5 ms·

TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with g

TL;DR: "[Coding perfectly and anticipating any possible change to how the tools work] are not reasonable expectations of a human being. We need languages with guard rails to protect against these kinds of errors." I definitely agree with this. And it also applies to a lot more than what the article is focused on (low-level security). It seems that right now the entire programming ecosystem seems to jump to "you just don't understand it" rather than "this should be more intuitive, or at least safer by design."

DannyB2 8y ago
There are several quasi-related variations. Arguments against higher level languages and abstractions. Examples: If you have to use a garbage collected language (eg, just about any modern language) it's because you're too stupid to know how to manage memory properly. [ various arguments against type safe languages, turning runtime errors into compile time errors ] Higher level languages and abstractions are just bloat. [or are too bloated, etc] Managed language runtime systems are too [ big | expensive | bloated | slow ] etc. (eg, the Java runtime, or .NET runtime, to a degree also Python, JavaScript, Lisp(s), etc) Counter arguments: Any sufficiently complex program will need the managed runtime, garbage collection, abstractions, type safety, etc. Greenspun's tenth rule: (https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. We could just write everything in assembly language, er, . . . um . . no, in hex code. And key it into the front of the machine on toggle switches with blinking lights. We could! Yes, really! So why aren't we? Why isn't, say, LibreOffice written in assembly language? I use high level languages, runtime systems, GC, etc because I'm not optimizing for cpu cycles and bytes. I'm optimizing for DOLLARS. A long time ago, in a galaxy far, far away, computer hardware was the most expensive resource. Today developer time is the most expensive resource. Everybody is happy to have their word processor upgrade a year sooner even if it means it uses a mere extra 500 MB of memory.
- alexanderdmitri 8y ago
  The devil is in the details usually here. Bloat can absolutely affect your bottomline in many ways.
  - DannyB2 8y ago
    One man's 'bloat' is another man's features. Consider both Microsoft Word and Notepad. Which is more bloated? Which is more light weight? Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc? Which has fewer features? People usually complaining about 'bloat' in a high level language or its runtime are really complaining about features that they either don't use, don't understand, or don't even realize are there.
    - alexanderdmitri 8y ago
      > Which is more bloated? Microsoft Word > Which is more light weight? Notepad > Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc? Microsoft Word > Which has fewer features? Notepad Users who are complaining about bloat are usually complaining about either application performance, ease of use and basic task completion complexity and/or general cluttering of the UI. Longer than expected load times can lead users to believe an application is bloated as well. It's true that all these things might be caused by something other than bloat, but these are typical repercussions of adding general cruft and also these tend to be design decisions and implementation details separate from the feature that the bloat was added for. Developers complaining about bloat (not the ones on HN giving a critique of a github repo after browsing it for a couple minutes, but the ones who are actually knee deep in source code trying to meet a deadline for a specific feature or bug fix and to whom the bloat is literally a gravity well affecting their development pace and agility) are usually referring to previous development cycles that they believe unnecessarily introduced complex libraries for simple tasks or outsourced application logic to dependencies that are not under control of the in-house development that have unnecessarily made the code base unwieldy and created more rotten code overall from a maintainability/extensibility vantage. In both these cases, a good early signal of detrimental bloat would be someone taking out a PR that introduces 500MB to the application. Justifying it as I'm maximizing for DOLLARS makes me think of someone who just won the lottery deciding that as a result of their net worth increasing a thousand fold, they're going to start willingly paying 1000x the price for things and also buy 1000x the amount of things. Should anyone try to convince them of how this logic is going to work out (perhaps someone stuck behind them in line at the store as they ring out the tens of thousands of grocery items, each of which provides a special value most people don't use, understand, or even realize is edible), the lottery winner calmly explains to the well-meaning individual (who happens to have just as high a net worth as the lottery winner it turns out but has achieved this over time and will have a higher net worth going forward from here) that perhaps this well-meaning simpleton just don't realize how much money has just been won. And sure, an application like Microsoft Word that has been actively developed for more than 35 years will likely have bloat, especially when maintained to preserve backward compatibility. There's a statistical minimum in this regard. Whether or not the bloat is as bad as it needs to be is another thing. If the development team behind Word has simply been adding 500MB here and 500MB there and defending it with "we're not going to write the new features in assembly" or "this helps me as a programmer be more productive" or "this source modification is so large because of all the features you don't know about" or "what?! we're not in North Korea" or all of the above, they are 100% creating more work for themselves and this extra work definitely comes with a price tag. In fact, without really have much insight into the general culture or incentives over there, it's a reasonable bet they've taken steps to prevent developers from introducing tech debt and bloat with this sort of defense. Either way, it's weird to point to Microsoft Word's accumulated debt and overall decreasing performance specs as a result of multiple decades of evolving development as a reason to dismiss bloat as a non-issue. If I were a career non-bloat advocate, traveling from university to university on my canola oil powered moped I'd be pointing to Word as a reason to take bloat seriously and a reminder that the feature your adding now will likely be on the opposing force of a future person's battle with bloat and you should fight it with all the flower power you can muster or risk them tracking you down with a vendetta after they realize it was your commit making their job shit right now.
