164 karma · joined August 24, 2023
I think it's simply what they already knew. Very few programmers learn multiple languages to any kind of depth.
Is there any evidence that Python is an easy language to learn? I think we've reached a situation where beginners learn Python because it's seen as beginner friendly... because beginners learn Python!
- Weird scoping rules
- Very limited list-comprehensions
- Ability to monkey patch things is a liability
- Mutability by default
- Lack of support for functional programming
- Deployment story remains extremely painful
- Tacked on type-system
- Slow execution of pure Python code
If this sounds like a rant... it sort of is. I find it really sad that so much programmer effort is being put into something with poor fundamentals. Many of these issues cannot be fixed with breaking changes.
For example: https://github.com/fsharp/fslang-suggestions/issues/243#issu...
> EDIT 5 years later: You can see in the edit history of this comment what I originally wrote here; I was upset and said unkind things that I regret, and which nobody deserved to hear. I apologized at the time and I still feel I should apologize again, unequivocally. I was in the wrong here.
You can also run the content pipeline as a .NET tool outside of Visual Studio. It works on Linux too!
There are also a handful of true grammar schools left. These are free to attend, but are selective based on ability. There is debate about the extent to which raw ability is really being tested, and not preparedness for the test.
There are also private schools that call themselves grammar schools. These were once free and selective, but converted to fee-paying at some point. They like the prestige of being called a "grammar" but don't be fooled!
The lack of true grammar schools has been a big hit to social mobility in the UK. Now, getting into a grammar requires not just passing a test, but also having parents rich enough to buy a house in the catchment area. Public school alumni dominate top industries and government.
The UK "free school" approach has been a mixed bag. On the one hand, various academy chains have managed to turn around failing schools. On the other, some parents are left with no choice but to send their child to a religious school due to catchment areas and waiting lists.
As a tax payer, I don't want my contributions going towards religious institutions.
The loss of "special schools" for students with severe special needs has not helped anyone (imo).
Anecodtally, I see motorists driving whilst using their phone on a daily basis. I rarely see cycling jumping red lights. I also see motorists jumping red lights, but rarely. I frequently see motorists on the wrong side of the road trying to skip traffic queues.
But you claim was about recklessness.
Poor driving is much, much more reckless than poor cycling, given the kinetic energy involved.
Citation needed.
The X-risk crowd need to realize that LLMs, whilst useful, are toys compared to Skynet.
The risk from AI right now is mega-corps breaking the law (hiring, discrimination, libel, ...) on a massive scale and using blackbox models as an excuse.
You get paid to deliver more value to someone than you cost them (or someone else might cost them!)
Whether or not you have fun has little to do with it.
Accelerationism is the belief that we should race towards catastrophe so that we can rebuild society in a better way.
E / Acc is a (sometimes ironic) amalgam of the two.
You won't be surprised to learn that not many in these groups have studied history.
As engineers we focus too much on the implementation details and not the benefits to the user.
How about:
- ZooKeeper alternative with lower latency
- ZooKeeper alternative with lower memory use
- ZooKeeper alternative with predictable overheads
(I don't know if these are true, just suggestions)
I always opt for option 2 where possible though.
Perhaps really performance critical stuff could have a "notrace" annotation.
In languages with async-await syntax, I like that it is explicit what is sync and what is async. I also like how the "bind" points within an async expression make it clear where the syncronization happens. It seems to me that Java 21 makes all of this implicit, which is a step backward in this respect.
Similar to how types enforce valid usage (a foundational idea in Java), I feel that an Async<T> should not be implicitly a T.
Are people concerned about this at all?
Have the Java designers addressed this?
They sure didn't try very hard to secure it. I wonder if it was their strategy all along.