5 ms·

So.. what you're trying to highlight is that a language is supposed to make up for the incompetence of the person using it?

yakshaving_jgt 8y ago
Yes. Humans are fallible. That is an immutable truth. There’s no great wisdom in relying on human discipline alone to produce reliable software.
coldtea 8y ago
Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it could refuse while allowing devs to express the same features, and that results in bugs is a mistake in the language (e.g. the sorry state of strings in C).
- kristopolous 8y ago
  Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes. I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd. But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never. Instead it leads to larger, less maintainable, more convoluted messes that have to be trashed quicker. Giant ceremonial cargo cult style monstrosities with huge circuitous logic - 4, 5, maybe 6 layers, a router calling a controller, calling a service, calling a provider, calling an event model, which runs a single if statement ... as if that's how we protect ourselves against incompetence. These approaches just lead to wasteful projects where they end up rewriting the whole thing in whatever the framework/language de jour is instead of writing easily maintainable, quickly understandable code that's designed to work for the next 10 years. I've talked to many programmers who are embarrassed by the language they are using ... wtf is that?! They've turned programming into fast fashion. Then people like to ask what someone's favorite language is, usually when they first meet them, as a social cue, as if we are a bunch of highschool kids following pop music. I mean what on earth... we're supposed to building the future here, not running around like a bunch of spastic fanboys from platform to platform, just to mess everything up all over again in bold new ways using slightly different syntax. The best thing to do is give people the least abstract thing with the fewest conformity requirements ... essentially make it open ended and then the messes are easier to spot and easier to fix. You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) Anyway, new shiny fancy tools with GoF buzzwords won't ever fix incompetence, it'll only make it worse.
  - coldtea 8y ago
    >Incompetent people will create incompetent things regardless of the tool Which is neither here nor there. For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them. If only it was just "incompetent people" that made mistakes... >But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never. You weren't looking hard enough. Every day millions of programmers don't make "buffer overflow" errors for example, that otherwise they'd have made, because they work in languages that don't allow them. And they'd have made those mistakes regardless of their programming chops. The best programmers, people that run circles around you and me, still make those mistakes.
    - kristopolous 8y ago
      Those mistakes aren't easy to spot or easy to fix. It's about giving code sunlight so that action at a distance and other kinds of magic don't hide errors making them harder to find, get in your way of fixing them, making reproducibility a mess and confirmation simply guesswork. Its the restrictive design trend of crippling languages which needlessly prevents the sunlight effect from happening along with "information hiding principle" gone completely amuck with the information successfully hidden in dozens of innocently named files with listeners, observers, watchers, triggers and who knows what else being mysteriously called based on reflective programming so not even grep will help you. Static code analysis and seamless navigation is totally a thing of the past. Instead, the errors will have the stack of the error handler and that's it. The debugger is useless because stepping through the code is 98% scaffolding. All these fancy tools bludgeoning any introspection or diagnostic system so the only remaining workable debug system is printing debug variables and rerunning the code like I'm programming on a TI-81 (only that had debug and release run modes...features I can usually only dream of these days) Progress! Welcome to 2019! It's crazy. This isn't how maintainable code is written
      - svsucculents 8y ago
- furicane 8y ago
  We created higher level languages to reduce time spent coding. We wouldn't be using assembly. It appears that we think about different terms when visualizing what "incompetent" means. We create languages to tackle different sets of problems, and we want to minimize human error - that part, I believe, we can agree on. However, if you perform "SELECT * FROM mytable" (table grows indefinitely) and then sort / limit in the language and not database - you're incompetent, you simply lack knowledge and you didn't even think abstractly what can happen by doing so. There's no language out there that can teach you "right tool for the job" or "keep it simple" or "should I do it, maybe there's another way, did someone else have this problem?", no matter what wizard creates it. We will never weed out incompetent people by creating languages and a language shouldn't cater to a moron.
- svsucculents 8y ago
  Totally disagree with this parental assessment of a language. It certainly doesn't apply to spoken languages or most ideal communication modalities. I think you want to fix your problem: which isn't a problem for someone else. See this everywhere on this site: SV kultur and the catch22 pronouncements of the correction generation.
scarface74 8y ago
Exactly. That’s why most languages, for example have reasonable semantics for strings that don’t allow you to copy a string, overwrite memory and corrupt the call stack. There is a reason most web sites don’t use C.

