7 ms·

The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' cul

The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral. It was not until an early aviation safety pioneer came up with a demonstration on the ground (something like a spinning chair and blindfold - I forget the details) that pilots who went through the demonstration were shocked to discover they "fell for" the physical illusion they believed they were immune to. I feel like programming is in the same state today. Especially the more C/C++ code I see in my career: I'm absolutely convinced humans should just not expected to manually manage some of the things they try to do now.

_bxg1 8y ago
C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)
- AdeptusAquinas 8y ago
  How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.
  - cm2187 8y ago
    Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.
    - core-questions 8y ago
      I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help enough to be worth it?
      - dunefox 8y ago
        Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
        dictum 8y ago
        The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
        mannykannot 8y ago
        If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.
      - SatvikBeri 8y ago
        I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.
  - _bxg1 8y ago
    Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns. Complex JavaScript codebases used to mostly be this way, but in recent years the JavaScript community has seen a huge influx of new, inexperienced programmers. There are obvious downsides to this, but one upside is that they don't have the pretense of being able to do everything perfectly without help, making them less resistant to things like TypeScript.
    - AdeptusAquinas 8y ago
      Being very careful not to start a flamewar, my armchair analysis is the opposite: JS has seen a large influx of serious backend developers, who generally have no time for silly arguments against static typing.
      - geoelectric 8y ago
        My guess is it's some of both, really. There's the old saw about levels of SWE expertise: * Beginner: doesn't know much and knows it * Intermediate: knows a lot, hasn't lived with the consequences * Expert: knows a lot, including when not to use what they know The two comments here seem to be articulating the community shifting between I->B and I->E respectively. I think it's safe to say we have both a maturing developer base and a huge influx of newbies. That intermediate "look what I can do!" stage still exists, probably as much as ever, but is being professionally tempered by the caution inherent in the other two cohorts. The Intermediate stage is the most fun to watch, though, and probably a lot of what drives innovation. The coolest projects come from people who ostensibly should've known better than to try that thing.
- taeric 8y ago
  Oddly, most of the complaints against lisp just don't acknowledge that they have actually had type safety for a long long time. Not just in racket's types. But common lisp has had valid compilation steps for a long long time.
  - brundolf 8y ago
    In fairness, at my company we use a custom dialect of CL which does not have a type system, so I may not have enough perspective to make broad statements about the Lisp community. Though, intuitively, I'd think that in a language all about dynamic data structures and self-modifying code, static analysis would be really hard. But I may just be ignorant in this area.
    - taeric 8y ago
      I can't claim a lack of ignorance in this area. It is always baffling when you see just what some of the older lisp machines were capable of. Too many posts reduce this to some sort of "magic of lisp" message. Which is certainly fun, in many ways. However, I think most of it is just a lot of hard work that was done by folks. Much of which will never be considered by the rest of us, almost solely on lack of information. So, yes, I imagine in many ways it is harder. Doesn't make it impossible, though. And indeed, most type checking can be almost trivially done. As an example, typechecking the arguments to a format command. Trivially easy in most invocations. Only when people do build up dynamic programs is this hard. Thing is, those programs are hard to even think of, so most of us don't write them.
- dkarl 8y ago
  It's hard to stereotype the "C/C++ community." The C++ community popularized RAII for safer management of mutex locks, reference counts, and other resources; smart pointers for null checking; and other ergonomic improvements motivated by the knowledge that getting those things right in plain C required an unrealistic and/or wasteful level of vigilance. When I encountered Rust I immediately recognized the same desire for safety and protection that motivated usage of RAII in C++. And, funnily enough, back in my C++ days I remember dabbling in Common Lisp and loving that there were macros that achieved similar results.
  - kazinator 8y ago
    I put a form of RAII into TXR Lisp, unified with GC finalization: https://news.ycombinator.com/item?id=13937660 https://news.ycombinator.com/item?id=13937660
glhaynes 8y ago
[drifting off-topic…] This article about early aviation covers what you're talking about and I found to be a great read: https://www.theatlantic.com/past/docs/unbound/langew/turn.htm https://www.theatlantic.com/past/docs/unbound/langew/turn.ht...
godelski 8y ago
> (something like a spinning chair and blindfold - I forget the details) The test they do is blindfold you and spin you in a chair. But they switch directions and you have to point your thumbs in the direction your are spinning. It is possible to determine which way you are, but it is freaking difficult and really you're probably cheating by knowing the initial spin direction and keeping track of sharp decelerations (change in direction). Basically it is simulating how you might be spinning in clouds and not be aware of it. Unlike the chair simulation these spins are more gradual/subtle and you're not paying extremely close attention (your attention SHOULD be elsewhere, i.e. flying the plane).

_bxg1 8y ago

C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)

