Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Questions

patrickcollison.com

Post reply on HN
Print view View original

471–480 of 493 posts

Re: Questions

#471

Post by dennisgorelik »

softawre wrote: post #466
ellyagg wrote: post #400

Earlier quoted context omitted.

My dad was a programmer and I'm a programmer. I don't think I'll ever make a salary as high as he did[1], and that's in absolute dollars. Yet, my quality of life is definitely better. I take vacations all over the world. I can look up any fact I want instantly on the internet. I work from home 3 days a week. I've easily cured maladies that were huge nuisances when he was my age. You're right that macroeconomic indica…

How much was his salary? I would think a lot of programmers these days make more in absolute dollars than their parents would have.

Not all children are as smart or productive as their parents.

Re: Questions

#472

Post by fibbery »

L_Rahman wrote: post #305
chucky wrote: post #35

> Why are there so many successful startups in Stockholm? Several reasons. First, you need to recognize that any Sweden-based startup will, when it gets to be known internationally, have a Stockholm-based office. So it's not about a city of 1 million inhabitants, it's a country of 10 million that's the true number here. As an example, I believe Spotify opened their original offices in both Stockholm and Göteborg more…

It's interesting the quite possibly the most important condition didn't get mentioned. Sweden's social safety net is among the strongest in the world. If the floor on failure is that you still have access to food, housing and healthcare then quitting a full-time job to start a company becomes much more possible. More people starting companies, more attempts at big targets, more outlier successes.

Also education and childcare

Re: Questions

#473

Post by Koshkin »

AnimalMuppet wrote: post #469
Koshkin wrote: post #288

On a tangential note, there is an Italian proverb about questions and answers.

For those of us not well-versed on Italian proverbs, would you tell us what that proverb says?

It says, Un pazzo può fare più domande di quante sette uomini saggi possano rispondere.

Re: Questions

#474

Post by Gibbon1 »

reitanqild wrote: post #66
alkonaut wrote: post #23

Earlier quoted context omitted.

C#/.NET 64 bit does this too but there were always limitations such as not being able to reload the code if method parameters were changed, closures were modified etc.

On Java you can often do most of this using either JRebel or DCEVM.

When I saw how C#/.net could do this I found myself annoyed because you could in theory do with with even C. There isn't any reason you couldn't monkey patch a new function in a running C program. At least for a pure function.

I used to work with a OG (with a pocket protector no less) who did this when debugging assembly by pasting op-codes using a debug monitor.

Re: Questions

#475

Post by zbentley »

lisper wrote: post #462
zbentley wrote: post #452

Earlier quoted context omitted.

Citation needed. “Because there existed languages with different concurrency models” doesn’t really explain why the choice of C for Python’s implementation necessitated a GIL (there are plenty of languages and tools built on C with non-GIL-ish concurrency systems, and many languages/tools built on not-C that don’t expose the concurrency features of their underlying language at all). Look into how/why then GIL was add…

> it has much more to do with not wanting to reimplement the language/break compatibility I don't know what "language/break compatibility" means. The GIL is needed because Python's reference-counted memory management system is not thread-safe, and this can't be fixed without compromising either portability or performance. It's really that simple.

> The GIL is needed because Python's reference-counted memory management system is not thread-safe.

That is correct. What does that have to do with C? Thread-unsafe code exists in all languages. The GIL's lock is itself a pthread mutex and condvar underneath, and equivalent constructs exist in all (to my knowledge) modern threaded programming environments.

"not wanting to reimplement the language/break compatibility" is a reference to the successful efforts that have been made to remove the GIL in CPython. Those efforts have not (yet) moved towards merging into mainline CPython because they require a) lots of reimplementation work and added complexity in the language core, and b) would very likely break the majority of compiled extension modules.

I think that's additional evidence that the GIL isn't a C problem; they removed it, in C, without fighting or otherwise working around the language.

Re: Questions

#476

Post by lisper »

zbentley wrote: post #475
lisper wrote: post #462

Earlier quoted context omitted.

> it has much more to do with not wanting to reimplement the language/break compatibility I don't know what "language/break compatibility" means. The GIL is needed because Python's reference-counted memory management system is not thread-safe, and this can't be fixed without compromising either portability or performance. It's really that simple.

> The GIL is needed because Python's reference-counted memory management system is not thread-safe. That is correct. What does that have to do with C? Thread-unsafe code exists in all languages. The GIL's lock is itself a pthread mutex and condvar underneath, and equivalent constructs exist in all (to my knowledge) modern threaded programming environments. "not wanting to reimplement the language/break compatibility"…

> That is correct. What does that have to do with C? Thread-unsafe code exists in all languages.

Yes, that's true. But thread-unsafe GC does not exist in all languages. When GC is provided natively by the language it can be implemented much more safely and efficiently than if you try to shoehorn it in afterwards.

> the successful efforts that have been made to remove the GIL in CPython

That's news to me. Reference?

Re: Questions

#478

Post by zbentley »

lisper wrote: post #476
zbentley wrote: post #475

Earlier quoted context omitted.

> The GIL is needed because Python's reference-counted memory management system is not thread-safe. That is correct. What does that have to do with C? Thread-unsafe code exists in all languages. The GIL's lock is itself a pthread mutex and condvar underneath, and equivalent constructs exist in all (to my knowledge) modern threaded programming environments. "not wanting to reimplement the language/break compatibility"…

> That is correct. What does that have to do with C? Thread-unsafe code exists in all languages. Yes, that's true. But thread-unsafe GC does not exist in all languages. When GC is provided natively by the language it can be implemented much more safely and efficiently than if you try to shoehorn it in afterwards. > the successful efforts that have been made to remove the GIL in CPython That's news to me. Reference?

https://youtu.be/P3AyI_u66Bw

Or search “gilectomy” on LWN. Or check out stackless etc.; it turns out removing the GIL technically is historically one of the easier parts of removing the GIL entirely.

It sounds like your main problem is with python’s GC model. Reference counting doesn’t have to be thread-unsafe, but in scripting/interpreted-ish languages that want their threading story to involve seamless (I.e. no special syntax unless you want it, it’s on you not to blow off your foot) sharing of state between threads at will, like Python and Ruby, a GIL or equivalent is the norm. Sometimes it’s not as intrusive as python’s, but it does seem like a necessary (or at least very likely) implementation pattern for languages that want to provide that seamlessness. You can have thread-safe reference counted GC in a traditional scripting language, but that tends to come with a much less automatic threading/concurrency API. Perl 5 is an example of that category, and it is implemented in C.

Re: Questions

#479

Post by keithpeter »

kerbalspacepro wrote: post #470
ntxy wrote: post #399

Earlier quoted context omitted.

this plagues my sleep. yes, spreadsheets! I always wonder: what's so special about spreadsheets?

Spreadsheets are the best! They are literally THE killer app for PCs.

They do allow people to walk up and start building models with minimal introduction. Low floor, and, alas, as many know here to their cost, a high ceiling in the sense that spreadsheets often get used for more advanced modelling that would benefit from being constructed in a more maintainable way.

Re: Questions

#480

Post by baud147258 »

lisper wrote: post #106

> Why are programming environments still so primitive? Because we as an industry made a strategic decision in the late 20th century to value run-time efficiency over all other quality metrics, a decision which has manifested itself in the primacy of C and its derivatives. Everything else has been sacrificed in the name of run time efficiency, including, notably, security. Development convenience was also among the co…

> Why can't I debug a function without restarting my program?

Because you use C or one of its derivatives

It's doable in java which is, I think, a derivative of C.

Post reply on HN