5 ms·

The only things that are powerful and expressive in JavaScript are bastardized beyond recognition versions of ideas from Lisp, Smalltalk and Self. You get those

by stiff 13y ago

The only things that are powerful and expressive in JavaScript are bastardized beyond recognition versions of ideas from Lisp, Smalltalk and Self. You get those dynamic mechanisms that we know for 50 years now (lambda expressions and runtime method dispatch, oh wow) to be useful but without learning any lessons learned in those 50 years about how to design a coherent language based on those concepts, you just get a hodgepodge of language constructs that don't add up together to form a useful toolkit. It might look nice in a 30 line program where you don't care about performance, code readability (and boy does this code look ugly) and bugs and maintenance costs. Ruby or Smalltalk have an object system for doing those kinds of things that was actually designed and not evolved by committees and corporations, so that your meta-programming doesn't have to always be only eval and .bind in various incarnations (unsafe, inconvenient and slow). I can't imagine how this thing here that makes evaluating "A1" perform a function call fits into the rest of JavaScript and why the hall was it even introduced: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Not to mention the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope. In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains. I congratulate the author of this code as much as everyone for finding an unexpected and very creative use for those features, but this doesn't make them great.

thatthatis 13y ago
All valid points. With the norvig example, the longer I look at it the more I like python. With this js example, the more I look at it the more I like python. Sadly, I can't really run python in the browser.
- davidbielen 13y ago
  Kinda: http://www.brython.info/index.html http://www.brython.info/index.html
  - thatthatis 13y ago
    Yeah, I'm aware of this and emscripten. So far, to me, they don't look viable for DOM manipulation.
    - adambard 13y ago
      Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your perspective) You really can think javascript and write coffeescript.
      - thatthatis 13y ago
        You make a convincing argument.
        adambard 13y ago
        Thanks! If you're looking for ways to ease the burden of compiling it yourself, my favorite tools are django-pipeline (for django) and middleman (for static sites). Both of these let you treat coffeescript files as first-class while you develop.
      - spion 13y ago
        Consider ES6 too. It also does a good job at removing some Javascript quirks and adds sensible looping constructs, list comprehensions, generators and generator comprehensions, proxies, rest/spread arguments (removing the need for the magical `arguments` identifier), classes (just sugar for what we already wire up with prototypical inheritance), modules, fat arrow functions etc. No help on the DSL front though - still stuck with various kinds of brackets and parens. On the other hand, it doesn't do the utterly horrible mistake of conflating variable declaration and variable assignment while forbidding shadowing, resulting with surprise bugs and spooky action at a distance.
lelandbatey 13y ago
I agree, saying "Wow, this is a viable and useful language" because you can do something in just a few highly unreadable lines seems... like a pretty odd judgment. It'd be a bit like saying that C is a great language because someone wrote a raytracer that fits on a business card[0] using it. [0] http://fabiensanglard.net/rayTracing_back_of_business_card/ http://fabiensanglard.net/rayTracing_back_of_business_card/
- chc 13y ago
  This code is fairly readable. It takes one or two shortcuts, but it's much closer to real code than to golf.
- hernan604 13y ago
  its called "Abstraction"
jlgreco 13y ago
Imagine if management had not vetoed non "Java-like" syntax's during javascripts creation. Maybe Brendan Eich could have gotten a decent scheme dialect into the browser instead, people could have learned it (because in hypothetical retrospect, what else were they going to do? Not learn it?), and we would be in a far more pleasant position today...
- CamperBob2 13y ago
  They would have learned whatever Java/C-derived scripting language that Microsoft came up with instead.
  - jlgreco 13y ago
    That was likely the fear at the time, but what we actually saw was Javascript became popular because it was useful and there wasn't really anything else like it. It became popular, so Microsoft threw in with it too. In order for that to have not happened, it would have had to be so unpopular that Microsoft would decide it wasn't worth adopting, but still popular enough to get Microsoft on board with the general idea. I just don't think that is likely; people would have sucked up a scheme-based javascript even if it was a tad unfamiliar; it was that useful. (Not to mention, going with the cynical "three E's" theory of 90s Microsoft, they would have at least first adopted it before perverting it.) I think people overplay the importance of being C-like. AutoLISP hit a bit earlier and found a very strong following in a non-programmer niche. People doing web development were already fucking around in HTML of course, so clearly they could wrap their heads around things over than curly braces.
    - TheZenPsycho 13y ago
      that is a weird and complicated take. microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape. simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.
