Hacker News Reader

Hacker News

Comment by dysoco | Hacker News Reader

Full thread

dysoco

What'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?

View on HN

But I'm an intellectually lazy techno-hipster who doesn't want to learn new programming languages!!

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...

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.

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.

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.

Or Clojure, which has a good concurrency story as well as compiles to javascript.

Sorry, by "web stuff" I meant the client side plus the first tier of stuff. I agree that for serious computation I want something else. Thanks for the tip on Elixir, though; that looks appealing.

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?

Then so be it. "The best tool" is a complex multi-value optimization that includes intangibles like personal preference. For me personally, server-side js wouldn't make any sense (right now) -- it's not my preferred language and it doesn't have the same sort of library support as other langs.

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.

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.

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 more widely known and used than Scheme.

It's true that the ideas in the book transcend programming languages, and that the first 3 chapters could probably could be covered in JavaScript with little modification, if a little clumsily. But rewriting the 4th and 5th to include sections on parsing JavaScript would be quite challenging, and furthermore JavaScript does not have as simple semantics as Scheme, so there would be a loss of a great deal of elegance and beauty. The metacircular Scheme interpreter can run itself, which would be harder to do in JavaScript since its core is more rich and Scheme's core: objects, methods and so on complicate it quite a bit.

Not to mention that if you are already learning the concepts taught in SICP, then learning Scheme is trivial.

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.

and that metacircular evaluator is probably my favorite part of the (original) book right now...

"It's as if -- as if the key to the treasure is the treasure!"

i think the (new) book is valuable in that it might reach some people who have some mental block about just wanting to know what they "need" to know and think that all they need to know is javascript, but for those who just like learning? start scheming. it's freakin' awesome.

Reply on news.ycombinator.com