7 ms·

Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript. Nothing uniquely qua

by pekk 13y ago

Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript. Nothing uniquely qualifies Javascript.

lisper 13y ago
Not even "in place of" but "in addition to". There's a reason that the script tag has a language attribute as part of the standard.
- patrickmay 13y ago
  This I would love to see. I'm not aware of any project working to enable Scheme or Common Lisp in the browser, though. Anyone else?
  - ctdavies 13y ago
    ClojureScript is a subset of Clojure that compiles to Google Closure-optimized JavaScript, so close enough, right?
    - lgas 13y ago
      Googling turned up several on just the first page of results: http://www.biwascheme.org/ http://www.biwascheme.org/ http://sisc-scheme.org/sisc-online.php http://sisc-scheme.org/sisc-online.php http://lisperator.net/slip/ http://lisperator.net/slip/ http://alex.nisnevich.com/ecmachine/ http://alex.nisnevich.com/ecmachine/ But the parent is really the right answer -- ClojureScript is actually targeted at meeting modern web development challenges and has a thriving ecosystem of powerful tools for the same.
      - patrickmay 13y ago
        Compiling to Javascript isn't what I find interesting. I'd like support for <script type="text/lisp" language="common-lisp" src="web-ui.lisp">. Pure Lisp, compiled for the user's browser and OS. No Javascript anywhere.
        sitkack 13y ago
        You can do this now <script src="biwascheme.js"> (console-log "Hello, world!") </script>
        patrickmay 13y ago
        You see that ".js" in your example? I don't want it. I would like to know how to implement and deploy a scripting engine that has no dependencies on Javascript whatsoever.
        sitkack 13y ago
        That doesn't materially matter. I know you don't want it, but it in no way effects the computation.
    - pmbauer 13y ago
      http://hoplon.io/ http://hoplon.io/ is a lot closer to the Hickey/Norvig/Anderson paper.
- Ygg2 13y ago
  I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310. On a serious note, JavaScript and the lack of fragmentation is one of the best features of Web. You don't have to download appropriate browsers (in theory and mostly in practice) to run your website.
  - taeric 13y ago
    This is one of the things that baffles me with the somewhat radical things getting added to javascript this go around. I mean, I can't argue that there are some things that will be nice to have. However, it seems that going with additions that are not addable as a library is contrary to the bloody web. Or, am I wrong and the new syntactical changes will be ok? Also... this pretty much exemplifies how/why lisp would have been awesome. Quite literally everything could be done "as a library."
  - lisper 13y ago
    > I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310. But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java. There would be very little difference in the UX between different scripting languages and the current UX w.r.t. media codexes, and the end result would be the same in both cases: there would be some repertoire of languages and codexes that everyone uses and become standard. The alternative is to forever have to deal with a language that by design cannot even handle integer math or unicode strings properly.
    - randallsquared 13y ago
      > But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java. That's exactly the point. Imagine dozens of them.
      - lisper 13y ago
        Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in. Dozens of languages? I very much doubt that will happen. Just as we only have a small handful of codexes that actually matter (Flash, Silverlight, H264, maybe ogg) I predict that we will end up with a small number of languages that actually matter: Javascript, Python, Ruby, and Scheme. Maybe CL. IMHO that would be a better world than the one we currently live in. Javascript is serviceable for its original purpose, but for serious webapps it's broken beyond redemption. NOTE: This is not to say that it is impossible to write serious webapps in Javasceript. Obviously it is possible. What I mean is that at some point the aggregate cost of dealing with Javascript's design flaws becomes greater than the aggregate cost of dealing with multiple browser scripting languages.
- pekk 13y ago
  You are right, I misspoke and would have said "in addition to"
chimeracoder 13y ago
While nothing uniquely "requires' Javascript, replacing it in an existing browser is no easy feat. Look at how much work has gone into making Dart work just in Chrome. And if any browser is going to replace Javascript, it's going to be Chrome (first), not Firefox - Mozilla is doubling-down on Javascript with both asm.js and FirefoxOS. Google is doubling-down on efforts to replace and/or subvert Javascripts, with both Dart and NaCl. Nothing uniquely qualifies Javascript now, but being the status quo is a qualification of sorts. Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).
- grey-area 13y ago
  Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers). I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it. It's a real shame we've ended up in a situation where the only API for manipulating the DOM is in js - script tags were not initially intended to be js only. Switching language would be the perfect opportunity to create a proper standard library for the web, by looking at the organic mess which is DOM access, js animation, etc, extracting the good parts, and throwing away all the rest. If it significantly improved dev productivity, and was available as a plugin initially for all browsers, people might be willing to experiment with it. There are political and technical problems with doing that of course, but it would be a great step forward for web development, and is not at all beyond the reach of a big browser vendor. I agree if it were to be anyone, it'd be Google.
  - chimeracoder 13y ago
    > I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it You'll get no disagreement from me about the JS stdlib. I was shocked when I found the "correct" way to extract the day of the week from a Date object in Javascript (without third-party libraries): https://stackoverflow.com/questions/4822852/javascript-how-to-get-the-day-of-week-and-the-month-of-the-year https://stackoverflow.com/questions/4822852/javascript-how-t... [0] It would be a great feat if/when someone does it. But saying that "Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript" sort of ignores the amount of work required to actually do this (properly). [0] Of course, this code does already exist internally, as evidenced by (new Date).toString(); you just can't access it.
