Meta-gripe: the navigation seems to use some kind of asynch loading without pushing to the browser history stack, and I'm finding it very difficult to move back and forth from the ToC to chapters. Maybe this can be addressed.
SICP translated to JavaScript
71–80 of 116 posts
Re: SICP translated to JavaScript
#72Earlier quoted context omitted.
Maybe not everything, but to explain the concepts behind SICP, why not.
As others have pointed out, chapters 4 and 5 are as wonderful and rich as they are because Scheme is homoiconic which makes writing Scheme interpreters and compilers in Scheme very easy -- no need for hairy lexing and parsing steps. Since (IMHO) these chapters are the best introduction to the study of programming languages and their implementation, it would be a real shame to discard them simply because JavaScript is…
By the way, I read SICP and it's one of my favorite book. It's unbelievable how quick things are hacked... i.e. 2 pages and you've got a SQL-like language. Also, I must agree that Scheme really fit with the theme and the book. It's clean, it's concise, there's no funky syntax to learn. And, I also must agree that the interpreter and compiler parts would be much much more complex in JS.
All that being said, I still think lots of great concepts behind SICP can be explained with JS as the main language instead of scheme. If it can help some people to feel at home and quick the book, that's just great. They'll most likely like it and then read the real SICP for the other parts.
Lastly, I must agree that when I read SICP the first time, it was also to learn scheme as a side-effect. But it's not necessarily everyone.
Re: SICP translated to JavaScript
#73Earlier quoted context omitted.
I know HOP. It depresses me how much of HOP is irrelevant in Python because they have proper iterators. And how few Perl programmers realize that these days the lack is a major omission in the language.
JavaScript doesn't have them either, until you include a functional toolchain library like Underscore. Does Perl have any similar library?
There's List::Util and List::MoreUtils: http://search.cpan.org/~adamk/List-MoreUtils-0.33/lib/List/M...
Re: SICP translated to JavaScript
#74What's next? "Advanced Programming in the Unix Environment: Now with Javascript!" ? Or "Linux Device Drivers: Javascript edition" ? Can we just accept that JS is not for everything?
Drivers maybe not, but after reading coreutils/ls source code, I think most of the userland part of my OS would probably benefit from a rewrite in js/v8.
In terms of the aesthetic pleasure you derive from reading the source, or the functionality of the artifact? I mean, saying everything but drivers would be better in js/v8 sounds absurd to me. You think the Linux kernel would be better performant written in js/v8? Your GDE? Window manager? Package manager?
Re: SICP translated to JavaScript
#75Earlier quoted context omitted.
I always thought this would be self-evident to people, but apparently not: The reason why I want to have Javascript on both the client and the server is so I can re-use code. My software has a fairly large chunk of code which is a gardening expert system. I'm hesitant to call it AI because it's so dumb, but it's along those lines. It knows things like "If you live in Phoenix and it's April, you should wait to plant y…
Yeah, I'm with you on this. Aesthetically, I'm in the "ugh, Javascript" camp. But practically, I recognize that I should just get over this. For web stuff, I fully expect that I'll be writing everything in JS in a few years.
Considering it doesn't even support multiple core processors, and processors are only coming out with more and more cores, I doubt it. This is assuming you are actually doing something that requires performance. Check out Elixir or Go if you want something new that actually makes technical sense.
Re: SICP translated to JavaScript
#76Earlier quoted context omitted.
Well, I never used Ruby, besides to see what this Ruby on Rails was all about and I already knew Python since the version 1 days. For me the only place for JavaScript is on the browser. For anything else, there are endless languages to choose from.
For anything else, there are endless languages to choose from. The Americans have taken over and the Americans have, based on their own linguistic experience, decided most people can only handle one spoken language and one programming language. For some of us, we can handle six programming languages and be fine. For "average" people, they're lucky to get one programming language, so it was decided to fad-hype-hipster…
> Look on github for how many people write shell scripts in ruby because they don't know how bash works. You can find the same over-syntax'd-programming-environment-as-shell-script with node too. We're the exceptions. They can't handle the truth.
As someone who has done this (and who currently works in C), I will say only that shell scripts translated to Ruby can be a lot easier to read and maintain than those written in bash... if I get to the point where I'm having to pipe to more than two of awk/sed/grep I will generally just write it in Ruby, because then my mother could read it. YMMV though. In every other sense I agree with you entirely, and I think the proliferation of JS rewrites of things that work in actually-designed languages is appalling.
Re: SICP translated to JavaScript
#77Meta-gripe: the navigation seems to use some kind of asynch loading without pushing to the browser history stack, and I'm finding it very difficult to move back and forth from the ToC to chapters. Maybe this can be addressed.
Check out my new library, SICPinJSnavigation.js
Re: SICP translated to JavaScript
#78Earlier quoted context omitted.
I just want to meet one programmer who can work on server side code, client side code, etc who can't handle them being written in different languages. This fad just doesn't make any sense to me. Let's reinvent the wheel so we can have JSON literals instead of Ruby hashes!
I always thought this would be self-evident to people, but apparently not: The reason why I want to have Javascript on both the client and the server is so I can re-use code. My software has a fairly large chunk of code which is a gardening expert system. I'm hesitant to call it AI because it's so dumb, but it's along those lines. It knows things like "If you live in Phoenix and it's April, you should wait to plant y…
Sounds like that part of the system could be written once (in any language) and then encapsulated and treated as a local service... (analogous to using a local copy of SQLite if you need a db). Then you can use the "best tool for the job" on the client and-or server?
Re: SICP translated to JavaScript
#79Earlier quoted context omitted.
I know HOP. It depresses me how much of HOP is irrelevant in Python because they have proper iterators. And how few Perl programmers realize that these days the lack is a major omission in the language.
JavaScript doesn't have them either, until you include a functional toolchain library like Underscore. Does Perl have any similar library?
JS 1.7, already available in some browsers and bleeding edge Node, has iterators and generators.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
Re: SICP translated to JavaScript
#80Earlier quoted context omitted.
Drivers maybe not, but after reading coreutils/ls source code, I think most of the userland part of my OS would probably benefit from a rewrite in js/v8.
In terms of the aesthetic pleasure you derive from reading the source, or the functionality of the artifact? I mean, saying everything but drivers would be better in js/v8 sounds absurd to me. You think the Linux kernel would be better performant written in js/v8? Your GDE? Window manager? Package manager?
> most of the userland part of my OS
I was careful in picking my words. I don't think Javascript is suited to express kernel level system control. There are many windows managers written in dynamic languages (lua, python, lisp). GDE = Desktop Environment ? I don't know if computing Package Manager dependency graphs be that slower if written in js, probably.
Beside the point was not about micro benchmark performance but about separation of concerns and reuse, more than a third of ls is output formatting.