6 ms·

Javascript is one of the fastest dynamically typed languages. People use it instead of other languages because the productivity of dynamically typed languages i

by methyl 5y ago

Javascript is one of the fastest dynamically typed languages. People use it instead of other languages because the productivity of dynamically typed languages is generally higher. I’d be interested in hearing what are those other languages that would be faster to run and not slower to program in.

eloisius 5y ago
"Not slower to program in" is a cost savings to the business, but let's be honest about that being what it is. It's a cost savings for the business that results in a crummier product for customers. Just like trimming a single tomato from the salad on in-flight meals is a cost savings to Delta. Doesn't mean it's a "better" salad.
- methyl 5y ago
  It's a question of having it or not at all. Poor salad is better than no salad.
  - eloisius 5y ago
    As far as I can tell, it's a question of having or not having whizbang bloated apps like Slack, but we had perfectly acceptable word processors, spreadsheets, 3D modeling tools, etc a long time ago. The current gen, JS-powered versions of those tools (Google Drive, Quip, Notion) all feel slower. Sure, there are fewer BSODs now so it probably evens out, but the extremely low latency UX of those tools back in the Windows 2000/XP days is lost.
    - whywhywhywhy 5y ago
      Yet Figma blows Illustrator and Sketch out of the water. A lot it’s really just down to developer talent and how much they care about it. Examples exist in the world proving it’s possible. Illustrator is slow for the same reasons, no one working on it cares about what they’re building. But still it would need 10x speed improvements in multiple areas to beat Figma now.
      - eloisius 5y ago
        And Office360 is about as bad as Google Docs. It's honestly probably not a JavaScript problem. Some mixture of businesses not giving a damn about quality because it's more profitable to play the acquire-integrate-exterminate game than make quality software, lower barrier to entry meaning we get more developers who are productive because of better tooling, but probably in over their heads making performance-critical things like input controls in JavaScript, and piles of new abstractions without the old abstractions ever going away.
