10 ms·

Every time I read about SICP, I get frustrated all over again about Javascript. It could have been Scheme and all web development would have benefited.

fire_lake 2y ago
Hey, at least there’s Clojurescript.
snek_case 2y ago
JavaScript was originally developed in two weeks due to time constraints from Brendan Eich's employer. It would probably have just as many design mistakes if he had stuck with a scheme-like syntax instead. It's just hard to create a well-designed language in such a short amount of time.
- emseetech 2y ago
  Yes, Javascript is one of the seminal "sales already signed the contract" situations in tech. Given the circumstances, it's amazing javascript isn't way worse.
  - bazoom42 2y ago
    It could have been VBScript.
ralphc 2y ago
The only way it would have "benefited" would be that the web would only be developed by lisp programmers. To the vast majority of programmers, syntax matters. C-style with brackets, or python whitespace, or Ruby do/end, these fit better the brains of the majority of programmers. Perhaps not the majority of HN readers but the majority of corporate devs. Another example of this is Erlang and Elixir. Elixir adds a couple of features over Erlang, macros and protocols, but Erlang does everything else. What made Elixir take off where Erlang didn't, after decades, is that Elixir has a syntax that people are comfortable with. Erlang has a syntax that will summon Cthulu.
- sakras 2y ago
  Is it an innate property of humans that the curly-brace style is more natural? I wonder if in an alternate universe where Lisp took off as the browser language people would find it more natural instead. It seems like somewhat of a chicken-egg problem.
  - lmm 2y ago
    I think it's innate that having differentiated syntax for different types of grouping is natural. Look at mathematical papers where people will introduce new brackets with new meanings. (Indeed look at the entirety of QM for a clear, simple case)
    - nequo 2y ago
      Some Scheme and Lisp dialects have that. For example, Racket often uses square brackets instead of parentheses for things like clauses of a cond expression, and Clojure uses square brackets for vector literals and curlies for hash map literals.
    - lispm 2y ago
      > "Look at mathematical papers where people will introduce new brackets with new meanings" Common Lisp has left brackets like {} and [] to the user (aka developer). It supports "reader macros", where the user can extend/supersede the syntax of s-expressions. So, specialized tools/libraries/applications can introduce these brackets for their own use. Examples are embedded SQL expressions, notations for Frames (special objects, in kind of a mix of OOP and Logics), grammar terms, etc. Thus it explicitly supports the idea of "people will introduce new brackets with new meanings".
  - lopatin 2y ago
    Does decades of empirical evidence not prove that people are more comfortable with imperative, curly brace programming over s-expressions? It's not a chicken and egg problem. The egg has hatched and nested parentheses lost.
odyssey7 2y ago
ECMAScript 2015: proper tail calls are now in the spec Chromium: we’re not doing proper tail calls
- davexunit 2y ago
  But now they have them... for WebAssembly.
potsandpans 2y ago
having call/cc would make my life better
ipnon 2y ago
I should write a Lisp browser.
foldr 2y ago
R5RS Scheme (standardised in 1998) didn't even have structs. To make anything like the DOM practical, you'd have needed some non-standard extensions that could well have ended up being a mess anyway.
epolanski 2y ago
As someone who's both versed in Lisps (CL, Racket, Scheme, Clojure) and JavaScript: thank god. It's like the Lisp crowd can't be honest with itself and not realise the serious shortcomings of lisp projects are: maintainability. Every single lisp project out there, hell this also applies to Haskell, is so radically different because everybody's too busy reinventing its own abstractions and macros (and language extensions in case of Haskell) that you just throw your hands up in the air in dismay. It's like the Lisp crowd, that can barely attract like-minded people to collaborate on some simple open source projects out there so you get 20 broken JSON parsers, cannot see the link between that issue and industrial lisps. I love lisps, they are fun, they have their place in the industry when you leverage them to their core strengths. Try to ask yourself: why does PHP has more quality killer-software than all of lisps combined?
- commandlinefan 2y ago
  > everybody's too busy reinventing its own abstractions Isn't that the problem with Javascript too, though? Javascript isn't good enough, let's all use jQuery. No, jQuery isn't good enough, let's all use Vue. No, Vue isn't good enough, let's all use Angular. No, Angular isn't good enough, let's all use React. No, React isn't good enough, let's...
  - shepherdjerred 2y ago
    This is very disingenuous. The frontend world does move quickly, but the part of the stack you're describing has been reasonably stable. Vanilla JS was replaced by jQuery after about a decade. A decade later, React/Vue/Angular (React came first, not last) replaced jQuery There was a paradigm shift in the kind of websites that people wanted to build. For better or worse, we went from HTML + CSS with some JavaScript (jQuery) to SPAs. It's easier for a team of junior developers to build a SPA with React compared to jQuery. The abstractions that you're describing changed because the goal changed. --- There has been plenty of churn around build tools, libraries on top of React/Vue, the paradigms within React/Vue (Hooks, Vue 3 composition API), state management libraries, and the adoption of TypeScript. Again, this isn't really reinventing abstractions as much as dealing with an evolving language that wasn't designed for the applications we're building today (though it is clearly quite capable!)

