3 ms·

When you can generate javascript from s-exprs, you can use macros with javascript.

KirinDave 17y ago
So you can add first-order generated-code errors to your generated-code errors when your javascript generator has a problem or a new feature comes into play incorrectly. I understand that's nice and all, but couldn't you just write javascript? While it lacks macros, it is certainly dynamically expressive enough that you can do pretty much anything you could reasonably require. A cursory examination of Mootools and JQuery could tell you that.
- rincewind 17y ago
  > I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp." [...] > I understand that's nice and all, but couldn't you just write javascript? I agree with you on this point (JQuery is quite nice), but this is orthogonal to the CL vs. Clojure vs. $Framework debate. http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper/JavaScriptGenerator/GeneratorMethods.html http://api.rubyonrails.org/classes/ActionView/Helpers/Protot... http://clamato.net/ http://clamato.net/ http://github.com/collin/jabs http://github.com/collin/jabs http://en.wikipedia.org/wiki/Objective-J http://en.wikipedia.org/wiki/Objective-J
- JulianMorrison 17y ago
  If you are using all the higher-order features of javascript to make it terse and expressive, you are probably "doing it wrong" in terms of producing fast code in a selection of browsers. From this perspective, javascript is the compiler output language, like machine code. Parenscript would then be like assembly - a 1:1 mapping - but embedded in a powerful enough macro system that it can be wrapped into a readable DSL.
  - KirinDave 17y ago
    > you are probably "doing it wrong" in terms of producing fast code in a selection of browsers. And yet JQuery and Mootools are both incredibly fast, as benchmarks show. And yes, I'm aware of the model you're using, and reiterating explicitly what I implied isn't making your argument any stronger, in my opinion.
    - JulianMorrison 17y ago
      They are fast because they have been coded by experts. So maybe they look cute - would your code that looks as cute run as well? Probably not unless you can match them in knowing why.
      - KirinDave 17y ago
        Or by leveraging their work as their documentation suggests. Seriously, performant javascript is not some magical thing only wizards can attain. Performant _generic_ javascript is tough stuff, but just using the libraries is hardly JIT compiling.
    - sedachv 17y ago
      Which benchmarks for what? I'm not being smug, I really want to see some benchmarks that make sense. The only thing I've seen is either "jQuery version x.y.z. is % faster than jQuery version a.b.c." or "jQuery is % faster doing something than Prototype." Yes some of these libraries may be getting less slow, and some of them are less slow at doing certain things than other slow libraries, but the only thing that would make sense is to compare them to hand-written JS and see the trade-off in performance vs code size. Most jQuery application code I see is just adding layers over the DOM in a way that doesn't provide any extra expressive power or conciseness (frequently the opposite). Yes, selectors are cool, but only if you need to manipulate a document that's been generated by someone else. If you have control over how you generate HTML, you can actually keep track of your DOM elements in a way that doesn't involve searching at run-time and expresses domain concepts - I mean, imagine this!, actually program normal code.

So you can add first-order generated-code errors to your generated-code errors when your javascript generator has a problem or a new feature comes into play incorrectly. I understand that's nice and all, but couldn't you just write javascript? While it lacks macros, it is certainly dynamically expressive enough that you can do pretty much anything you could reasonably require. A cursory examination of Mootools and JQuery could tell you that.

rincewind 17y ago
> I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp." [...] > I understand that's nice and all, but couldn't you just write javascript? I agree with you on this point (JQuery is quite nice), but this is orthogonal to the CL vs. Clojure vs. $Framework debate. http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper/JavaScriptGenerator/GeneratorMethods.html http://api.rubyonrails.org/classes/ActionView/Helpers/Protot... http://clamato.net/ http://clamato.net/ http://github.com/collin/jabs http://github.com/collin/jabs http://en.wikipedia.org/wiki/Objective-J http://en.wikipedia.org/wiki/Objective-J
JulianMorrison 17y ago
If you are using all the higher-order features of javascript to make it terse and expressive, you are probably "doing it wrong" in terms of producing fast code in a selection of browsers. From this perspective, javascript is the compiler output language, like machine code. Parenscript would then be like assembly - a 1:1 mapping - but embedded in a powerful enough macro system that it can be wrapped into a readable DSL.
- KirinDave 17y ago
  > you are probably "doing it wrong" in terms of producing fast code in a selection of browsers. And yet JQuery and Mootools are both incredibly fast, as benchmarks show. And yes, I'm aware of the model you're using, and reiterating explicitly what I implied isn't making your argument any stronger, in my opinion.
  - JulianMorrison 17y ago
    They are fast because they have been coded by experts. So maybe they look cute - would your code that looks as cute run as well? Probably not unless you can match them in knowing why.
    - KirinDave 17y ago
      Or by leveraging their work as their documentation suggests. Seriously, performant javascript is not some magical thing only wizards can attain. Performant _generic_ javascript is tough stuff, but just using the libraries is hardly JIT compiling.
  - sedachv 17y ago
    Which benchmarks for what? I'm not being smug, I really want to see some benchmarks that make sense. The only thing I've seen is either "jQuery version x.y.z. is % faster than jQuery version a.b.c." or "jQuery is % faster doing something than Prototype." Yes some of these libraries may be getting less slow, and some of them are less slow at doing certain things than other slow libraries, but the only thing that would make sense is to compare them to hand-written JS and see the trade-off in performance vs code size. Most jQuery application code I see is just adding layers over the DOM in a way that doesn't provide any extra expressive power or conciseness (frequently the opposite). Yes, selectors are cool, but only if you need to manipulate a document that's been generated by someone else. If you have control over how you generate HTML, you can actually keep track of your DOM elements in a way that doesn't involve searching at run-time and expresses domain concepts - I mean, imagine this!, actually program normal code.