robomartin 13y ago
So....I wonder...what's your idea of what should be a proper language to have in the browser? Note: This isn't criticism of your view nor am I taking sides. I am wondering --since you have a strong opinion on this front-- what you think the solution might look like. I mean, are you looking at the idea of having something like python natively available at the browser?
wwweston 13y ago
> (and boy does this code look ugly) At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly. > your meta-programming doesn't have to always be only eval and .bind in various incarnations I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS. > unsafe, inconvenient and slow Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting. > the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with. > In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains. The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option. > this doesn't make them great. No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.
- jgraham 13y ago
  > "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.
SimHacker 13y ago
What breaks my heart when someone claims that JavaScript was inspired by Self, is how Self was all about the wonders of multiple inheritance and dynamically mutable parent slots. JavaScript totally missed the boat on that one, with only one prototype slot, and the only time you can set it is when you create the object with "new".
SimHacker 13y ago
I recently found myself needing to use "with", and hating myself for it. Does anyone know a better way to do this in JavaScript? // Take an array of context dictionaries, and return a // function that evaluates a string in those contexts. // I fully realize how horrible this code is, and that // it only supports up to ten contexts. I feel terrible // about it, as I should, but I would feel even worse // if it were impossible to do this. But isn't there // a simpler way to do this is JavaScript? Maybe I // could use __proto__ inheritence, but I was hoping // to avoid. function evalInContextsFunction(_contexts) { var _contextCount = _contexts.length; if (_contextCount == 0) { return function evalInContexts(_text) {return eval(_text)}; } with (_contexts[0] || {}) { if (_contextCount == 1) { return function evalInContexts(_text) {return eval(_text)}; } with (_contexts[1] || {}) { if (_contextCount == 2) { return function evalInContexts(_text) {return eval(_text)}; } [...and so on...]

by stiff 13y ago

thatthatis 13y ago

All valid points. With the norvig example, the longer I look at it the more I like python. With this js example, the more I look at it the more I like python. Sadly, I can't really run python in the browser.

davidbielen 13y ago
Kinda: http://www.brython.info/index.html http://www.brython.info/index.html
- thatthatis 13y ago
  Yeah, I'm aware of this and emscripten. So far, to me, they don't look viable for DOM manipulation.
  - adambard 13y ago
    Consider coffeescript. It does a good job at removing nuisance quirks from Javascript, and adding some python-esque features (sensible looping constructs, list comprehensions, etc.), while maintaining logical equivalence with the javascript it compiles to. (It also mirrors some of the syntactic features of ruby that make that language so appropriate for producing DSLs, which is a feature or a bug depending on your perspective) You really can think javascript and write coffeescript.
    - thatthatis 13y ago
      You make a convincing argument.
      - adambard 13y ago
        Thanks! If you're looking for ways to ease the burden of compiling it yourself, my favorite tools are django-pipeline (for django) and middleman (for static sites). Both of these let you treat coffeescript files as first-class while you develop.
    - spion 13y ago
      Consider ES6 too. It also does a good job at removing some Javascript quirks and adds sensible looping constructs, list comprehensions, generators and generator comprehensions, proxies, rest/spread arguments (removing the need for the magical `arguments` identifier), classes (just sugar for what we already wire up with prototypical inheritance), modules, fat arrow functions etc. No help on the DSL front though - still stuck with various kinds of brackets and parens. On the other hand, it doesn't do the utterly horrible mistake of conflating variable declaration and variable assignment while forbidding shadowing, resulting with surprise bugs and spooky action at a distance.

