4 ms·

> I tend to think of Javascript as the language that fulfills the promises that BASIC never did I taught myself BASIC when I was 7 when I didn't know what a pr

> I tend to think of Javascript as the language that fulfills the promises that BASIC never did I taught myself BASIC when I was 7 when I didn't know what a programming language was. I've been programming JS for 25 years and I still commonly can't predict what the behavior of some aspects of my code is going to be, or what the state of the application is at a given point, until I try/run it.

kamranjon 4y ago
"4" + 4 = "44" "44" - 4 = 40
- deleted 4y ago
  [deleted]
- a_wild_dandan 4y ago
  In other words: play stupid games, win stupid prizes. ;)
  - kamranjon 4y ago
    Haha yes, most oddities in JS are a result of the language allowing you to play stupid games - many languages would just throw an error here (heck even ruby does). I discovered this strangeness when I forgot to parseFloat on a string and things kept humming along as if nothing was wrong, until I did some addition and things grew exponentially.
    - cxr 4y ago
      > many languages would just throw an error here Some do. Many don't. I have a feeling that most people who say this sort of thing mean "Python" and assume that that's the norm. (The "heck even ruby does" remark def. reinforces that.) Can you name any that do that aren't dynamic languages?
      - kamranjon 4y ago
        C, Rust, Go. There are probably many more. But I think you might be overall misinterpreting my original comment. I was responding to someone who said they still commonly find unpredictable behavior in Javascript that they were unaware of after using it for years. I just responded with something I recently discovered in a similar vein, and you appeared to take it as some sort of statement about Javascript as a language. I really enjoy Javascript, and I was really just highlighting a recent example I ran into that gave me the same feeling conveyed in the original comment I was responding to.
        cxr 4y ago
        C does not throw an error. C does not even have the infrastructure to throw errors. The closest thing are signals, and it doesn't use those for this issue. Go is similar to C, C#, Java, JS, etc in the sense that if anything is to be done about it then the expectation is for it to be flagged as part of typechecking before runtime. I don't have enough experience with Rust, but I'd be willing to bet that it doesn't do what you're saying, either.
        kamranjon 4y ago
        C throws a warning, because you need to manually cast to get expected behavior. But it does not behave the same as javascript, try it yourself, you will not get "44" when you add "4" to 4. Go does not support implicit type conversion, so no it does not behave the same as Java or Javascript, and will throw an error. Rust does not allow adding an integer to a string and will also throw an error. I suggest actually trying these things yourself, we are talking about adding an integer to a string, or subtracting an integer from a string. Obviously many languages will throw an error when trying to do this.
        cxr 4y ago
        > C throws a warning [sic] No, it doesn't. Nor does it throw an error. Once again: C does not even have the infrastructure to throw. Not just when adding numbers and strings, but anything. Ever. In any circumstance. > it does not behave the same as javascript Who said it did? > I suggest actually trying these things yourself Likewise (especially if you're going to be condescending about it). > Obviously many languages will throw an error when trying to do this. That's not obvious. I've asked you for examples, and you've named multiple ones that definitely don't. (And this is not an attempt to be rude, but rather frank: at this point in the discussion you come across as someone who, despite having probably used several handfuls of languages including the ones you mention, has a lot of confidence but only a coarse understanding and/or loose appreciation of the relevant concepts at play—down to confusing the distinction between compile-time vs run-time behavior.)
  - eviks 4y ago
    Use stupid language, get stupid games
- mdp2021 4y ago
  True, and apparently counterintuitive if presented that way, but it makes sense as '+' is a string concatenation operator. It is the type conversion that can be used in unclear contexts - it can be comfortable and also dangerous.
- deleted 4y ago
  [deleted]
- cxr 4y ago
  People love to trot out examples like this while remaining totally silent about why they're trying to add/subtract numbers and strings in the first place or articulate what they expected to happen when they did it. On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" [...] I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
  - kamranjon 4y ago
    Oh I absolutely ran into this because I had a bug, I had forgot to parse the number into the correct format, but it still feels odd that the language behaves this way. Here is an example of what Ruby outputs: "4" + 4 : `+': no implicit conversion of Integer into String (TypeError) "44" - 4 : undefined method `-' for "40":String (NoMethodError) The funny thing being the implicit type conversion that javascript does. This is likely why typescript has become so popular. Are there other languages that have implicit type conversion for basic types like javascript?
    - plugin-baby 4y ago
      Java?
  - mekoka 4y ago
    Why? Because type errors are a fact of life in programming. They're not evidence of programmers trying to be eccentric. What was expected? Regardless if static or dynamic, it should be strongly typed. Just throw the error. All languages that have tried to salvage the situation when the programmer's intent became ambiguous end up creating problems down the road.
    - cxr 4y ago
      > type errors are a fact of life in programming ...and anyone who cares, therefore, uses a typechecker. What makes it such a weird criticism is that, in order for it to make sense, you have to satisfy all three of 1) being someone who is annoyed that the operators have these well-defined semantics for mixed types, 2) actually mixing types and doing so by accident rather than intentionally, but 3) nonetheless someone who refuses to use a typechecker. That's a special case of someone insistent on putting the wrong figures into the machine altogether... > Regardless if static or dynamic, it should be strongly typed. Just throw the error. Java and C# are two of the most popular and widely used strongly typed languages. They don't throw errors for this.