camus2 13y ago
Once you "accept" transpilation,you can use any language in the browser and you stop asking yourself these questions. You still need to know javascript though. Dart,CoffeeScript,Typescript,ClosureScript... IT's not like people dont have the choice today.And sourcemaps work well when debugging,usually.
- davorb 13y ago
  If we had LISP, we wouldn't really need CSS or HTML either. Everything could be represented with s-expressions and we would all reach nirvana.
  - klibertp 13y ago
    Only if every single designer who happens to write some styles has paredit installed. Ditto for every non-technical user who would want to customize some template or something. Sexps are cool, but you really, really need proper tools to edit them efficiently. Without them it's very easy to make a mistake, which of course will make it to runtime, because it won't be a syntax error in most cases. That's the downside of having so little syntax. So I think that (for CSS) we'd either build very simple sexp based DSL using macros or we'd just create a compile-to-sexps human friendly syntax. On the plus side, with Lisps, that would be one evening to implement... :)
    - hajile 13y ago
      If you aren't already using templates, then you're probably doing it wrong. If you have a designer doing serious template work and that designer doesn't know anything, then you're probably doing it wrong. languages like haml and jade are very close to M-expression languages and could work as drop-in replacements for S-expressions just like they are used as <html> replacements at present or s-expr could be used. In addition, in the presence of a lisp language, the code <--> data relationship can be quite convenient.
    - rurban 13y ago
      Remember DSSSL anyone? Obviously worse was better
weland 13y ago
> Nothing uniquely qualifies Javascript. The kind and amount of technical expertise behind the development mass that drives most of the Web nowadays does, sadly.
rjsw 13y ago
It would have been easy to do this in IE too, there was a well defined COM interface to allow alternative scripting engines to be used.

by pekk 13y ago

Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript. Nothing uniquely qualifies Javascript.

lisper 13y ago

Not even "in place of" but "in addition to". There's a reason that the script tag has a language attribute as part of the standard.

patrickmay 13y ago
This I would love to see. I'm not aware of any project working to enable Scheme or Common Lisp in the browser, though. Anyone else?
- ctdavies 13y ago
  ClojureScript is a subset of Clojure that compiles to Google Closure-optimized JavaScript, so close enough, right?
  - lgas 13y ago
    Googling turned up several on just the first page of results: http://www.biwascheme.org/ http://www.biwascheme.org/ http://sisc-scheme.org/sisc-online.php http://sisc-scheme.org/sisc-online.php http://lisperator.net/slip/ http://lisperator.net/slip/ http://alex.nisnevich.com/ecmachine/ http://alex.nisnevich.com/ecmachine/ But the parent is really the right answer -- ClojureScript is actually targeted at meeting modern web development challenges and has a thriving ecosystem of powerful tools for the same.
    - patrickmay 13y ago
      Compiling to Javascript isn't what I find interesting. I'd like support for <script type="text/lisp" language="common-lisp" src="web-ui.lisp">. Pure Lisp, compiled for the user's browser and OS. No Javascript anywhere.
      - sitkack 13y ago
        You can do this now <script src="biwascheme.js"> (console-log "Hello, world!") </script>
        patrickmay 13y ago
        You see that ".js" in your example? I don't want it. I would like to know how to implement and deploy a scripting engine that has no dependencies on Javascript whatsoever.
        sitkack 13y ago
        That doesn't materially matter. I know you don't want it, but it in no way effects the computation.
  - pmbauer 13y ago
    http://hoplon.io/ http://hoplon.io/ is a lot closer to the Hickey/Norvig/Anderson paper.
Ygg2 13y ago
I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310. On a serious note, JavaScript and the lack of fragmentation is one of the best features of Web. You don't have to download appropriate browsers (in theory and mostly in practice) to run your website.
- taeric 13y ago
  This is one of the things that baffles me with the somewhat radical things getting added to javascript this go around. I mean, I can't argue that there are some things that will be nice to have. However, it seems that going with additions that are not addable as a library is contrary to the bloody web. Or, am I wrong and the new syntactical changes will be ok? Also... this pretty much exemplifies how/why lisp would have been awesome. Quite literally everything could be done "as a library."
