5 ms·

What's next? "Advanced Programming in the Unix Environment: Now with Javascript!" ? Or "Linux Device Drivers: Javascript edition" ? Can we just accept that JS

by dysoco 13y ago

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?

jophde 13y ago
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 13y ago
  [deleted]
- erikpukinskis 13y ago
  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.
  - wpietri 13y ago
    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.
    - jophde 13y ago
      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.
      - cgag 13y ago
        Or Clojure, which has a good concurrency story as well as compiles to javascript.
      - wpietri 13y ago
        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.
  - beambot 13y ago
    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?
    - Tichy 13y ago
      What if JS is the best tool for the job?
      - beambot 13y ago
        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.
  - acjohnson55 13y ago
    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.
    - Tichy 13y ago
      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.
- mheathr 13y ago
  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.
d0m 13y ago
Maybe not everything, but to explain the concepts behind SICP, why not.
- spacemanaki 13y ago
  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.
  - 3rd3 13y ago
    Not to mention that if you are already learning the concepts taught in SICP, then learning Scheme is trivial.
  - d0m 13y ago
    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.
10098 13y ago
But I'm an intellectually lazy techno-hipster who doesn't want to learn new programming languages!!
agumonkey 13y ago
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.
- mbillie1 13y ago
  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?
  - agumonkey 13y ago
    > 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.
mundizzle 13y ago
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-least-power.html http://www.codinghorror.com/blog/2007/07/the-principle-of-le...

by dysoco 13y ago

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?

jophde 13y ago

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 13y ago
[deleted]
erikpukinskis 13y ago
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.
- wpietri 13y ago
  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.
  - jophde 13y ago
    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.
    - cgag 13y ago
      Or Clojure, which has a good concurrency story as well as compiles to javascript.
    - wpietri 13y ago
      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.
- beambot 13y ago
  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?
  - Tichy 13y ago
    What if JS is the best tool for the job?
    - beambot 13y ago
      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.
- acjohnson55 13y ago
  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.
  - Tichy 13y ago
    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.
mheathr 13y ago
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.

d0m 13y ago

Maybe not everything, but to explain the concepts behind SICP, why not.

spacemanaki 13y ago
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.
- 3rd3 13y ago
  Not to mention that if you are already learning the concepts taught in SICP, then learning Scheme is trivial.
- d0m 13y ago
  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.

10098 13y ago

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

agumonkey 13y ago

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.

mbillie1 13y ago
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?
- agumonkey 13y ago
  > 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.

mundizzle 13y ago

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-least-power.html http://www.codinghorror.com/blog/2007/07/the-principle-of-le...