Reminds me of a C++ codebase I once had to inspect that was entirely written as if it were written in Java. With camelcase naming for everything, getters and setters for every class variable, interfaces everywhere.
Also because the special characters were (and are) difficult to type on European keyboards.
Characters like []{}\|~ are behind multi-finger access and often not printed at all on the physical keys (at least in the past). You can see how this adds a hurdle to writing C…
Pascal was designed by a European, so he preferred keywords which could be typed on every international keyboard. C basically just used every symbol from 7-bit ASCII that happened to be on the keyboards in Bell Labs.
Just as example, on my slovenian QWERTZ layout: [ - altgr+f, ] - altgr+g, { - altgr+b, } - altgr+n, \ - altgr+q, | - altgr+w, ~ - altgr+1.
You get used to them, though you start feeling like a pianist after a short coding session. The one most annoying for me are the fancy javascript/typescript quotes, which I have to use all too often: ` - altgr+7.
I tried switching to US a few times, but every time muscle memory made me give up soonish - especially since there are big benefits to using same keyboard layout as other people in your office are using.
Also practically everytime I need to write a comment, commit message or email I need my č, š and ž. It's kinda nice to have them only a single keypress away.
I'm from a non-English country. I only ever use layout of my locale when I write in my language. That's how it was ever since I was a kid who knew little English. And that's how all computers I've encountered in my country are set up - English first, local second.
In addition, our layout, overwrites only the numerics – all other symbols are the same as on a US layout.
There’s so many assumptions here about a person who’s starting to learn programming.
For starters, that they’re on Linux, they feel comfortable running complex CLI commands, they can memorize the U.S. layout just like that, and that they can type without looking at the physical keys (because changing the virtual mapping means keys produce something else than what the label says).
In reality, the learner’s first exposure to C family languages is more likely to be a website where you can run some JavaScript in a text box. And the first hurdle is to figure out how to even type {}. American developers just completely forget about that.
I’ve been writing C and its progeny (C++, JavaScript, Rust etc.) since 1990 on a Finnish keyboard.
The AltGr brackets are fine. The truly annoying character to type is the backtick (which is a quite new addition to the pantheon of special characters, C doesn’t use it).
My personal opinion is that Niklaus Wirth had the better overall ideas about clarity and inclusiveness in programming language design, but that battle is long lost. (What you consider the character set needed for "proper programming" is really a relatively new development, mid-1990s and later.)
Backticks were fairly important for shell scripting in the past, but have officially been replaced with $(), which can be nested.
My intuition is that Perl would be the most challenging on a keyboard where it's harder to type unusual punctuation, since it feels like a very punctuation-heavy language, but I don't know whether it actually uses more than C (I think the backtick has a shell-style meaning in Perl too).
Well unless opting for something like Dvorak, you are indeed doomed to something that was specificcaly designed to please typewriter mechanical constraints without much care for the resulting ergonomics.
I use a Bépo layout personally, on a Typematrix 2030 most of the time, as French is my native language.
or maybe popular proglangs were designed for writing on USAn press/office keyboards – remember that UNIX came to be as a typesetting appliance — disregarding anyone else.
Spectacular?? Terrifying. If I need to type non-ASCII Latin characters I'll just use compose sequences. The thought of a non-U.S. keyboard layout with modifiers required to type []{}<> and so on is terrifying.
> camelcase naming for everything, getters and setters for every class variable, interfaces everywhere
This is not far off from the guidelines in many cases, e.g. Windows code (well, not every variable of course.) A lot of Java design was copied from C++.
I've seen similar codebases as well written by people who have spent way too much time with Java. One even had it's own String class which was just a wrapper for std::string with Java-like methods.
In my opinion, Astron's PMT (Power Measurement Toolkit) is a much more useful tool than this, because it abstracts over Intel, AMD, and Nvidia (including Jetson): https://git.astron.nl/RD/pmt
"In 2018, professors Alan Benson, Danielle Li, and Kelly Shue analyzed sales workers' performance and promotion practices at 214 American businesses to test the veracity of the Peter principle. They found that these companies tended to promote employees to a management position based on their performance in their previous position, rather than based on managerial potential. Consistent with the Peter principle, the researchers found that high performing sales employees were likelier to be promoted, and that they were likelier to perform poorly as managers, leading to considerable costs to the businesses.[15][16][2]"
The Peter Principle might be downstream of the Monotonic Pay Scale, where it is expected that a person who manages others must be paid more than any of them. Conversely, no matter how good you are or how much money you are making the business, you will reach a point where your pay is effectively capped unless you transition to management.
The government suffers from this especially, despite an ostensibly very different incentive structure. The explosion in government contractors (by which I mean, individuals indirectly employed to do jobs in lieu of direct hires) seems to be driven in no small part by this problem.
Surprises me to see I'm the first comment here to say: I just use GPT4 for this. Works perfectly, even for getting the Latex source of a formula you only have a screenshot of.
Probably quite the overkill in terms of energy efficiency for just image to text, but I only need this like once every two weeks or so.
In the city where I live, also in the Netherlands, we had multiple of these but all of them got converted back to normal intersections with traffic lights and it has been a huge improvement.
My understaning is that normal intersection with traffic lights has higher troughput (as cars can just fly through it at or near 50 km/h if the green light is long enough), but roundabout have lower average wait times (if the traffic is low to moderate, you usually wait less that 5-10 seconds to enter the intersection).
No, simple roundabouts are worse in both throughput and wait times than normal intersections with traffic lights. They are however safer, and that safety is precisely thanks to slowing traffic town, which means that collisions are less frequent because drivers have more time to react and if a collision happens it happens at lower speed. Just think about it: how can wait time be smaller and throughput higher when cars approaching a roundabout from _any_ direction need to slow down compared to normal intersection where cars on one road can wizz through with full speed?
To answer your question: wait times can be lower because, if the traffic is low enough, ALL cars just wizz through, at the cost of slowing down while entering the roundabout. Whereas, for the intersection with traffic lights, a significant number of cars will hit red light and have to wait for a minute or two.
Except it's not true. You can't wizz through a roundabout because the road is curved, you are physically unable to drive through it with the same speed as you drive on a straight road. It's by design. When traffic is very light then the traffic lights can be simply disabled (for instance, at night). Not disabling them is the failure of the people responsible for the traffic lights, not some inherent unsolvable problem.
This depends on how light the traffic is. In a lot of places, traffic outside of rush hours is light to moderate (but definitely not light enough to justify disabling the lights), and the roundabouts might the more efficient solution, at least outside of rush hours. It was probably studied by someone already, as this would make a decent research topic for any transporation scientist.
In light traffic roundabouts are actually worse than normal intersection. How can it even be disputed? Let's say you have one car per hour, or any number of cars approaching in such a way that none of them gets close to the intersection at the same time. It goes through normal intersection without much slow down. It goes through equivalent roundabout _always_ slowing substantially down. What's here to dispute? If you have cars approaching at the same time then it gets a bit more complicated but the claim that in such a situation you can still always beat normal intersection is just ridiculous, because if the cars show up at exactly the right time some of them still need to completely stop before entering roundabout because there is already another car circling it. Analogously with normal intersection you don't need to always stop before entering it because both cars might be turning into perpendicular roads and they don't cross their paths at all so they both can go smoothly through without stopping at all. I do agree that roundabouts make the intersections safer, that's great, but it's at the cost of throughput but everybody pretends it's not true. Even the claim that the delay is reduced because cars would need to wait on traffic lights is dubious, because you can't just enter or leave a roundabout when there is heavy traffic through it that competes with your 'route' , roundabout is not equal for all entry points and doesn't distribute all of them equally. So you might wait just as long as you would waiting on traffic lights. Standard intersections are worse only if they have dumb traffic lights and the traffic is light, that forces you to stop and wait even though there is no competing traffic. But again, it's a case of fixing the lights and making them sense the incoming traffic instead of installing roundabouts.
> Let's say you have one car per hour, or any number of cars approaching in such a way that none of them gets close to the intersection at the same time.
That's not light traffic, that's basically no traffic. I don't think anyone bothers to build a roundabout for such intersection.
Roundabouts are for light to moderate traffic scenarios. Their main benefit is that they get drivers to slow down, which vastly reduces number of accidents and fatalities on the intersection. The effect on throughput is secondary, as the intersection was not congested anyway.
That claim of reduced fatalities is also getting outdated now, since the introduction of roundabouts with more than one line. Also accident rate for the cyclists is actually higher on roundabout than in a a standard intersection. So all in all, roundabouts are not as great as many insist and my beef with them and their supporters is that they keep bringing up the same talking points that were presented _before_ roundabouts started to be built on a massive scale and don't want to hear the empirical evidence about how these roundabouts actually work in practice.
Brings back high school memories when we used to shutdown peoples mIRC client with a special message that you could send as a personal message to them.
I don't know it anymore but I remember it started with a whole bunch of aaaaaaa, but also included other characters. The beauty is the attack left no trace at all, so they never knew what hit them.
