What an abomination.
Wow, stay classy.
SICP translated to JavaScript
101–110 of 116 posts
Re: SICP translated to JavaScript
#102Earlier 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 are plenty of iterator/generator libraries on CPAN. My personal favourite is Coro::Generator - https://metacpan.org/module/Coro::Generator
Re: Underscore... there is a Perl port - http://vti.github.io/underscore-perl/
Re: SICP translated to JavaScript
#103What'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!
If the language can do so competently, why not? I think that would be a great leap forward for programming as it would consolidate efforts developing libraries, documentation, and tools.
Re: SICP translated to JavaScript
#104Background: this is the textbook used for a class at NUS (National University of Singapore). Previous iterations of the class, CS1101S, used the original scheme version of SICP, but omitted chapters 4 and 5 in the interest of time. [1]
I took the scheme version of the class and learned a ton. From what I've heard, the reasons for the switch included javascript being more practical and the previous professor deciding to take a break from teaching that class. Basically, many of the reasons overlap with that for Berkeley switching 61A from scheme to python [2].
I've also heard that the javascript version of the class is just as rigorous and challenging as the scheme version.
Shameless plug: if you want an interactive version of SICP in the original scheme, check out http://xuanji.appspot.com/isicp/1-1-elements.html
[1] Which might explain why the lack of macros in javascript wasn't a concern
Re: SICP translated to JavaScript
#105Obvious 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…
It might be worth noting that this class (CS1101S in NUS) stops at chapter 3 of SICP. I took the previous scheme version of the class.
Btw, I'm curious as to why the HOJ book didn't get taken down? I checked and the HOP book is not released under a license that allows for derivative works. I'm curious because I've made an interactive version of SICP (using scheme) and I can't find any other books to do this to because no one releases books under permissive enough licenses.
Re: SICP translated to JavaScript
#106Earlier quoted context omitted.
> 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 writte…
You found the one exception. There's a fuzzy line when dealing with shell scripts. If you're just iterating over a directory and checking some files, that's great shell script territory. If you're making a launcher script for another program to set the environment, check directories, fix permissions, and run pre-flight checks, that's great for shell script. But, sometimes we end up with feature creep. You start out w…
> If you're just iterating over a directory and checking some files
Unfortunately, I very frequently see this in shell scripts...
ls $SOME_PATH | awk...
Re: SICP translated to JavaScript
#107Earlier quoted context omitted.
And everyone is better than the average. :) Honestly, HN too has hordes of people who can't write FizzBuzz. No reason to feel elitist for anybody really.
FizzBuzz seems to be an American thing. I have been coding since 1986 and only learned about it via the usual HN hiring discussions.
Most programmers never heard of Fizzbuzz, the point of it is merely to screen out candidates who can't come up with their own solutions to problems.
A lot of so-called experts aren't capable of doing more than copy other people's solutions. Fizzbuzz offers a simple but new problem for candidates to solve.
Re: SICP translated to JavaScript
#108Earlier 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…
Fortunately, I think we're entering an era where JS can be a nearly transparent target language for translation from the languages of our choice, with things like asm.js and source maps. We're not quite there yet, but it definitely seems like where we're going.
I'd prefer the other way round. JavaScript is better than most popular programming languages (including Python). It is not perfect, so I consent there might better languages out there.
Re: SICP translated to JavaScript
#109Earlier 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…
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?
What if JS is the best tool for the job?
Re: SICP translated to JavaScript
#110Earlier quoted context omitted.
Perhaps due to the increasing popularity of JavaScript and the decreasing accessibility or usage of Scheme.
SICP uses Scheme, not Common Lisp. Scheme is a deliberately minimalist language, which is fairly accessible and easy to write your own implementation of. In fact, in SICP, you do that, a couple of times, writing first a Scheme interpreter, then extending it in various ways like adding logic programming capabilities, then you write a virtual machine and a compiler that compiles down to that virtual machine. JavaScript…
JavaScript is rather minimalist as well. It has some warts, but they are easy to avoid.