2 ms·

> 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

> 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.
  - overgard 7y ago
    Honest question: have you ever actually done any (professional) development in C/C++ or Rust? You're WAY overstating the development tax on these things. C isn't hard because it's harder to debug (it's about the same difficulty to be perfectly honest). It's hard because you have to actually think about each allocation and instruction. You might not want to! That's fine! You're incurring a large perfomance tax though, if you don't. It's not nothing! Also, I'm calling bullshit that manual memory management lacks "safety and sanity". It's harder. You can screw it up. That doesn't mean that the default should be "pretend like machines have infinite RAM and we'll never run out". We're engineers, we make tradeoffs here all the time. BTW: I think it's funny that you're pretending like I'm a low level partisan or something that doesn't know the upsides of modern languages. My day job is writing typescript. My favorite language is python. But my previous two jobs were writing super low-level C++ code for 3D modelling and game development. I am entirely aware of how convenient a garbage collector is. I also don't think "helloworld" should compile to be 1MB. We should have standards.
    - pdimitar 7y ago
      > Honest question: have you ever actually done any (professional) development in C/C++ or Rust? I did in C and C++ and ran away screaming from them 12 years ago. I am learning Rust lately and I am actively rewriting several small-to-medium-sized projects that I wrote in Ruby or Elixir in the past. Accidentally, some of those projects have intersections with C/C++ code I wrote ~15 years ago and the Rust code is much more manageable, it's smaller, more understandable (although it has a pretty quirky syntax at places) and I am confident it will be easier to troubleshoot -- if my 18 years in the area are worth a penny. It doesn't carry invisible gotchas between the lines which is IMO the biggest win when you write a lower-level language. > Also, I'm calling bullshit that manual memory management lacks "safety and sanity". It's harder. You can screw it up. Correction: you WILL, INEVITABLY, screw up manual allocation, eventually. That's the crux of your discussion with the other guy here. The mental baggage you have to carry in your brain to avoid this is not worth it for 99% of the projects, at least those in my career. None of my customers and employers ever contracted for NASA or gaming studios, so reaching for C/C++ was a huge waste of human time, most of the time. If you have to write an embedded OS or there's absolutely no way to use Go or Rust to interface with a hardware piece that still has no driver -- and you are the one writing it -- sure, C/C++ are still a good choice (although I do wonder for how much longer; Zig and Rust look better and better with time but I imagine LLVM still has to improve a lot so Rust is useful for OS/driver development). If not, using literally everything else on the spectrum -- from Rust to Python/PHP/Ruby/Elixir/JS -- will work fine. > That doesn't mean that the default should be "pretend like machines have infinite RAM and we'll never run out". We're engineers, we make tradeoffs here all the time. I don't think anyone here said that but I haven't scanned the whole thread yet. You are indeed fighting an [extreme] straw-man in my eyes as well. > I am entirely aware of how convenient a garbage collector is. I also don't think "helloworld" should compile to be 1MB. We should have standards. Now we're getting somewhere! :) We absolutely should be having standards. The problem is sadly very common: everybody is like "my MacBook could handle Python's runtime inefficiency so meh to you old man yelling at cloud, we got work to do". IMO all programming languages should have a natural way to sink to the bottom of popularity if their runtimes are not improved over time. I am a good example of how people should pick their tech (given no firm requirements from employers, of course). I tried several dynamic languages and made a pick based on my productivity, the helpfulness of the community, the average quality of the libraries, and the technical prowess of the runtime. I do wish it had a shorter bootstrap time but hey, it's specifically made for servers so I can swallow it. On the other end of the spectrum, I'd like to make a comeback in the very fast low[-ish] level languages so I am learning Rust. I know I can gain extra runtime speed (and maybe memory efficiency but that's not a given) if I go back to C and C++ but I'd like to balance out productivity with stress and overall ability to get shit done. And especially important: not join tribes that yell "real men use C++!", I am sick of that crap. --- I don't think you and the other guy actually disagreed but kind of got hung up on a few minutiae. I also believe we indeed should have standards. (Which means software like Slack should not be used at all.) But we all know that writing compilers and optimizers is pretty damn hard.

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.
- overgard 7y ago
  Honest question: have you ever actually done any (professional) development in C/C++ or Rust? You're WAY overstating the development tax on these things. C isn't hard because it's harder to debug (it's about the same difficulty to be perfectly honest). It's hard because you have to actually think about each allocation and instruction. You might not want to! That's fine! You're incurring a large perfomance tax though, if you don't. It's not nothing! Also, I'm calling bullshit that manual memory management lacks "safety and sanity". It's harder. You can screw it up. That doesn't mean that the default should be "pretend like machines have infinite RAM and we'll never run out". We're engineers, we make tradeoffs here all the time. BTW: I think it's funny that you're pretending like I'm a low level partisan or something that doesn't know the upsides of modern languages. My day job is writing typescript. My favorite language is python. But my previous two jobs were writing super low-level C++ code for 3D modelling and game development. I am entirely aware of how convenient a garbage collector is. I also don't think "helloworld" should compile to be 1MB. We should have standards.
  - pdimitar 7y ago
    > Honest question: have you ever actually done any (professional) development in C/C++ or Rust? I did in C and C++ and ran away screaming from them 12 years ago. I am learning Rust lately and I am actively rewriting several small-to-medium-sized projects that I wrote in Ruby or Elixir in the past. Accidentally, some of those projects have intersections with C/C++ code I wrote ~15 years ago and the Rust code is much more manageable, it's smaller, more understandable (although it has a pretty quirky syntax at places) and I am confident it will be easier to troubleshoot -- if my 18 years in the area are worth a penny. It doesn't carry invisible gotchas between the lines which is IMO the biggest win when you write a lower-level language. > Also, I'm calling bullshit that manual memory management lacks "safety and sanity". It's harder. You can screw it up. Correction: you WILL, INEVITABLY, screw up manual allocation, eventually. That's the crux of your discussion with the other guy here. The mental baggage you have to carry in your brain to avoid this is not worth it for 99% of the projects, at least those in my career. None of my customers and employers ever contracted for NASA or gaming studios, so reaching for C/C++ was a huge waste of human time, most of the time. If you have to write an embedded OS or there's absolutely no way to use Go or Rust to interface with a hardware piece that still has no driver -- and you are the one writing it -- sure, C/C++ are still a good choice (although I do wonder for how much longer; Zig and Rust look better and better with time but I imagine LLVM still has to improve a lot so Rust is useful for OS/driver development). If not, using literally everything else on the spectrum -- from Rust to Python/PHP/Ruby/Elixir/JS -- will work fine. > That doesn't mean that the default should be "pretend like machines have infinite RAM and we'll never run out". We're engineers, we make tradeoffs here all the time. I don't think anyone here said that but I haven't scanned the whole thread yet. You are indeed fighting an [extreme] straw-man in my eyes as well. > I am entirely aware of how convenient a garbage collector is. I also don't think "helloworld" should compile to be 1MB. We should have standards. Now we're getting somewhere! :) We absolutely should be having standards. The problem is sadly very common: everybody is like "my MacBook could handle Python's runtime inefficiency so meh to you old man yelling at cloud, we got work to do". IMO all programming languages should have a natural way to sink to the bottom of popularity if their runtimes are not improved over time. I am a good example of how people should pick their tech (given no firm requirements from employers, of course). I tried several dynamic languages and made a pick based on my productivity, the helpfulness of the community, the average quality of the libraries, and the technical prowess of the runtime. I do wish it had a shorter bootstrap time but hey, it's specifically made for servers so I can swallow it. On the other end of the spectrum, I'd like to make a comeback in the very fast low[-ish] level languages so I am learning Rust. I know I can gain extra runtime speed (and maybe memory efficiency but that's not a given) if I go back to C and C++ but I'd like to balance out productivity with stress and overall ability to get shit done. And especially important: not join tribes that yell "real men use C++!", I am sick of that crap. --- I don't think you and the other guy actually disagreed but kind of got hung up on a few minutiae. I also believe we indeed should have standards. (Which means software like Slack should not be used at all.) But we all know that writing compilers and optimizers is pretty damn hard.