- lisper 13y ago
  > I'm afraid you're browser doesn't support XScript, please download Chrome Explorer 310. But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java. There would be very little difference in the UX between different scripting languages and the current UX w.r.t. media codexes, and the end result would be the same in both cases: there would be some repertoire of languages and codexes that everyone uses and become standard. The alternative is to forever have to deal with a language that by design cannot even handle integer math or unicode strings properly.
  - randallsquared 13y ago
    > But this sort of thing already happens all the time. You don't have the right flash player, or the right silverlight player, or the right version of Java. That's exactly the point. Imagine dozens of them.
    - lisper 13y ago
      Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in. Dozens of languages? I very much doubt that will happen. Just as we only have a small handful of codexes that actually matter (Flash, Silverlight, H264, maybe ogg) I predict that we will end up with a small number of languages that actually matter: Javascript, Python, Ruby, and Scheme. Maybe CL. IMHO that would be a better world than the one we currently live in. Javascript is serviceable for its original purpose, but for serious webapps it's broken beyond redemption. NOTE: This is not to say that it is impossible to write serious webapps in Javasceript. Obviously it is possible. What I mean is that at some point the aggregate cost of dealing with Javascript's design flaws becomes greater than the aggregate cost of dealing with multiple browser scripting languages.
pekk 13y ago
You are right, I misspoke and would have said "in addition to"

chimeracoder 13y ago

While nothing uniquely "requires' Javascript, replacing it in an existing browser is no easy feat. Look at how much work has gone into making Dart work just in Chrome. And if any browser is going to replace Javascript, it's going to be Chrome (first), not Firefox - Mozilla is doubling-down on Javascript with both asm.js and FirefoxOS. Google is doubling-down on efforts to replace and/or subvert Javascripts, with both Dart and NaCl. Nothing uniquely qualifies Javascript now, but being the status quo is a qualification of sorts. Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).

grey-area 13y ago
Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers). I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it. It's a real shame we've ended up in a situation where the only API for manipulating the DOM is in js - script tags were not initially intended to be js only. Switching language would be the perfect opportunity to create a proper standard library for the web, by looking at the organic mess which is DOM access, js animation, etc, extracting the good parts, and throwing away all the rest. If it significantly improved dev productivity, and was available as a plugin initially for all browsers, people might be willing to experiment with it. There are political and technical problems with doing that of course, but it would be a great step forward for web development, and is not at all beyond the reach of a big browser vendor. I agree if it were to be anyone, it'd be Google.
- chimeracoder 13y ago
  > I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it You'll get no disagreement from me about the JS stdlib. I was shocked when I found the "correct" way to extract the day of the week from a Date object in Javascript (without third-party libraries): https://stackoverflow.com/questions/4822852/javascript-how-to-get-the-day-of-week-and-the-month-of-the-year https://stackoverflow.com/questions/4822852/javascript-how-t... [0] It would be a great feat if/when someone does it. But saying that "Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript" sort of ignores the amount of work required to actually do this (properly). [0] Of course, this code does already exist internally, as evidenced by (new Date).toString(); you just can't access it.

camus2 13y ago

Once you "accept" transpilation,you can use any language in the browser and you stop asking yourself these questions. You still need to know javascript though. Dart,CoffeeScript,Typescript,ClosureScript... IT's not like people dont have the choice today.And sourcemaps work well when debugging,usually.

davorb 13y ago
If we had LISP, we wouldn't really need CSS or HTML either. Everything could be represented with s-expressions and we would all reach nirvana.
- klibertp 13y ago
  Only if every single designer who happens to write some styles has paredit installed. Ditto for every non-technical user who would want to customize some template or something. Sexps are cool, but you really, really need proper tools to edit them efficiently. Without them it's very easy to make a mistake, which of course will make it to runtime, because it won't be a syntax error in most cases. That's the downside of having so little syntax. So I think that (for CSS) we'd either build very simple sexp based DSL using macros or we'd just create a compile-to-sexps human friendly syntax. On the plus side, with Lisps, that would be one evening to implement... :)
  - hajile 13y ago
    If you aren't already using templates, then you're probably doing it wrong. If you have a designer doing serious template work and that designer doesn't know anything, then you're probably doing it wrong. languages like haml and jade are very close to M-expression languages and could work as drop-in replacements for S-expressions just like they are used as <html> replacements at present or s-expr could be used. In addition, in the presence of a lisp language, the code <--> data relationship can be quite convenient.
  - rurban 13y ago
    Remember DSSSL anyone? Obviously worse was better

weland 13y ago

> Nothing uniquely qualifies Javascript. The kind and amount of technical expertise behind the development mass that drives most of the Web nowadays does, sadly.

rjsw 13y ago

It would have been easy to do this in IE too, there was a well defined COM interface to allow alternative scripting engines to be used.