creativemonkeys
creativemonkeys on Hacker News
Let's say you want to work with numbers and you want your program to run as fast as possible. If you specify the number of bits you want, like i32, then the compiler must make sure on 64bit CPUs, where the register holding this value has an extra 32bits available, that the extra bits are not garbage and cannot influence a subsequent operation (like signed right shift), so the compiler might be forced to insert an instruction to clear the upper 32bits, and you end up with 2 instructions for a single operation, meaning that your code now runs slower on that machine.
However, had you used 'int' in your code, the compiler would have chosen to represent those values with a 64bit data type on 64bit machines, and 32bit data type on 32bit machines, and your code would run optimally, regardless of the CPU. This of course means it's up to you to make sure that whatever values your program handles fit in 32bit data types, and sometimes that's difficult to guarantee.
If you decide to have your cake and eat it too by saying "fine, I'll just select i32 or i64 at compile time with a condition" and you add some alias, like "word" -> either i32 or i64, "half word" -> either i16 or i32, etc depending on the target CPU, then congrats, you've just reinvented 'int', 'short', 'long', et.al.
Personally, I'm finding it useful to use fixed integer sizes (e.g. int32_t) when writing and reading binary files, to be able to know how many bytes of data to read when loading the file, but once those values are read, I cast them to (int) so that the rest of the program can use the values optimally regardless of the CPU the program is running on.
Being direct creates an imbalance, for example when one describes an issue or person purely from a negative point of view, regardless of whether all of it is actually true. Most people will innately attempt to say something positive about that same person to restore some sort of balance to the discussion.
Generalizations are also an example of imbalance, with people typically having a strong reaction to it, even though I think most people would agree that if 97 times out of 100 something is true, it's safe to say that thing is true.
Lastly, as a special case of generalizations, taking an absolute stance is also seen as imbalanced, and therefore bad, because, I assume, most things in life aren't black and white - there's lots of gray areas, so it's pragmatic to start out assuming that in actuality there's a gray area with any issue.
This is all to say that Stallman doesn't speak in a balanced way, which is why I think his speeches and ideas do not appeal to the American audience, or any other audience that places a higher value on balance than on the actual ideas.
If he were able to convey those same ideas in a less absolutist, more nuanced and more pragmatic manner, I think he, as a person, would be more appreciated in the US and perhaps people would listen more closely to what Stallman has to say.
I've lived in several other countries, particularly in Europe, and generalizations, absolute positions and speaking in a direct manner are all generally appreciated by the society there, or at the very least it's tolerated much better and won't get you dismissed right away (since that's how most people speak).
At the end of the day, I personally think Stallman is right. When I look at what he says, I see a non-compromising idealist who places more value on truth, and how things "ought to be", than on pleasantries and gray areas, and that's a difficult sell to the American audience. When I focus on his content with the understanding that he's converting gray into either black or white, I see a dreamer and a believer in a utopian society. I too would like to live in a world where all software is FOSS and we all write FOSS code that runs on FOSS hardware, but I recognize that's a dream. It shouldn't stop us from trying to make that dream a reality though.
People who don't put in the effort to really learn their tools, need tools with training wheels. It's perfectly fine for a language to put in checks to protect you against yourself and be "fast enough for practical purposes", just don't confuse "almost fast" with "always fast". Rust programs have to pay the price for runtime checks because Rust doesn't trust you to know what you're doing.
It's possible to become a better driver to handle the F1 car, just like it's possible to arrive at the same destination driving a Corolla, just 2 minutes later. If you want the speed though, you have to put in the effort.
I think the only way to dethrone C is to change the equation of what's expensive to do in hardware - accessing memory, and that's not a problem us software guys are going to solve.
You could invest your time into learning that finite list, or you could invest your time into learning a new language with a long list of _unknown_ issues yet to be discovered - but out of sight, out of mind, right?
As far as runtime speed goes, assuming equal instructions being generated, if Rust spends even one CPU cycle checking array lengths, its generated code will be slower than C's, by definition. You can justify the trade-off ("it checks array lengths for me because I am human and I forget sometimes") or relax the restrictions ("it's not humanly noticeable"), but you can't claim it runs faster or even just as fast, because it's not.
The only thing Rust proved to me is that there was a whole generation of developers who did't mind writing unreadable Perl code who had kids that are equally unaware of how unreadable Rust code is and it'll take a few decades for them to see that, assuming that Rust stays relevant for another decade.
C is a small language with a spec designed to adapt to new hardware while remaining fast. The spec is ambiguous in precisely the places where resolving the ambiguity would mean either limiting its portability or its speed. This increases the learning curve significantly and also requires diligence on behalf of the developer, so it's high effort to write.
It's a perfectionist's language, because, if you can steer clear of the known pitfalls, you get a working piece of software that's maximally portable and fast, and fast is still what we want our tools to be.
There is a place for Zig, and Nim and Rust in this world, but there is no world in which these tools make the same trade-offs as C and end up with a faster and more portable (across hardware) language.
They can sacrifice speed to make it more difficult for the developer to make mistakes. They can sacrifice portability to make assumptions that resolve undefined behavior, which would also decrease the burden on the developer, but they will never get all three - correctness, portability and speed, so in that sense, they will never replace C, they can only hope to starve C of developers.
You drove a Corolla in college, then got a job and drove a cool BMW for several years and now you think you're hot shit, so you hope in an F1 car and not only does it take forever to learn how to drive it, it has to be driven on a special track and the gearbox is different, what a nuisance!
"If only we could add 4 doors, automatic transmission, snow tires, and a trunk to put our stuff in, people won't keep getting into accidents with this car", you say. Right, but then it becomes a BMW. If you want real speed, you need to first go slow and master the car because otherwise you'll crash and burn.
C is messy because real world hardware is very messy. You can't push bytes through the hardware at its speed limit without getting your hands dirty, and we all come out into the real world wearing "class Dog extends Animal" white gloves.
To use C effectively, you should not be coding in C in your mind. You should be thinking in assembly, but your fingers should be typing C code. It's not safe, but if you want to reach 230MPH and accelerate at 60MPH in 2.6 seconds, you better know exactly what you're doing when you hop behind the wheel of that car. It's not for the weak.
1. You bought a license to use SublimeText 3 in perpetuity
2. Later ST3 offers a routine update that doesn't communicate the fact that it is actually an upgrade to a product with a different licensing scheme. This comes as an unpleasant surprise to you.
2a. Additionally, applying a small update constitutes a small interruption to whatever you were doing (update, restart, continue editing).
3. Once started, ST4's very clear messaging is that you need a new license.
4. Because of #3, the minor interruption turned into a large interruption. Yes, people can go and downgrade, but _they shouldn't need to do that_.
I think #2 was a mistake on ST team's part (which they acknowledge) and it makes them look unprofessional in this one instance.
It is a frustrating experience, and it's OK and normal for users of SublimeText to feel frustrated. I want to make sure this is recognized, because saying "oh oops it was a bug" explains the root cause, but doesn't acknowledge the frustration it causes. I see this in software all the time. Software is for humans - we, as software developers, need to own the human consequences of these bugs as well, not just the technical side-effects.
Here's a bunch of things I was dealing with on a daily basis at the time:
* No revision control - sometimes files got deleted and research was lost
* Code that worked by accident, e.g. accessing the first element in an array using @array[$0] instead of @array[0], which worked only because $0 evaluates to "myscript.pl", and @array["myscript.pl"] returns the first element in the array.
* Some people just liked their code left-indented (read: no indentation at all anywhere)
When Python came along, with batteries included and with science-friendly libraries like numpy and scikit (so not just text processing, but proper numerical processing) you could get away with coding all your stuff in Python (though a lot of stuff is still Matlab). And on top of that it was easier to learn and to read than Python and it was fast enough. It was a no-brainer, so newcomers stopped learning Perl.
That said, Python's biggest contribution to this world, in my opinion, was forcing people to indent their goddamn code, because, as super-smart as these science guys generally were, they were also super-stubborn.
As for me, I moved from academia into the industry and it's so much nicer to work with other software developers. Sometimes I wonder if I should stop making some billionaire richer and go back to contributing to the scientific field, but, unfortunately, I have bills to pay. Maybe when I retire.
We didn't set a timer, but we usually gave her 5-10 minutes to calm down before popping back in.
If there's one thing I've learned though is that every baby is actually different (and it's not just a saying). For example, we've been bottle-feeding the baby right before sleep (nap and evening) every day for two years now, which I understand is against the usual advice of not feeding the baby immediately before putting her to sleep, but we found that she sleeps much better throughout the night and it didn't seem to cause any issues as long as we burped her properly before laying her down in the crib. YMMV though.