"An invasion of armies can be resisted; an invasion of ideas cannot be resisted" - http://en.wikiversity.org/wiki/Victor_Hugo_quote
This generation is going to be rewrite in Javascript/v8, everything that can be written in Javascript.
SICP translated to JavaScript
51–60 of 116 posts
Re: SICP translated to JavaScript
#52What'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?
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!
[deleted]
Re: SICP translated to JavaScript
#53What'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?
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 your lettuce until September".
It's useful to have it on the client, when you're in the garden and there's no connectivity, or when you tweak your settings and don't want to have to download a bunch of "conclusions" from the server. It's useful to have it on the server so that the server can send emails, pre-cache HTML for faster loading pages, etc.
If my server is written in Ruby (which is is right now) then I have to re-implement that entire system twice. That's double the code. It feels gross. And I can't help but feel like most web-apps have code like this that could be shared between the client and the server.
Re: SICP translated to JavaScript
#54Earlier 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…
Very well said.
> Look on github for how many people write shell scripts in ruby because they don't know how bash works.
I have seen this happen in a company I used to work for, when new system engineers came on board, but in this case it was Groovy.
Re: SICP translated to JavaScript
#55Obvious objections - JS has no tail call elimination, no macros, and state-changing is managed with entirely different conventions in Scheme. Also the conceit of SICP (not really justified) is that they don't have to teach you syntax, because homoiconicity. Still, I think it's a worthy pursuit to try to bring the insights of this book to a wider audience. Side note: the navigation is really irritating. The back butto…
>JS has no tail call elimination
Apparently this is changing with ES6.
Re: SICP translated to JavaScript
#56What'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?
Atwood's Law "any application that can be written in JavaScript, will eventually be written in JavaScript."
http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
Re: SICP translated to JavaScript
#57Earlier 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.
I'm a longtime perl user, and I don't know where my blind spots are. Are there any particular resources you would recommend for someone like me to get going quickly with python? In particular ones that specifically address the type of blind spot you mention?
The Python tutorial teaches the language fairly well: http://docs.python.org/2/tutorial/
The iterator section is http://docs.python.org/2/tutorial/classes.html#iterators. Here it is quickly. Suppose that an object has a __iter__ method which will return something with a next method that will, when it has exhausted the iterator, call StopIteration. Then all native looping constructs can loop over that object and it will just work.
If you call a function that internally calls yield and nowhere calls return, then you get back a generator, which is an object with those methods.
There is also syntax to construct such generators inline without even an explicit function.
All of the closure based looping stuff in HOP which supports potentially infinite streams? It is all built in!
Re: SICP translated to JavaScript
#58why, God, why?
Perhaps due to the increasing popularity of JavaScript and the decreasing accessibility or usage of Scheme.
SICP isn't a book about Scheme. It's a book about writing computer programs. Scheme was used because it imposes the minimum additional cognitive load. Worrying about all the warts in, e.g. Common Lisp (to say nothing about Javascript or Scala, say) would detract from the pedagogical mission of the book.
Re: SICP translated to JavaScript
#59Some people will stop at nothing to convert the world to JavaScript and Ruby. (please don't do the latter... or is it too late?)
The world is not entirely composed of consumer web startups. There are plenty of opportunities that don't share the tradeoffs inherent in the typical HN style environment.
Re: SICP translated to JavaScript
#60Obvious objections - JS has no tail call elimination, no macros, and state-changing is managed with entirely different conventions in Scheme. Also the conceit of SICP (not really justified) is that they don't have to teach you syntax, because homoiconicity. Still, I think it's a worthy pursuit to try to bring the insights of this book to a wider audience. Side note: the navigation is really irritating. The back butto…
tail call elimination can be implemented in javascript: http://raganwald.com/2013/03/28/trampolines-in-javascript.ht...
Trampolines are a solution to the same problem that tail-call elimination solves; they're not transparent to the programmer.