AdeptusAquinas 8y ago
How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.
- cm2187 8y ago
  Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.
  - core-questions 8y ago
    I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing". Do they really help enough to be worth it?
    - dunefox 8y ago
      Well, I remember times when my program crashed because I tried to add a dictionary and an integer - so, yeah, they do help.
      - dictum 8y ago
        The problem lies on enough: the overhead of static typing has to be lower, in the lifespan of a project, to the time spent fixing bugs like this one. (Other things, like liability from bugs and crashes, may give an edge to static typing. The age-old debate is how much)
        mannykannot 8y ago
        If you know what sorts of data your variables denote and your functions take and return, being explicit about it is not much of a burden for the benefits it brings.
    - SatvikBeri 8y ago
      I regularly work in a statically typed language (Scala) and a dynamic/gradually typed language (Python.) I never find that static types force me to plan more – it's pretty easy to change them on the fly. I frequently find that static types let the IDE highlight an error the second I write it, instead of waiting until running tests. And every codebase I've worked with has taken at least a few minutes to run tests (and sometimes much longer), so this is a pretty substantial savings. Or in other words, static types free me up to be more creative, by requiring me to spend less energy & attention on certain types of errors that were common before.
- _bxg1 8y ago
  Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns. Complex JavaScript codebases used to mostly be this way, but in recent years the JavaScript community has seen a huge influx of new, inexperienced programmers. There are obvious downsides to this, but one upside is that they don't have the pretense of being able to do everything perfectly without help, making them less resistant to things like TypeScript.
  - AdeptusAquinas 8y ago
    Being very careful not to start a flamewar, my armchair analysis is the opposite: JS has seen a large influx of serious backend developers, who generally have no time for silly arguments against static typing.
    - geoelectric 8y ago
      My guess is it's some of both, really. There's the old saw about levels of SWE expertise: * Beginner: doesn't know much and knows it * Intermediate: knows a lot, hasn't lived with the consequences * Expert: knows a lot, including when not to use what they know The two comments here seem to be articulating the community shifting between I->B and I->E respectively. I think it's safe to say we have both a maturing developer base and a huge influx of newbies. That intermediate "look what I can do!" stage still exists, probably as much as ever, but is being professionally tempered by the caution inherent in the other two cohorts. The Intermediate stage is the most fun to watch, though, and probably a lot of what drives innovation. The coolest projects come from people who ostensibly should've known better than to try that thing.
taeric 8y ago
Oddly, most of the complaints against lisp just don't acknowledge that they have actually had type safety for a long long time. Not just in racket's types. But common lisp has had valid compilation steps for a long long time.
- brundolf 8y ago
  In fairness, at my company we use a custom dialect of CL which does not have a type system, so I may not have enough perspective to make broad statements about the Lisp community. Though, intuitively, I'd think that in a language all about dynamic data structures and self-modifying code, static analysis would be really hard. But I may just be ignorant in this area.
  - taeric 8y ago
    I can't claim a lack of ignorance in this area. It is always baffling when you see just what some of the older lisp machines were capable of. Too many posts reduce this to some sort of "magic of lisp" message. Which is certainly fun, in many ways. However, I think most of it is just a lot of hard work that was done by folks. Much of which will never be considered by the rest of us, almost solely on lack of information. So, yes, I imagine in many ways it is harder. Doesn't make it impossible, though. And indeed, most type checking can be almost trivially done. As an example, typechecking the arguments to a format command. Trivially easy in most invocations. Only when people do build up dynamic programs is this hard. Thing is, those programs are hard to even think of, so most of us don't write them.
dkarl 8y ago
It's hard to stereotype the "C/C++ community." The C++ community popularized RAII for safer management of mutex locks, reference counts, and other resources; smart pointers for null checking; and other ergonomic improvements motivated by the knowledge that getting those things right in plain C required an unrealistic and/or wasteful level of vigilance. When I encountered Rust I immediately recognized the same desire for safety and protection that motivated usage of RAII in C++. And, funnily enough, back in my C++ days I remember dabbling in Common Lisp and loving that there were macros that achieved similar results.
- kazinator 8y ago
  I put a form of RAII into TXR Lisp, unified with GC finalization: https://news.ycombinator.com/item?id=13937660 https://news.ycombinator.com/item?id=13937660

glhaynes 8y ago

[drifting off-topic…] This article about early aviation covers what you're talking about and I found to be a great read: https://www.theatlantic.com/past/docs/unbound/langew/turn.htm https://www.theatlantic.com/past/docs/unbound/langew/turn.ht...

godelski 8y ago

> (something like a spinning chair and blindfold - I forget the details) The test they do is blindfold you and spin you in a chair. But they switch directions and you have to point your thumbs in the direction your are spinning. It is possible to determine which way you are, but it is freaking difficult and really you're probably cheating by knowing the initial spin direction and keeping track of sharp decelerations (change in direction). Basically it is simulating how you might be spinning in clouds and not be aware of it. Unlike the chair simulation these spins are more gradual/subtle and you're not paying extremely close attention (your attention SHOULD be elsewhere, i.e. flying the plane).