6 ms·

What is this post supposed to prove? It certainly is not supposed to prove that a hello world is a representative real-world program, from which one could infer

What is this post supposed to prove? It certainly is not supposed to prove that a hello world is a representative real-world program, from which one could infer that writing and debugging a real-world program in Julia is 835 times as complex as writing a real-world program in assembly, since the former makes 835 times as many syscalls as an assembly program. (You know, that number seems okay for me, except it needs to be applied to these languages in reverse.) I agree that software bloat is a big problem, but trivializing that problem to printing a "hello world" to the screen, punishing all languages with runtimes by measuring the syscalls involved in their startup routines, disregarding the fact that many users are going to have a single system-wide runtime for e.g. C or Python or Julia and therefore the total-kB number does not scale linearly with the number of programs written in C or Python or Julia, ignoring the massively increased software development and debugging time for writing in low-level and memory-unsafe languages like assembly, static Zig, or C, and directly implying[0] that most problems with software complexity can be solved by writing in assembly, static Zig, or C rather than in Julia/Ruby/Java/all other languages from the bottom 90% of the list (and that's the vibe that this post gives me) is, for me, more about making a venting shitpost than creating something that provides even a part of an actual solution to software bloat in general. The "more time your users are sitting there waiting for your program" statement is especially amusing to me. Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. [0] "These numbers are real. This is more complexity that someone has to debug, more time your users are sitting there waiting for your program, less disk space available for files which actually matter to the user."

ajkjk 7y ago
It could just be trying to be interesting, not to prove anything.
- phoe-krk 7y ago
  Why is it attempting to moralize if it is not meant to prove any morals then?
- hn_throwaway_99 7y ago
  The language in the post, "Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for." certainly seems to imply it's moralizing about something.
overgard 7y ago
If your compiler generates something huge for the most basic test, how can you trust it's doing well on actual programs? Most real programs are far too complicated to analyze. It may be a toy example, but if your language can't handle a toy, it's probably bad on real world programs also.
- jefozabuss 7y ago
  This example is not too relevant because the overhead is probably the additional tools (e.g. debug, error handlers, etc), there should be multiple examples for a normal comparison, e.g. 3-4 examples of more and more advanced code since then maybe these numbers would increase in a similar fashion.
- phoe-krk 7y ago
  You have a weird definition of "handling". A high-level language performs the same amount of work as the lower-level one - I cannot see a language listed in the blogpost that has failed to display a command in the console. It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. This "simplicity"[0] is often fetishized, and this blog post looks no different to me - look how many overflow bugs in operating system kernels this "simplicity" has caused. Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? [0] I can agree, writing in a memory unsafe language is simple, as long as it's someone else who maintains the code you wrote, accepts or reroutes all of the bugtickets that happen, and analyzes heisenbugs that come from weird memory corruptions caused by unsafe code.
  - overgard 7y ago
    > A high-level language performs the same amount of work as the lower-level one No, uh, the high level language performs way more work. It just happens that most of that work is useless. You seem to be unclear on the definition of efficiency, so let me spell it out: it's not about getting the work done, it's about getting the work done in the minimal amount of steps. That's why this is a good test: there's a clear boundary of "minimal amount of work". > It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. Yes, nobody has ever written a complex program in C. Excluding every OS and every important desktop application, I guess. Yeah, it's more work. Sometimes doing something hard takes more work. > Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? You're right. Let's rewrite the Linux kernel in Ruby. C just isn't up to the task. As an added bonus, all our computers will now have the benefit of working as excellent space heaters!
einpoklum 7y ago
> What is this post supposed to prove? It proves that the compilers for many programming languages emit a lot of instructions and a lot of system calls they could have optimized away theoretically. This is particularly true when there are lots of "startup routines". When the program to be run is known, almost all of that startup can be found out to not be necessary, and stripped from the final executable. > Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. They might, if your program is interactive and is used often enough. Now, writing assembly is not very realistic, but considering a different language with less overhead - is.
- phoe-krk 7y ago
  > they could have optimized away theoretically. For a hello-world program, this is true, you do not need any of the features that usually come in the language runtime - no garbage collection, no runtime memory safety, no runtime introspection, et cetera. This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. And that, considering your point of view, might be a feature, not a bug - especially if your program, having a runtime of its own, actually produces its own stacktrace, allows you to interactively inspect values of variables throughout the stack, and - in case of some runtimes - is capable of opening up its own debugger for you to perform introspection and issue analyzing in.
  - saagarjha 7y ago
    > This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. Right, I think the point was that this isn't always necessary, in which case it becomes extra baggage that you have to carry around.
- hokumguru 7y ago
  For all the daily articles that pop up here on HN concerning premature optimization I find it surprising to see this thread and all the sentiment of language choice mattering. It’s far easier to work in and translate thoughts to more feature rich languages. The vast majority of the time it’s not the language itself that will be an optimization issue down the line but rather the written code.
jhoeriutre 7y ago
It's the software developers equivalent of virtue signaling. Some people get outraged that OTHERS use plastic straws, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS paper straw. Some programmers get outraged that OTHERS write bloated programs in Python/JavaScript/Electron, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS C/Assembly/native GUI app.
deleted 7y ago
[deleted]
3xblah 7y ago
"What is this supposed to prove?" Perhaps it proves that if one is writing relatively small, simple programs, some of these languages are overkill.

ajkjk 7y ago

It could just be trying to be interesting, not to prove anything.

phoe-krk 7y ago
Why is it attempting to moralize if it is not meant to prove any morals then?
hn_throwaway_99 7y ago
The language in the post, "Most languages do a whole lot of other crap other than printing out “hello world”, even if that’s all you asked for." certainly seems to imply it's moralizing about something.

overgard 7y ago

If your compiler generates something huge for the most basic test, how can you trust it's doing well on actual programs? Most real programs are far too complicated to analyze. It may be a toy example, but if your language can't handle a toy, it's probably bad on real world programs also.

jefozabuss 7y ago
This example is not too relevant because the overhead is probably the additional tools (e.g. debug, error handlers, etc), there should be multiple examples for a normal comparison, e.g. 3-4 examples of more and more advanced code since then maybe these numbers would increase in a similar fashion.
phoe-krk 7y ago
You have a weird definition of "handling". A high-level language performs the same amount of work as the lower-level one - I cannot see a language listed in the blogpost that has failed to display a command in the console. It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. This "simplicity"[0] is often fetishized, and this blog post looks no different to me - look how many overflow bugs in operating system kernels this "simplicity" has caused. Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? [0] I can agree, writing in a memory unsafe language is simple, as long as it's someone else who maintains the code you wrote, accepts or reroutes all of the bugtickets that happen, and analyzes heisenbugs that come from weird memory corruptions caused by unsafe code.
- overgard 7y ago
  > A high-level language performs the same amount of work as the lower-level one No, uh, the high level language performs way more work. It just happens that most of that work is useless. You seem to be unclear on the definition of efficiency, so let me spell it out: it's not about getting the work done, it's about getting the work done in the minimal amount of steps. That's why this is a good test: there's a clear boundary of "minimal amount of work". > It's the lower-level languages that, for the sake of efficiency and minimalism, cannot handle systems larger than a hello-world and actual programs written in them without long development times and a mass of bugs that come straight from their inability to abstract when necessary and from their memory management systems that lack sanity and safety. Yes, nobody has ever written a complex program in C. Excluding every OS and every important desktop application, I guess. Yeah, it's more work. Sometimes doing something hard takes more work. > Or, paraphrasing your quote, if your language prevents you from creating most basic abstractions, how can you trust it's doing well on actual programs? You're right. Let's rewrite the Linux kernel in Ruby. C just isn't up to the task. As an added bonus, all our computers will now have the benefit of working as excellent space heaters!

einpoklum 7y ago

> What is this post supposed to prove? It proves that the compilers for many programming languages emit a lot of instructions and a lot of system calls they could have optimized away theoretically. This is particularly true when there are lots of "startup routines". When the program to be run is known, almost all of that startup can be found out to not be necessary, and stripped from the final executable. > Your users are not going to wait shorter for your program because you and your team are taking another year to write, test, and debug it in assembly. They might, if your program is interactive and is used often enough. Now, writing assembly is not very realistic, but considering a different language with less overhead - is.

phoe-krk 7y ago
> they could have optimized away theoretically. For a hello-world program, this is true, you do not need any of the features that usually come in the language runtime - no garbage collection, no runtime memory safety, no runtime introspection, et cetera. This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. And that, considering your point of view, might be a feature, not a bug - especially if your program, having a runtime of its own, actually produces its own stacktrace, allows you to interactively inspect values of variables throughout the stack, and - in case of some runtimes - is capable of opening up its own debugger for you to perform introspection and issue analyzing in.
- saagarjha 7y ago
  > This stems directly from the fact that many of these languages have borrowed features from Lisp, which has the whole language (GC, compiler, debug functions, etc..) always available for the code. Right, I think the point was that this isn't always necessary, in which case it becomes extra baggage that you have to carry around.
hokumguru 7y ago
For all the daily articles that pop up here on HN concerning premature optimization I find it surprising to see this thread and all the sentiment of language choice mattering. It’s far easier to work in and translate thoughts to more feature rich languages. The vast majority of the time it’s not the language itself that will be an optimization issue down the line but rather the written code.

jhoeriutre 7y ago

It's the software developers equivalent of virtue signaling. Some people get outraged that OTHERS use plastic straws, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS paper straw. Some programmers get outraged that OTHERS write bloated programs in Python/JavaScript/Electron, and wiggle the finger at them for being bad persons while pointing at their VIRTUOUS C/Assembly/native GUI app.

deleted 7y ago

[deleted]

3xblah 7y ago

"What is this supposed to prove?" Perhaps it proves that if one is writing relatively small, simple programs, some of these languages are overkill.