a_wild_dandan 4y ago
Thus far, JS has overwhelmingly been my favorite programming language. Expressive; amazing type system with TS; fast (V8 is an engineering marvel); and its ecosystem has frameworks/libraries for nearly everything, given its overwhelming popularity! What makes reasoning about JS your code difficult, relative to other languages? Maybe the event loop is unintuitive? In my experience, opaque application states were caused by my odd engineering choices rather than any particular language. But I'd love to hear your experience.
- user3939382 4y ago
  There are so many gotchas that I give up even trying to remember them, thus I just try the code to find out what it will do. One fun one that just came up is that async callbacks work totally different inside a forEach vs a for loop. https://developer.mozilla.org/en-US/docs/Glossary/Hoisting https://developer.mozilla.org/en-US/docs/Glossary/Hoisting I’m sure someone out there has compiled the list of things that don’t make sense. It’s like 100 people designed different features without talking to each other and glued it all together into one language.
  - lenkite 4y ago
    In one of my earlier JS projects, the coding guidelines strictly enforced the rule of declaring all variables at top of the function to not get confused by JS hoisting "magic". You need to enforce coding conventions in JS as soon as you have greater than one person working on a project. Sometimes even if you are the lone person - esp if you are coming back to it after a delay.
rasz 4y ago
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger W. Dijkstra
- pacaro 4y ago
  At university I took one cs class, which was an easy credit part of a math class. It was taught in Fortran and at the beginning of the first lecture (this was in 1990) the lecturer asked for a show of hands who had experience with BASIC and many of us raised our hands. We were then given a pessimistic variant of the Dijkstra quote. I never took another CS class I have been working in the industry for nearly 30 years, have worked on cutting edge technology, contributed to software that billions of people use (and written plenty that fewer than 10 people use) I will, of course, never have the same impact/influence that Dijkstra has had. Did he ever acknowledge how fundamentally wrong he was about this?
  - rasz 4y ago
    This is quite hilarious considering the rest of the Dijkstra 1975 letter >FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
azangru 4y ago
> I still commonly can't predict what the behavior of some aspects of my code is going to be Commonly? Could you give an example? > or what the state of the application is at a given point That's not a criticism of a language though, is it? It is either a criticism of how an application is being written, or a statement about the complexity of the application.
javascrap 4y ago
This is mostly because you have been at it so long. If you start fresh with TS + modern tooling the vast majority of the gotchas no longer exist. I’m in the same boat. My grey beard is frequently showing.

kamranjon 4y ago

"4" + 4 = "44" "44" - 4 = 40

deleted 4y ago
[deleted]
a_wild_dandan 4y ago
In other words: play stupid games, win stupid prizes. ;)
- kamranjon 4y ago
  Haha yes, most oddities in JS are a result of the language allowing you to play stupid games - many languages would just throw an error here (heck even ruby does). I discovered this strangeness when I forgot to parseFloat on a string and things kept humming along as if nothing was wrong, until I did some addition and things grew exponentially.
  - cxr 4y ago
    > many languages would just throw an error here Some do. Many don't. I have a feeling that most people who say this sort of thing mean "Python" and assume that that's the norm. (The "heck even ruby does" remark def. reinforces that.) Can you name any that do that aren't dynamic languages?
    - kamranjon 4y ago
      C, Rust, Go. There are probably many more. But I think you might be overall misinterpreting my original comment. I was responding to someone who said they still commonly find unpredictable behavior in Javascript that they were unaware of after using it for years. I just responded with something I recently discovered in a similar vein, and you appeared to take it as some sort of statement about Javascript as a language. I really enjoy Javascript, and I was really just highlighting a recent example I ran into that gave me the same feeling conveyed in the original comment I was responding to.
      - cxr 4y ago
        C does not throw an error. C does not even have the infrastructure to throw errors. The closest thing are signals, and it doesn't use those for this issue. Go is similar to C, C#, Java, JS, etc in the sense that if anything is to be done about it then the expectation is for it to be flagged as part of typechecking before runtime. I don't have enough experience with Rust, but I'd be willing to bet that it doesn't do what you're saying, either.
        kamranjon 4y ago
        C throws a warning, because you need to manually cast to get expected behavior. But it does not behave the same as javascript, try it yourself, you will not get "44" when you add "4" to 4. Go does not support implicit type conversion, so no it does not behave the same as Java or Javascript, and will throw an error. Rust does not allow adding an integer to a string and will also throw an error. I suggest actually trying these things yourself, we are talking about adding an integer to a string, or subtracting an integer from a string. Obviously many languages will throw an error when trying to do this.
        cxr 4y ago
        > C throws a warning [sic] No, it doesn't. Nor does it throw an error. Once again: C does not even have the infrastructure to throw. Not just when adding numbers and strings, but anything. Ever. In any circumstance. > it does not behave the same as javascript Who said it did? > I suggest actually trying these things yourself Likewise (especially if you're going to be condescending about it). > Obviously many languages will throw an error when trying to do this. That's not obvious. I've asked you for examples, and you've named multiple ones that definitely don't. (And this is not an attempt to be rude, but rather frank: at this point in the discussion you come across as someone who, despite having probably used several handfuls of languages including the ones you mention, has a lot of confidence but only a coarse understanding and/or loose appreciation of the relevant concepts at play—down to confusing the distinction between compile-time vs run-time behavior.)