P_I_Staker 8y ago
I'm torn on this, because while we can always do better, sometimes there's things you just gotta know; this is the best we can do, so far. There's also lots of lazy programmers, that think everything should be easy and intuitive, when in reality they need to do more to understand the tools they have and hone their craft. I refuse to call them bad, because I think most people can reach expert level. Maybe not master or grandmaster, but experts would do.
- zaphar 8y ago
  Wanting better, safer, and more intuitive tools does not presume that people don't and shouldn't grow. Even with the tools there are plenty of bugs/challenging problems in just understanding and correctly expressing the problem domain in those safe and intuitive tools. The two positions are not incompatible.
  - P_I_Staker 8y ago
    Completely agree. That said, we have what we have, and people tend to be very idealistic about these things (favoring one vs. the other). Example, I use Git and Make in C. Others claim "this is the future, everything should be intuitive and graphical". I honestly don't see a way forward for either technology to be more intuitive; a better Git GUIs would be a plus for new users, but that's just the tip of the iceberg. I'm not the type that think "you must do everything at the command line, or you're too stupid to be a decent programmer"; those people do exist. On the flip side, complaints about not being intuitive enough might be met with a shrug from me. Do we really want to use Eclipse and SVN, because you don't want to learn how to use the tooling? (of course, I'd never actually put it like that) Personally, I don't think it's a better solution. I'm not holding my breath for a complete overhaul of Git / Make, and am wary of trying something more novel for now.
    - zaphar 8y ago
      Sure work doesn't need to completely halt while we wait for a perfect solution. But I think that where there are safer and more intuitive tools we should use and promote them.
madhadron 8y ago
> It seems that right now the entire programming ecosystem seems to jump to "you just don't understand it" rather than "this should be more intuitive, or at least safer by design." Stockholm syndrome? Hazing? Fear that skills that moat off expertise will be devalued? Saying that I should do something that the computer can do for me is telling me that my time is not worth anything. It's pretty insulting.

DannyB2 8y ago

There are several quasi-related variations. Arguments against higher level languages and abstractions. Examples: If you have to use a garbage collected language (eg, just about any modern language) it's because you're too stupid to know how to manage memory properly. [ various arguments against type safe languages, turning runtime errors into compile time errors ] Higher level languages and abstractions are just bloat. [or are too bloated, etc] Managed language runtime systems are too [ big | expensive | bloated | slow ] etc. (eg, the Java runtime, or .NET runtime, to a degree also Python, JavaScript, Lisp(s), etc) Counter arguments: Any sufficiently complex program will need the managed runtime, garbage collection, abstractions, type safety, etc. Greenspun's tenth rule: (https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. We could just write everything in assembly language, er, . . . um . . no, in hex code. And key it into the front of the machine on toggle switches with blinking lights. We could! Yes, really! So why aren't we? Why isn't, say, LibreOffice written in assembly language? I use high level languages, runtime systems, GC, etc because I'm not optimizing for cpu cycles and bytes. I'm optimizing for DOLLARS. A long time ago, in a galaxy far, far away, computer hardware was the most expensive resource. Today developer time is the most expensive resource. Everybody is happy to have their word processor upgrade a year sooner even if it means it uses a mere extra 500 MB of memory.