lelandbatey 13y ago

I agree, saying "Wow, this is a viable and useful language" because you can do something in just a few highly unreadable lines seems... like a pretty odd judgment. It'd be a bit like saying that C is a great language because someone wrote a raytracer that fits on a business card[0] using it. [0] http://fabiensanglard.net/rayTracing_back_of_business_card/ http://fabiensanglard.net/rayTracing_back_of_business_card/

chc 13y ago
This code is fairly readable. It takes one or two shortcuts, but it's much closer to real code than to golf.
hernan604 13y ago
its called "Abstraction"

jlgreco 13y ago

Imagine if management had not vetoed non "Java-like" syntax's during javascripts creation. Maybe Brendan Eich could have gotten a decent scheme dialect into the browser instead, people could have learned it (because in hypothetical retrospect, what else were they going to do? Not learn it?), and we would be in a far more pleasant position today...

CamperBob2 13y ago
They would have learned whatever Java/C-derived scripting language that Microsoft came up with instead.
- jlgreco 13y ago
  That was likely the fear at the time, but what we actually saw was Javascript became popular because it was useful and there wasn't really anything else like it. It became popular, so Microsoft threw in with it too. In order for that to have not happened, it would have had to be so unpopular that Microsoft would decide it wasn't worth adopting, but still popular enough to get Microsoft on board with the general idea. I just don't think that is likely; people would have sucked up a scheme-based javascript even if it was a tad unfamiliar; it was that useful. (Not to mention, going with the cynical "three E's" theory of 90s Microsoft, they would have at least first adopted it before perverting it.) I think people overplay the importance of being C-like. AutoLISP hit a bit earlier and found a very strong following in a non-programmer niche. People doing web development were already fucking around in HTML of course, so clearly they could wrap their heads around things over than curly braces.
  - TheZenPsycho 13y ago
    that is a weird and complicated take. microsoft had visual basic in the browser, working like php works. that was microsoft's vision, which would have been the web if netscape didn't still have significant market share. IE had to implement javascript to be compatible with pages written for netscape. simple as that. just microsoft's famous "embrace, extend, extinguish" strategy at work.

robomartin 13y ago

So....I wonder...what's your idea of what should be a proper language to have in the browser? Note: This isn't criticism of your view nor am I taking sides. I am wondering --since you have a strong opinion on this front-- what you think the solution might look like. I mean, are you looking at the idea of having something like python natively available at the browser?

wwweston 13y ago

> (and boy does this code look ugly) At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly. > your meta-programming doesn't have to always be only eval and .bind in various incarnations I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS. > unsafe, inconvenient and slow Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting. > the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with. > In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains. The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option. > this doesn't make them great. No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.

jgraham 13y ago
> "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.

SimHacker 13y ago

What breaks my heart when someone claims that JavaScript was inspired by Self, is how Self was all about the wonders of multiple inheritance and dynamically mutable parent slots. JavaScript totally missed the boat on that one, with only one prototype slot, and the only time you can set it is when you create the object with "new".

SimHacker 13y ago

I recently found myself needing to use "with", and hating myself for it. Does anyone know a better way to do this in JavaScript? // Take an array of context dictionaries, and return a // function that evaluates a string in those contexts. // I fully realize how horrible this code is, and that // it only supports up to ten contexts. I feel terrible // about it, as I should, but I would feel even worse // if it were impossible to do this. But isn't there // a simpler way to do this is JavaScript? Maybe I // could use __proto__ inheritence, but I was hoping // to avoid. function evalInContextsFunction(_contexts) { var _contextCount = _contexts.length; if (_contextCount == 0) { return function evalInContexts(_text) {return eval(_text)}; } with (_contexts[0] || {}) { if (_contextCount == 1) { return function evalInContexts(_text) {return eval(_text)}; } with (_contexts[1] || {}) { if (_contextCount == 2) { return function evalInContexts(_text) {return eval(_text)}; } [...and so on...]