- eviks 4y ago
  Use stupid language, get stupid games
mdp2021 4y ago
True, and apparently counterintuitive if presented that way, but it makes sense as '+' is a string concatenation operator. It is the type conversion that can be used in unclear contexts - it can be comfortable and also dangerous.
deleted 4y ago
[deleted]
cxr 4y ago
People love to trot out examples like this while remaining totally silent about why they're trying to add/subtract numbers and strings in the first place or articulate what they expected to happen when they did it. On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" [...] I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
- kamranjon 4y ago
  Oh I absolutely ran into this because I had a bug, I had forgot to parse the number into the correct format, but it still feels odd that the language behaves this way. Here is an example of what Ruby outputs: "4" + 4 : `+': no implicit conversion of Integer into String (TypeError) "44" - 4 : undefined method `-' for "40":String (NoMethodError) The funny thing being the implicit type conversion that javascript does. This is likely why typescript has become so popular. Are there other languages that have implicit type conversion for basic types like javascript?
  - plugin-baby 4y ago
    Java?
- mekoka 4y ago
  Why? Because type errors are a fact of life in programming. They're not evidence of programmers trying to be eccentric. What was expected? Regardless if static or dynamic, it should be strongly typed. Just throw the error. All languages that have tried to salvage the situation when the programmer's intent became ambiguous end up creating problems down the road.
  - cxr 4y ago
    > type errors are a fact of life in programming ...and anyone who cares, therefore, uses a typechecker. What makes it such a weird criticism is that, in order for it to make sense, you have to satisfy all three of 1) being someone who is annoyed that the operators have these well-defined semantics for mixed types, 2) actually mixing types and doing so by accident rather than intentionally, but 3) nonetheless someone who refuses to use a typechecker. That's a special case of someone insistent on putting the wrong figures into the machine altogether... > Regardless if static or dynamic, it should be strongly typed. Just throw the error. Java and C# are two of the most popular and widely used strongly typed languages. They don't throw errors for this.

a_wild_dandan 4y ago

Thus far, JS has overwhelmingly been my favorite programming language. Expressive; amazing type system with TS; fast (V8 is an engineering marvel); and its ecosystem has frameworks/libraries for nearly everything, given its overwhelming popularity! What makes reasoning about JS your code difficult, relative to other languages? Maybe the event loop is unintuitive? In my experience, opaque application states were caused by my odd engineering choices rather than any particular language. But I'd love to hear your experience.

user3939382 4y ago
There are so many gotchas that I give up even trying to remember them, thus I just try the code to find out what it will do. One fun one that just came up is that async callbacks work totally different inside a forEach vs a for loop. https://developer.mozilla.org/en-US/docs/Glossary/Hoisting https://developer.mozilla.org/en-US/docs/Glossary/Hoisting I’m sure someone out there has compiled the list of things that don’t make sense. It’s like 100 people designed different features without talking to each other and glued it all together into one language.
- lenkite 4y ago
  In one of my earlier JS projects, the coding guidelines strictly enforced the rule of declaring all variables at top of the function to not get confused by JS hoisting "magic". You need to enforce coding conventions in JS as soon as you have greater than one person working on a project. Sometimes even if you are the lone person - esp if you are coming back to it after a delay.

rasz 4y ago

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger W. Dijkstra

pacaro 4y ago
At university I took one cs class, which was an easy credit part of a math class. It was taught in Fortran and at the beginning of the first lecture (this was in 1990) the lecturer asked for a show of hands who had experience with BASIC and many of us raised our hands. We were then given a pessimistic variant of the Dijkstra quote. I never took another CS class I have been working in the industry for nearly 30 years, have worked on cutting edge technology, contributed to software that billions of people use (and written plenty that fewer than 10 people use) I will, of course, never have the same impact/influence that Dijkstra has had. Did he ever acknowledge how fundamentally wrong he was about this?
- rasz 4y ago
  This is quite hilarious considering the rest of the Dijkstra 1975 letter >FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.

azangru 4y ago

> I still commonly can't predict what the behavior of some aspects of my code is going to be Commonly? Could you give an example? > or what the state of the application is at a given point That's not a criticism of a language though, is it? It is either a criticism of how an application is being written, or a statement about the complexity of the application.

javascrap 4y ago

This is mostly because you have been at it so long. If you start fresh with TS + modern tooling the vast majority of the gotchas no longer exist. I’m in the same boat. My grey beard is frequently showing.