naikrovek 5y ago
> the productivity of dynamically typed languages is generally higher. This is the assumption, yes, and I am not sure that it's true at all; people simply believe it to be true rather than actually check to see if their assumptions are correct. I believe this to be a very false assumption, in reality. The number of lines of JS that I see which do a particular thing is very high compared to other languages. This is not a JavaScript example, but it goes to my point that our assumptions are wrong: For example, can someone explain to me why a the Dropbox Desktop client 3 years ago was 4 million lines of Python?[0] If Python is such a high-level language, why are so many lines of code needed to do such a simple thing? [0]: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin...
- pflanze 5y ago
  The "4 million lines of Python" in that article is referring to the number of lines that are type checked (I don't see any mention of how much code remained unchecked, although the graphs might imply some 20%), but it also includes Dropbox' server side code base; the shown graphs imply that the server side is 4x larger than the client side. Assuming the above implications are true, the client side app would be 1 million lines of code. I guess someone with the client could go and measure? I don't mean to say that 1 M loc isn't still large, but you seem to be drawing conclusions from using numbers incorrectly.
  - naikrovek 5y ago
    ok, over 1M lines of code... ...For the Dropbox client. line count from: (https://dropbox.tech/application/incrementally-migrating-over-one-million-lines-of-code-from-python-2-to-python-3 https://dropbox.tech/application/incrementally-migrating-ove...) how high-level are "high-level" languages? I would say that it would take far fewer lines of C or even Assembly to accomplish the same goals. 50k lines of C, probably. XTerm is ~70k lines of C, if I recall (I am certainly within 0.5 orders of magnitude), and it is extremely complex and does much more. if you want a more direct comparison, look at rsync or syncthing. I haven't looked at the size of those, ever, but I'd be willing to bet that both are FAR smaller than 1M lines of code. So, how it acceptable that a high-level language requires more lines of code than a "lower-level" language like C or Go? we're supposed to GAIN SOMETHING in the tradeoff by using high-level languages, and we're not. certainly not as much as we assume we are. we need to pay attention to these assumptions that we're making to ensure that they're true, periodically. we're not. it's just accepted as fact that "high-level" languages require fewer lines of code and less work to produce high-quality software, and I don't think we're seeing the benefits of the tradeoff anymore, if we ever really did, outside of tiny example programs.
anthk 5y ago
Eh, try OcaML against JS.

by methyl 5y ago

eloisius 5y ago

"Not slower to program in" is a cost savings to the business, but let's be honest about that being what it is. It's a cost savings for the business that results in a crummier product for customers. Just like trimming a single tomato from the salad on in-flight meals is a cost savings to Delta. Doesn't mean it's a "better" salad.

methyl 5y ago
It's a question of having it or not at all. Poor salad is better than no salad.
- eloisius 5y ago
  As far as I can tell, it's a question of having or not having whizbang bloated apps like Slack, but we had perfectly acceptable word processors, spreadsheets, 3D modeling tools, etc a long time ago. The current gen, JS-powered versions of those tools (Google Drive, Quip, Notion) all feel slower. Sure, there are fewer BSODs now so it probably evens out, but the extremely low latency UX of those tools back in the Windows 2000/XP days is lost.
  - whywhywhywhy 5y ago
    Yet Figma blows Illustrator and Sketch out of the water. A lot it’s really just down to developer talent and how much they care about it. Examples exist in the world proving it’s possible. Illustrator is slow for the same reasons, no one working on it cares about what they’re building. But still it would need 10x speed improvements in multiple areas to beat Figma now.
    - eloisius 5y ago
      And Office360 is about as bad as Google Docs. It's honestly probably not a JavaScript problem. Some mixture of businesses not giving a damn about quality because it's more profitable to play the acquire-integrate-exterminate game than make quality software, lower barrier to entry meaning we get more developers who are productive because of better tooling, but probably in over their heads making performance-critical things like input controls in JavaScript, and piles of new abstractions without the old abstractions ever going away.

naikrovek 5y ago

> the productivity of dynamically typed languages is generally higher. This is the assumption, yes, and I am not sure that it's true at all; people simply believe it to be true rather than actually check to see if their assumptions are correct. I believe this to be a very false assumption, in reality. The number of lines of JS that I see which do a particular thing is very high compared to other languages. This is not a JavaScript example, but it goes to my point that our assumptions are wrong: For example, can someone explain to me why a the Dropbox Desktop client 3 years ago was 4 million lines of Python?[0] If Python is such a high-level language, why are so many lines of code needed to do such a simple thing? [0]: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin...

pflanze 5y ago
The "4 million lines of Python" in that article is referring to the number of lines that are type checked (I don't see any mention of how much code remained unchecked, although the graphs might imply some 20%), but it also includes Dropbox' server side code base; the shown graphs imply that the server side is 4x larger than the client side. Assuming the above implications are true, the client side app would be 1 million lines of code. I guess someone with the client could go and measure? I don't mean to say that 1 M loc isn't still large, but you seem to be drawing conclusions from using numbers incorrectly.
- naikrovek 5y ago
  ok, over 1M lines of code... ...For the Dropbox client. line count from: (https://dropbox.tech/application/incrementally-migrating-over-one-million-lines-of-code-from-python-2-to-python-3 https://dropbox.tech/application/incrementally-migrating-ove...) how high-level are "high-level" languages? I would say that it would take far fewer lines of C or even Assembly to accomplish the same goals. 50k lines of C, probably. XTerm is ~70k lines of C, if I recall (I am certainly within 0.5 orders of magnitude), and it is extremely complex and does much more. if you want a more direct comparison, look at rsync or syncthing. I haven't looked at the size of those, ever, but I'd be willing to bet that both are FAR smaller than 1M lines of code. So, how it acceptable that a high-level language requires more lines of code than a "lower-level" language like C or Go? we're supposed to GAIN SOMETHING in the tradeoff by using high-level languages, and we're not. certainly not as much as we assume we are. we need to pay attention to these assumptions that we're making to ensure that they're true, periodically. we're not. it's just accepted as fact that "high-level" languages require fewer lines of code and less work to produce high-quality software, and I don't think we're seeing the benefits of the tradeoff anymore, if we ever really did, outside of tiny example programs.

anthk 5y ago

Eh, try OcaML against JS.