4 ms·

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

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!
- phoe-krk 7y ago
  > No, uh, the high level language performs way more work. The effective work is the same: a line is printed to the screen. The part you consider "wasted" does only go to waste if all of your programs are "hello world" programs, at which point, you might consider yourself fairly lucky if you also get paid for that. > Yes, nobody has ever written a complex program in C. > You're right. Let's rewrite the Linux kernel in Ruby. You're attacking a straw man. You completely omitted the part I wrote about "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." No one doubts the existence of Linux, BSDs, Darwin, or Windows. I doubt the programmer productivity while working on them.
  - overgard 7y ago
    > The effective work is the same: a line is printed to the screen. The part you consider "wasted" does only go to waste if all of your programs are "hello world" programs, at which point, you might consider yourself fairly lucky if you also get paid for that. Did the CPU work go towards something useful? No? Then it is waste. Some waste is inevitable; that doesn't change what it is. It's still waste. We should minimize waste. It's kind of simple. >You're attacking a straw man. You completely omitted the part I wrote about "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." No mate, you're the one attacking a straw man. You're ignoring the actual evidence of people getting important things done in low level languages and hand-waving it away because it doesn't agree with your preconceived notions of how things should be done.
    - phoe-krk 7y ago
      > Did the CPU work go towards something useful? No? Then it is waste. Some waste is inevitable; that doesn't change what it is. It's still waste. We should minimize waste. It's kind of simple. Sure, then let us minimize the waste - for example, minimizing the number of man-hours spent on fixing buffer overflows, null pointer dereferences and memory corruptions all over the software ecosystem across a variety of operating systems and architectures. Some languages have already eliminated that waste, by means of automatic memory management and memory safety. This is the part that doesn't agree with your preconceived notions in turn, and therefore you omit it from your posts altogether. Sure, if you're aiming for a trivial "hello world" program, then you can write it in the language that will give you the best result of the optimization function of time spent writing and debugging it, binary size, syscall size and whatever other measures you might want. So assembly and C are absolutely fine. And then, when you want to quickly and effectively write an actual system that utilizes the features of the respective languages' runtimes, use the same method: write it in the language that'll give you the best results under that same optimization function. And I can bet a few bucks that total development and bugfixing time will skyrocket for the low level languages, giving you all the waste that you mentioned above. > You're ignoring the actual evidence of people getting important things done in low level languages Again - I said that these achievements are undisputable and evident. The number of memory safety bugs in these low level languages is also one of them, which is a fact that you keep on ignoring.
trust_in_brutus 7y ago
I don't think what people are saying here is that the languages are too abstract, it's that compilers are implementing those abstractions with too much overhead. Most compilers (i assume) optimize by applying specific optimizations to patterns they find in the source. most of the time this is pretty good compared to non-optimized code. but the other day on HN i learned about polyhedral compilation, which is pretty crazy of an optimization. it got me thinking: what about all the optimizations we don't know about? is it possible to find the absolute best optimization for a program given some specifications of what we want from it? I think an ideal compiler would brute-force optimize like this so we don't miss out on optimizations we didn't think of: 1: compile the code normally without optimizations 2: generate a binary [see note1], and test if it produces the same output as the binary from (1)[see note2] 3: sort through the binaries and choose the best ones (perhaps some binaries are more optimized for speed, size, etc so there may be tradeoffs) note1: here are a couple ways i think you could do this, in order of practicality: A: modify the binary from (1) a bit at a time B: modify the binary from (1) X bits at a time, or any of the other binaries from (2) that passed the test, more likely to modify binaries that perform better in the tests. C: iterate through every possible binary up to around the size of the binary from (1) note2: the easiest way to implement this would be to test it with a ton of sample input, but it would be better if the binary could be analyzed somehow to see if it satisfied the parameters of the source code. I wouldn't use a such a brute-force optimizer to actually produce code which would then be undefined, but you could use it to reverse-engineer optimizations and implement them in source code. edit: formatting
wolco 7y ago
Your thinking like a cog in a machine. It is easier to program in high level languages. So easy that the hard part becomes dealing with management, constantly rewriting for marginal improvements. You start thinking the sprint is important and you ststt choosing a language so hiring is easier. In the end we end up with bloating teams and bloated software that continues to do less use more cpu but costs more It was more difficult to write a huge program in C. But you needed a smaller team. You are so deep in the system management is always over their heads.

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!

