11 ms·

> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due

by avl999 6y ago

> the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1! Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix.

bird_monster 6y ago
> Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.
ZephyrBlu 6y ago
In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.
- cjfd 6y ago
  The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.
  - pansa2 6y ago
    > your program is only fully type checked when all code paths are executed. The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.
    - willtim 6y ago
      That is impossible with almost all non-trivial software. Testing proves only the presence of errors not their absence.
      - neillyons 6y ago
        > Testing proves only the presence of errors not their absence. I've never thought of it that way, but that totally makes sense.
    - cjfd 6y ago
      I am all for high test coverage. One should not underestimate the effort in that, though. Some time ago I covered some two thousand lines of code completely in tests. As in, all code paths, checking all side effects. Kind of an effort in the spirit of "dealing effectivly with legacy code" by Michael Feathers. They were quite non-trivial and it took me about two months. Doing such a thing may not always be feasible. Also if code is written by others they may have covered fewer code paths in tests than one would have liked. A type checker will check all code paths but the tests that your predecessor failed to write are not checking anything.
    - srean 6y ago
      You can think of the compiler for a statically typed language doing exactly that at runtime for a subset of potential errors -- the type errors. Some people claim that they never make them and they may well be correct. I do commit such errors so compiler is a friend, but a pedantic friend.
    - dkersten 6y ago
      I've worked with Python codebases that had very extensive test suites and I've still encountered many cases of bugs slipping through that a static type check would have caught. Its really hard to make sure tests are fully comprehensive. About the best you could do is generative property-based tests, but then the feedback loop is not great as it may take minutes, hours, days or weeks for a particular problem case to be generated, while the static check would have caught it at compile time or even interactively in your IDE. I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.
jcelerier 6y ago
having just spent an hour over vscode live share with a student who's learning javascript, I have a pretty good idea. But I've worked with people who saw all compiler errors as things of the devil and wanted to defer as much as possible to runtime.
- kungito 6y ago
  faculty helps students debug their code?? where?
  - jcelerier 6y ago
    I'm in france haha. why wouldn't you help a student who asks you kindly ?
    - xdavidliu 6y ago
      Parent is probably referring to situations where faculty are too busy researching, writing grants, or just plain don't feel like it, and tell students something like "go play with it" "look it up" "google it" "read the fudging manual" Of course, there are many great faculty who _do_ care greatly about teaching and always help students.
  - LandR 6y ago
    At my Uni we had students from higher years do volunteer time during lab sessions for lower year students. You would just wander around the lab helping random people who were stuck. Sometimes there would be some proffessors there too to help you out.
dan-robertson 6y ago
I feel like it probably isn’t worthwhile to litigate the merits of static typing every time there is a HN post that’s vaguely adjacent to the topic. For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soon, one in python and one in ocaml. Perhaps that will provide a datapoint about learning the languages but maybe there will just be a lot of selection bias or library or environment or teacher differences. And how easy it is to learn a language probably isn’t the main datapoint to care about anyway.
- Guthur 6y ago
  It would if python actually encouraged runtime coding. In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.
  - sfg 6y ago
    So, Common Lisp and Smalltalk? Any others?
    - Guthur 6y ago
      I'd imagine some Scheme environments are good as well, like Dr Racket. Unfortunately the same amount of effort that has been applied to static type checking has not been applied to dynamic language environments. It would have been very interesting to see what could be possible with the more advancement.
    - cjallen88 6y ago
      Factor for sure
  - andrekandre 6y ago
    yep, i was going to say the same thing, the biggest issue with dynamic vs static is maybe people are missing the point: dynamic languages (like smalltalk) were designed for live coding where the results are immediate, when that is broken and coding is done in a "dead" environment of course dynamic typing will cause problems that arent caught until runtime... but the original idea was one shouldnt have had to wait until runtime in the first place!

by avl999 6y ago

bird_monster 6y ago

> Well I can't imagine how much more annoyed they'd be when using an interpreted language which lets the code run just fine but then fails at runtime in mysterious and subtle ways requiring hours of manually scanning though code and print statements when the compiler would have caught a decent subset of those errors with helpful messages about the exact line they need to fix. You cannot get mad at errors you don't know about. Also letting the user find and report the error allows you to mark your tickets "done" and move on, which makes management happy.

ZephyrBlu 6y ago

In my experience, you quickly develop an intuition for where things are going wrong with interpreted languages. Ex: "Oh, cannot access property x of undefined? Something must be going wrong in y object" Python definitely feels a lot more helpful than JS though. Can't speak for other interpreted languages like Ruby.