alexanderdmitri 8y ago
The devil is in the details usually here. Bloat can absolutely affect your bottomline in many ways.
- DannyB2 8y ago
  One man's 'bloat' is another man's features. Consider both Microsoft Word and Notepad. Which is more bloated? Which is more light weight? Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc? Which has fewer features? People usually complaining about 'bloat' in a high level language or its runtime are really complaining about features that they either don't use, don't understand, or don't even realize are there.
  - alexanderdmitri 8y ago
    > Which is more bloated? Microsoft Word > Which is more light weight? Notepad > Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc? Microsoft Word > Which has fewer features? Notepad Users who are complaining about bloat are usually complaining about either application performance, ease of use and basic task completion complexity and/or general cluttering of the UI. Longer than expected load times can lead users to believe an application is bloated as well. It's true that all these things might be caused by something other than bloat, but these are typical repercussions of adding general cruft and also these tend to be design decisions and implementation details separate from the feature that the bloat was added for. Developers complaining about bloat (not the ones on HN giving a critique of a github repo after browsing it for a couple minutes, but the ones who are actually knee deep in source code trying to meet a deadline for a specific feature or bug fix and to whom the bloat is literally a gravity well affecting their development pace and agility) are usually referring to previous development cycles that they believe unnecessarily introduced complex libraries for simple tasks or outsourced application logic to dependencies that are not under control of the in-house development that have unnecessarily made the code base unwieldy and created more rotten code overall from a maintainability/extensibility vantage. In both these cases, a good early signal of detrimental bloat would be someone taking out a PR that introduces 500MB to the application. Justifying it as I'm maximizing for DOLLARS makes me think of someone who just won the lottery deciding that as a result of their net worth increasing a thousand fold, they're going to start willingly paying 1000x the price for things and also buy 1000x the amount of things. Should anyone try to convince them of how this logic is going to work out (perhaps someone stuck behind them in line at the store as they ring out the tens of thousands of grocery items, each of which provides a special value most people don't use, understand, or even realize is edible), the lottery winner calmly explains to the well-meaning individual (who happens to have just as high a net worth as the lottery winner it turns out but has achieved this over time and will have a higher net worth going forward from here) that perhaps this well-meaning simpleton just don't realize how much money has just been won. And sure, an application like Microsoft Word that has been actively developed for more than 35 years will likely have bloat, especially when maintained to preserve backward compatibility. There's a statistical minimum in this regard. Whether or not the bloat is as bad as it needs to be is another thing. If the development team behind Word has simply been adding 500MB here and 500MB there and defending it with "we're not going to write the new features in assembly" or "this helps me as a programmer be more productive" or "this source modification is so large because of all the features you don't know about" or "what?! we're not in North Korea" or all of the above, they are 100% creating more work for themselves and this extra work definitely comes with a price tag. In fact, without really have much insight into the general culture or incentives over there, it's a reasonable bet they've taken steps to prevent developers from introducing tech debt and bloat with this sort of defense. Either way, it's weird to point to Microsoft Word's accumulated debt and overall decreasing performance specs as a result of multiple decades of evolving development as a reason to dismiss bloat as a non-issue. If I were a career non-bloat advocate, traveling from university to university on my canola oil powered moped I'd be pointing to Word as a reason to take bloat seriously and a reminder that the feature your adding now will likely be on the opposing force of a future person's battle with bloat and you should fight it with all the flower power you can muster or risk them tracking you down with a vendetta after they realize it was your commit making their job shit right now.

P_I_Staker 8y ago

I'm torn on this, because while we can always do better, sometimes there's things you just gotta know; this is the best we can do, so far. There's also lots of lazy programmers, that think everything should be easy and intuitive, when in reality they need to do more to understand the tools they have and hone their craft. I refuse to call them bad, because I think most people can reach expert level. Maybe not master or grandmaster, but experts would do.

zaphar 8y ago
Wanting better, safer, and more intuitive tools does not presume that people don't and shouldn't grow. Even with the tools there are plenty of bugs/challenging problems in just understanding and correctly expressing the problem domain in those safe and intuitive tools. The two positions are not incompatible.
- P_I_Staker 8y ago
  Completely agree. That said, we have what we have, and people tend to be very idealistic about these things (favoring one vs. the other). Example, I use Git and Make in C. Others claim "this is the future, everything should be intuitive and graphical". I honestly don't see a way forward for either technology to be more intuitive; a better Git GUIs would be a plus for new users, but that's just the tip of the iceberg. I'm not the type that think "you must do everything at the command line, or you're too stupid to be a decent programmer"; those people do exist. On the flip side, complaints about not being intuitive enough might be met with a shrug from me. Do we really want to use Eclipse and SVN, because you don't want to learn how to use the tooling? (of course, I'd never actually put it like that) Personally, I don't think it's a better solution. I'm not holding my breath for a complete overhaul of Git / Make, and am wary of trying something more novel for now.
  - zaphar 8y ago
    Sure work doesn't need to completely halt while we wait for a perfect solution. But I think that where there are safer and more intuitive tools we should use and promote them.

madhadron 8y ago

> It seems that right now the entire programming ecosystem seems to jump to "you just don't understand it" rather than "this should be more intuitive, or at least safer by design." Stockholm syndrome? Hazing? Fear that skills that moat off expertise will be devalued? Saying that I should do something that the computer can do for me is telling me that my time is not worth anything. It's pretty insulting.