yakshaving_jgt 8y ago

Yes. Humans are fallible. That is an immutable truth. There’s no great wisdom in relying on human discipline alone to produce reliable software.

coldtea 8y ago

Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it could refuse while allowing devs to express the same features, and that results in bugs is a mistake in the language (e.g. the sorry state of strings in C).

kristopolous 8y ago
Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes. I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd. But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never. Instead it leads to larger, less maintainable, more convoluted messes that have to be trashed quicker. Giant ceremonial cargo cult style monstrosities with huge circuitous logic - 4, 5, maybe 6 layers, a router calling a controller, calling a service, calling a provider, calling an event model, which runs a single if statement ... as if that's how we protect ourselves against incompetence. These approaches just lead to wasteful projects where they end up rewriting the whole thing in whatever the framework/language de jour is instead of writing easily maintainable, quickly understandable code that's designed to work for the next 10 years. I've talked to many programmers who are embarrassed by the language they are using ... wtf is that?! They've turned programming into fast fashion. Then people like to ask what someone's favorite language is, usually when they first meet them, as a social cue, as if we are a bunch of highschool kids following pop music. I mean what on earth... we're supposed to building the future here, not running around like a bunch of spastic fanboys from platform to platform, just to mess everything up all over again in bold new ways using slightly different syntax. The best thing to do is give people the least abstract thing with the fewest conformity requirements ... essentially make it open ended and then the messes are easier to spot and easier to fix. You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) Anyway, new shiny fancy tools with GoF buzzwords won't ever fix incompetence, it'll only make it worse.
- coldtea 8y ago
  >Incompetent people will create incompetent things regardless of the tool Which is neither here nor there. For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them. If only it was just "incompetent people" that made mistakes... >But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never. You weren't looking hard enough. Every day millions of programmers don't make "buffer overflow" errors for example, that otherwise they'd have made, because they work in languages that don't allow them. And they'd have made those mistakes regardless of their programming chops. The best programmers, people that run circles around you and me, still make those mistakes.
  - kristopolous 8y ago
    Those mistakes aren't easy to spot or easy to fix. It's about giving code sunlight so that action at a distance and other kinds of magic don't hide errors making them harder to find, get in your way of fixing them, making reproducibility a mess and confirmation simply guesswork. Its the restrictive design trend of crippling languages which needlessly prevents the sunlight effect from happening along with "information hiding principle" gone completely amuck with the information successfully hidden in dozens of innocently named files with listeners, observers, watchers, triggers and who knows what else being mysteriously called based on reflective programming so not even grep will help you. Static code analysis and seamless navigation is totally a thing of the past. Instead, the errors will have the stack of the error handler and that's it. The debugger is useless because stepping through the code is 98% scaffolding. All these fancy tools bludgeoning any introspection or diagnostic system so the only remaining workable debug system is printing debug variables and rerunning the code like I'm programming on a TI-81 (only that had debug and release run modes...features I can usually only dream of these days) Progress! Welcome to 2019! It's crazy. This isn't how maintainable code is written
    - svsucculents 8y ago
furicane 8y ago
We created higher level languages to reduce time spent coding. We wouldn't be using assembly. It appears that we think about different terms when visualizing what "incompetent" means. We create languages to tackle different sets of problems, and we want to minimize human error - that part, I believe, we can agree on. However, if you perform "SELECT * FROM mytable" (table grows indefinitely) and then sort / limit in the language and not database - you're incompetent, you simply lack knowledge and you didn't even think abstractly what can happen by doing so. There's no language out there that can teach you "right tool for the job" or "keep it simple" or "should I do it, maybe there's another way, did someone else have this problem?", no matter what wizard creates it. We will never weed out incompetent people by creating languages and a language shouldn't cater to a moron.
svsucculents 8y ago
Totally disagree with this parental assessment of a language. It certainly doesn't apply to spoken languages or most ideal communication modalities. I think you want to fix your problem: which isn't a problem for someone else. See this everywhere on this site: SV kultur and the catch22 pronouncements of the correction generation.

scarface74 8y ago

Exactly. That’s why most languages, for example have reasonable semantics for strings that don’t allow you to copy a string, overwrite memory and corrupt the call stack. There is a reason most web sites don’t use C.