cjfd 6y ago
The thing is, though, that you mostly only get errors for code that is actually executed. So, your program is only fully type checked when all code paths are executed. In the case of python one can ameliorate this situation a bit by using mypy. At my job I see very often code being broken because, e.g., the signature of a function was changed but not in all places and so on. Now somebody will say that the IDE can solve that but these colleagues who are regularly breaking the code are actually using IDEs and it somehow still does not help. I have come to think that code that is not compiled and/or otherwise type checked is just not very serious and certainly not worthy of production environments.
- pansa2 6y ago
  > your program is only fully type checked when all code paths are executed. The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.
  - willtim 6y ago
    That is impossible with almost all non-trivial software. Testing proves only the presence of errors not their absence.
    - neillyons 6y ago
      > Testing proves only the presence of errors not their absence. I've never thought of it that way, but that totally makes sense.
  - cjfd 6y ago
    I am all for high test coverage. One should not underestimate the effort in that, though. Some time ago I covered some two thousand lines of code completely in tests. As in, all code paths, checking all side effects. Kind of an effort in the spirit of "dealing effectivly with legacy code" by Michael Feathers. They were quite non-trivial and it took me about two months. Doing such a thing may not always be feasible. Also if code is written by others they may have covered fewer code paths in tests than one would have liked. A type checker will check all code paths but the tests that your predecessor failed to write are not checking anything.
  - srean 6y ago
    You can think of the compiler for a statically typed language doing exactly that at runtime for a subset of potential errors -- the type errors. Some people claim that they never make them and they may well be correct. I do commit such errors so compiler is a friend, but a pedantic friend.
  - dkersten 6y ago
    I've worked with Python codebases that had very extensive test suites and I've still encountered many cases of bugs slipping through that a static type check would have caught. Its really hard to make sure tests are fully comprehensive. About the best you could do is generative property-based tests, but then the feedback loop is not great as it may take minutes, hours, days or weeks for a particular problem case to be generated, while the static check would have caught it at compile time or even interactively in your IDE. I don't hate dynamic languages, but this is a pretty major weak spot for them, in my personal opinion, and one that's bitten me a number of times.

jcelerier 6y ago

having just spent an hour over vscode live share with a student who's learning javascript, I have a pretty good idea. But I've worked with people who saw all compiler errors as things of the devil and wanted to defer as much as possible to runtime.

kungito 6y ago
faculty helps students debug their code?? where?
- jcelerier 6y ago
  I'm in france haha. why wouldn't you help a student who asks you kindly ?
  - xdavidliu 6y ago
    Parent is probably referring to situations where faculty are too busy researching, writing grants, or just plain don't feel like it, and tell students something like "go play with it" "look it up" "google it" "read the fudging manual" Of course, there are many great faculty who _do_ care greatly about teaching and always help students.
- LandR 6y ago
  At my Uni we had students from higher years do volunteer time during lab sessions for lower year students. You would just wander around the lab helping random people who were stuck. Sometimes there would be some proffessors there too to help you out.

dan-robertson 6y ago

I feel like it probably isn’t worthwhile to litigate the merits of static typing every time there is a HN post that’s vaguely adjacent to the topic. For the amount people care about it, there isn’t much evidence in either direction. And most studies that do exist are limited to small programs typically written by novices. Yale’s Singapore campus are going to be running two instances of the same course in parallel soon, one in python and one in ocaml. Perhaps that will provide a datapoint about learning the languages but maybe there will just be a lot of selection bias or library or environment or teacher differences. And how easy it is to learn a language probably isn’t the main datapoint to care about anyway.

Guthur 6y ago
It would if python actually encouraged runtime coding. In my opinion dynamic programmers need to embrace the runtime environment and use it as part of their development methodology. Unfortunately most popular dynamic languages have woeful runtime environments.
- sfg 6y ago
  So, Common Lisp and Smalltalk? Any others?
  - Guthur 6y ago
    I'd imagine some Scheme environments are good as well, like Dr Racket. Unfortunately the same amount of effort that has been applied to static type checking has not been applied to dynamic language environments. It would have been very interesting to see what could be possible with the more advancement.
  - cjallen88 6y ago
    Factor for sure
- andrekandre 6y ago
  yep, i was going to say the same thing, the biggest issue with dynamic vs static is maybe people are missing the point: dynamic languages (like smalltalk) were designed for live coding where the results are immediate, when that is broken and coding is done in a "dead" environment of course dynamic typing will cause problems that arent caught until runtime... but the original idea was one shouldnt have had to wait until runtime in the first place!