phoe-krk 7y ago
> No, uh, the high level language performs way more work. The effective work is the same: a line is printed to the screen. The part you consider "wasted" does only go to waste if all of your programs are "hello world" programs, at which point, you might consider yourself fairly lucky if you also get paid for that. > Yes, nobody has ever written a complex program in C. > You're right. Let's rewrite the Linux kernel in Ruby. You're attacking a straw man. You completely omitted the part I wrote about "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." No one doubts the existence of Linux, BSDs, Darwin, or Windows. I doubt the programmer productivity while working on them.
- overgard 7y ago
  > The effective work is the same: a line is printed to the screen. The part you consider "wasted" does only go to waste if all of your programs are "hello world" programs, at which point, you might consider yourself fairly lucky if you also get paid for that. Did the CPU work go towards something useful? No? Then it is waste. Some waste is inevitable; that doesn't change what it is. It's still waste. We should minimize waste. It's kind of simple. >You're attacking a straw man. You completely omitted the part I wrote about "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." No mate, you're the one attacking a straw man. You're ignoring the actual evidence of people getting important things done in low level languages and hand-waving it away because it doesn't agree with your preconceived notions of how things should be done.
  - phoe-krk 7y ago
    > Did the CPU work go towards something useful? No? Then it is waste. Some waste is inevitable; that doesn't change what it is. It's still waste. We should minimize waste. It's kind of simple. Sure, then let us minimize the waste - for example, minimizing the number of man-hours spent on fixing buffer overflows, null pointer dereferences and memory corruptions all over the software ecosystem across a variety of operating systems and architectures. Some languages have already eliminated that waste, by means of automatic memory management and memory safety. This is the part that doesn't agree with your preconceived notions in turn, and therefore you omit it from your posts altogether. Sure, if you're aiming for a trivial "hello world" program, then you can write it in the language that will give you the best result of the optimization function of time spent writing and debugging it, binary size, syscall size and whatever other measures you might want. So assembly and C are absolutely fine. And then, when you want to quickly and effectively write an actual system that utilizes the features of the respective languages' runtimes, use the same method: write it in the language that'll give you the best results under that same optimization function. And I can bet a few bucks that total development and bugfixing time will skyrocket for the low level languages, giving you all the waste that you mentioned above. > You're ignoring the actual evidence of people getting important things done in low level languages Again - I said that these achievements are undisputable and evident. The number of memory safety bugs in these low level languages is also one of them, which is a fact that you keep on ignoring.

trust_in_brutus 7y ago

I don't think what people are saying here is that the languages are too abstract, it's that compilers are implementing those abstractions with too much overhead. Most compilers (i assume) optimize by applying specific optimizations to patterns they find in the source. most of the time this is pretty good compared to non-optimized code. but the other day on HN i learned about polyhedral compilation, which is pretty crazy of an optimization. it got me thinking: what about all the optimizations we don't know about? is it possible to find the absolute best optimization for a program given some specifications of what we want from it? I think an ideal compiler would brute-force optimize like this so we don't miss out on optimizations we didn't think of: 1: compile the code normally without optimizations 2: generate a binary [see note1], and test if it produces the same output as the binary from (1)[see note2] 3: sort through the binaries and choose the best ones (perhaps some binaries are more optimized for speed, size, etc so there may be tradeoffs) note1: here are a couple ways i think you could do this, in order of practicality: A: modify the binary from (1) a bit at a time B: modify the binary from (1) X bits at a time, or any of the other binaries from (2) that passed the test, more likely to modify binaries that perform better in the tests. C: iterate through every possible binary up to around the size of the binary from (1) note2: the easiest way to implement this would be to test it with a ton of sample input, but it would be better if the binary could be analyzed somehow to see if it satisfied the parameters of the source code. I wouldn't use a such a brute-force optimizer to actually produce code which would then be undefined, but you could use it to reverse-engineer optimizations and implement them in source code. edit: formatting

wolco 7y ago

Your thinking like a cog in a machine. It is easier to program in high level languages. So easy that the hard part becomes dealing with management, constantly rewriting for marginal improvements. You start thinking the sprint is important and you ststt choosing a language so hiring is easier. In the end we end up with bloating teams and bloated software that continues to do less use more cpu but costs more It was more difficult to write a huge program in C. But you needed a smaller team. You are so deep in the system management is always over their heads.