fire_lake 2y ago

Hey, at least there’s Clojurescript.

snek_case 2y ago

JavaScript was originally developed in two weeks due to time constraints from Brendan Eich's employer. It would probably have just as many design mistakes if he had stuck with a scheme-like syntax instead. It's just hard to create a well-designed language in such a short amount of time.

emseetech 2y ago
Yes, Javascript is one of the seminal "sales already signed the contract" situations in tech. Given the circumstances, it's amazing javascript isn't way worse.
- bazoom42 2y ago
  It could have been VBScript.

ralphc 2y ago

The only way it would have "benefited" would be that the web would only be developed by lisp programmers. To the vast majority of programmers, syntax matters. C-style with brackets, or python whitespace, or Ruby do/end, these fit better the brains of the majority of programmers. Perhaps not the majority of HN readers but the majority of corporate devs. Another example of this is Erlang and Elixir. Elixir adds a couple of features over Erlang, macros and protocols, but Erlang does everything else. What made Elixir take off where Erlang didn't, after decades, is that Elixir has a syntax that people are comfortable with. Erlang has a syntax that will summon Cthulu.

sakras 2y ago
Is it an innate property of humans that the curly-brace style is more natural? I wonder if in an alternate universe where Lisp took off as the browser language people would find it more natural instead. It seems like somewhat of a chicken-egg problem.
- lmm 2y ago
  I think it's innate that having differentiated syntax for different types of grouping is natural. Look at mathematical papers where people will introduce new brackets with new meanings. (Indeed look at the entirety of QM for a clear, simple case)
  - nequo 2y ago
    Some Scheme and Lisp dialects have that. For example, Racket often uses square brackets instead of parentheses for things like clauses of a cond expression, and Clojure uses square brackets for vector literals and curlies for hash map literals.
  - lispm 2y ago
    > "Look at mathematical papers where people will introduce new brackets with new meanings" Common Lisp has left brackets like {} and [] to the user (aka developer). It supports "reader macros", where the user can extend/supersede the syntax of s-expressions. So, specialized tools/libraries/applications can introduce these brackets for their own use. Examples are embedded SQL expressions, notations for Frames (special objects, in kind of a mix of OOP and Logics), grammar terms, etc. Thus it explicitly supports the idea of "people will introduce new brackets with new meanings".
- lopatin 2y ago
  Does decades of empirical evidence not prove that people are more comfortable with imperative, curly brace programming over s-expressions? It's not a chicken and egg problem. The egg has hatched and nested parentheses lost.

odyssey7 2y ago

ECMAScript 2015: proper tail calls are now in the spec Chromium: we’re not doing proper tail calls

davexunit 2y ago
But now they have them... for WebAssembly.

potsandpans 2y ago

having call/cc would make my life better

ipnon 2y ago

I should write a Lisp browser.

foldr 2y ago

R5RS Scheme (standardised in 1998) didn't even have structs. To make anything like the DOM practical, you'd have needed some non-standard extensions that could well have ended up being a mess anyway.

epolanski 2y ago

As someone who's both versed in Lisps (CL, Racket, Scheme, Clojure) and JavaScript: thank god. It's like the Lisp crowd can't be honest with itself and not realise the serious shortcomings of lisp projects are: maintainability. Every single lisp project out there, hell this also applies to Haskell, is so radically different because everybody's too busy reinventing its own abstractions and macros (and language extensions in case of Haskell) that you just throw your hands up in the air in dismay. It's like the Lisp crowd, that can barely attract like-minded people to collaborate on some simple open source projects out there so you get 20 broken JSON parsers, cannot see the link between that issue and industrial lisps. I love lisps, they are fun, they have their place in the industry when you leverage them to their core strengths. Try to ask yourself: why does PHP has more quality killer-software than all of lisps combined?

commandlinefan 2y ago
> everybody's too busy reinventing its own abstractions Isn't that the problem with Javascript too, though? Javascript isn't good enough, let's all use jQuery. No, jQuery isn't good enough, let's all use Vue. No, Vue isn't good enough, let's all use Angular. No, Angular isn't good enough, let's all use React. No, React isn't good enough, let's...
- shepherdjerred 2y ago
  This is very disingenuous. The frontend world does move quickly, but the part of the stack you're describing has been reasonably stable. Vanilla JS was replaced by jQuery after about a decade. A decade later, React/Vue/Angular (React came first, not last) replaced jQuery There was a paradigm shift in the kind of websites that people wanted to build. For better or worse, we went from HTML + CSS with some JavaScript (jQuery) to SPAs. It's easier for a team of junior developers to build a SPA with React compared to jQuery. The abstractions that you're describing changed because the goal changed. --- There has been plenty of churn around build tools, libraries on top of React/Vue, the paradigms within React/Vue (Hooks, Vue 3 composition API), state management libraries, and the adoption of TypeScript. Again, this isn't really reinventing abstractions as much as dealing with an evolving language that wasn't designed for the applications we're building today (though it is clearly quite capable!)