Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript right on the hardware

technical.io

Post reply on HN
Print view View original

271–280 of 320 posts

Re: JavaScript right on the hardware

#271

Post by PommeDeTerre »

lifeformed wrote: post #145
marssaxman wrote: post #124

Earlier quoted context omitted.

Not sure what you mean by that. I meant exactly what I said: I feel sorry for anyone whose linguistic toolbox is so limited that Javascript is their best option for writing low-level code for manipulating electronic devices. It is hard to imagine a more profound mismatch between the tool and the problem it is supposed to solve.

I just want to program a little thingy to do fun stuff, and this is it. I don't care about languages, I already know js.

I think that your "I don't care about languages, I already know js." attitude perfectly describes the problem with many JavaScript programmers.

This sort of proud basking in ignorance is shameful, and should be considered unacceptable.

It is absurd to limit yourself to learning about just one programming language, especially when that language is so rife with flaws, and perhaps the worst widely-used programming language ever.

It is also harmful to create code of any sort when holding such an attitude, even when done as a hobby. It shows a complete lack of care about doing things even remotely correctly.

I have to admit, I'm very disappointed to read a sentence like, "I don't care about languages, I already know js." here.

Re: JavaScript right on the hardware

#272

Post by esailija »

dkuntz2 wrote: post #194
DonPellegrino wrote: post #188

Earlier quoted context omitted.

It takes less than an hour to learn and get used to it if you know the standard Java-style OOP already. It's worth it and it'll give you a whole new opinion on what OOP means. I made this a while ago, see if you can figure out how it works: http://jsfiddle.net/AXTdj/

I know how it works, I just find it worse, by far. There's a whole lot more overhead to getting it working, specifically all of the foo.prototype stuff, and it doesn't require that everything be together. Sure, it's kinda nice that you're able to extends objects later on, but I'd rather have everything neatly declared in one place. It definitely does not "give me a whole new opinion on what OOP means", it furthers my…

Your entire complaint is very superficial and easy to fix with any convention you like. For example: http://jsfiddle.net/AXTdj/3/ I included "overhead" calculations.

Re: JavaScript right on the hardware

#273

Post by anonymoushn »

Tichy wrote: post #260
anonymoushn wrote: post #138

Earlier quoted context omitted.

Non-string values are not valid hash keys. Operations that should be type errors fail silently and return nonsense. The prototype system is less powerful than the OO system of basically every other scripting language. The language will never have continuations, so people who want real control flow are stuck using preprocessors to generate callback spaghetti. Encoding a particularly rigid mix of dynamic and lexical sc…

Sure if you prefer static typing then JS is not for you. Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there? I would love to use LISP, but the libraries simply aren't there. Last time I tried Racket, there wasn't even a library for JSON.

> Sure if you prefer static typing then JS is not for you.

I did not say anything about static typing. Most dynamic languages are not forced by their specs to coerce disparate types into utter garbage. I invite you to type the examples in the Wat talk into a REPL for any other dynamic language and see how many of them produce exceptions.

> Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there?

Before answering, I will point out that coroutines are equivalent to one-shot continuations, and coroutines that can be copied are equivalent to multi-shot continuations. Then, I am familiar with continuation implementations in the following languages: Python [1][2], Scala with any JVM runtime[3], Any JVM language with a particular runtime[4], C[5], Lua[6], Julia[7], and C++[8]. Of these, the ones for the JVM, C/C++, and Lua[9] are multi-shot continuations or equivalent to them, while Julia and Python are a bit more limited. I am not familiar with many languages, so I'm sure I've missed a lot of instances of this sort of feature.

> I would love to use LISP, but the libraries simply aren't there. Last time I tried Racket, there wasn't even a library for JSON.

I can't really speak to this because I haven't spent time trying to build real software using lisp.

[1] https://pypi.python.org/pypi/greenlet

[2] http://www.stackless.com/

[3] http://jim-mcbeath.blogspot.com/2010/08/delimited-continuati...

[4] http://oss.readytalk.com/avian/javadoc/avian/Continuations.h...

[5] http://en.wikipedia.org/wiki/Setcontext

[6] http://lua-users.org/wiki/CoroutinesTutorial

[7] http://docs.julialang.org/en/latest/manual/control-flow/

[8] http://www.boost.org/doc/libs/1_51_0/libs/context/doc/html/c...

[9] http://lua-users.org/lists/lua-l/2006-01/msg00652.html

Re: JavaScript right on the hardware

#274

Post by gmac »

seldo wrote: post #71
10098 wrote: post #54

Earlier quoted context omitted.

I don't have much problem with programming an embedded device in a high-level language, but why JS specifically? Why not Lua, which just as fast, and is better than javascript in many respects?

I would have thought this was obvious, but orders of magnitude more developers know Javascript than Lua[1], thanks largely to the popularity of browsers as a programming environment. According to some recent research[2], the three primary factors affecting the adoption of a programming language by developers are, in this order: 1. Libraries available 2. Familiarity 3. Performance And per the paper, this order of pref…

Also, of dynamic languages, JS is among the most performant, and many times faster than (say) Ruby.

Re: JavaScript right on the hardware

#275

Post by esailija »

teebrz wrote: post #135
proee wrote: post #47

Javascript doesn't support integers, so it doesn't seem like a good language for programming low level hardware. What about bit manipulation (XOR, AND, Shifting, etc)? This is critical for a lot of serial data communications and I/O controls.

JS supports integers; it just doesn't have an integer type so you can't always store, operate, etc on them efficiently (though a smart engine can do some of that for you). It has bitwise manipulation operations which treat the Number as a 32 bit int. There are also Typed Arrays which make it easier to work on raw binary data. Though yes, it can occasionally get a little finicky trying to interface a high level dynami…

And when the engine cannot do that for you, there is always Math.imul

Re: JavaScript right on the hardware

#276

Post by 14113 »

coldtea wrote: post #111
eob wrote: post #28

First off, this is cool. It is tremendously exciting to see the bar for hardware hacking getting lower and lower. To the people complaining "Why JS? C is fine!", remember that once the complaint was "Why C? ASM is fine!". At the same time, I can't help but grin that we on the CS side find a way to erase all the gains in performance and efficiency as soon as the EE guys make them. There has to be come kind of universa…

> At the same time, I can't help but grin that we on the CS side find a way to erase all the gains in performance and efficiency as soon as the EE guys make them. That's one way to see it. Another is that we don't erase them: we put them to use so programming can be more widespread, easier and more ambitious in scope. (E.g. you cannot practically write a 10.000.000 line program in ASM, whereas you can in C. Or you ca…

You can. Rollercoaster tycoon was originally written in pure ASM.

Allowing programming to be more widespread is a noble cause, but there comes a point (and I think it is approaching rapidly) where you layer so much abstration between the machine and the programmer, that they're guaranteed to write poor, or at least slow code. We need to find a middle ground, and I think javascript pulls in the wrong direction to this.

Re: JavaScript right on the hardware

#277

Post by 14113 »

polarix wrote: post #127
fsniper wrote: post #114

Earlier quoted context omitted.

Everybody thinks they know javascript, but on the contrary nobody actually knows it. It's a very twisted and powerful language. It has many quirks and many unknowns. Most of the time if one thinks s/he knows javascript, actually s/he knows a higher level abstraction library and DOM built on javascript like Jquery.

Some people do know javascript. Implementations differ, but are getting more standardized as time goes on. Without the DOM and browser environment APIs, it gets a lot simpler. Do you think fewer people actually know javascript than actually know C++?

C++ is a bad example. C itself is mindblowinly complex, and C++ layers more on top of that. A better example might be Python, or possibly Lua. Languages that have been designed, rather than grown organically, unlike C++/C/Javascript.

Re: JavaScript right on the hardware

#278

Post by euroclydon »

Florin_Andrei wrote: post #148
icebraining wrote: post #141

Earlier quoted context omitted.

What makes the Arduino non-"bare"? The Arduino language is just C++, which gets compiled using gcc and uploaded using avrdude. It's not exactly running on a VM or using an interpreted language.

Sure, but with Arduino you're still floating on top of the Wiring libraries for almost anything you do. Coding a bare-metal AVR is a bit different: http://florin.myip.org/blog/how-make-halloween-creepy-blinki... There's no significant difference, unless you want fully predictable real-time behavior (of which my piece of code is NOT an example, but that's all I have online). Most people shouldn't care.

Thanks for sharing. I'm working (very slowly at the moment) on an AVR simulator in order to teach myself C. I think this is a great little program to compile and test with.

Re: JavaScript right on the hardware

#279

Post by gmac »

PommeDeTerre wrote: post #264
thedufer wrote: post #212

Earlier quoted context omitted.

Well, that's just unnecessarily offensive. I'm proficient in Python, Java, and C, and was at some point also fluent in PHP, Ruby, and Lisp. While I wouldn't particularly enjoy coding in Javascript, CoffeeScript is, to date, the best language I've worked with. I debug in JavaScript, so I'm not that far away from it. Why is "class-based OO" necessary? There's nothing wrong with prototypal inheritance. The way modules a…

There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept. I find your arguments somewhat odd. You do openly admit that you "wouldn't particularly enjoy coding in Javascript". People don't say such things about good programming languages, especially when arguing in favor of them to some extent. I also find it odd that you argue that there's nothing wrong with prot…

There's nothing wrong with admitting that JavaScript is a really bad language.

Your use of the word 'admitting' is peculiar. There's nothing wrong with claiming that JS is bad. There's also nothing wrong with claiming it's good.

I enjoy programming in CoffeeScript more than any other language I've used (Ruby, Python, Objective-C, a little Java, a little C). Plus, as dynamic languages go, it's fast. To me, these two things make CoffeeScript a fantastic language.

And since CoffeeScript is just syntactic sugar on top of JavaScript, well, I suppose JavaScript must at heart be a fantastic language too.

(Evidently today's my "someone is wrong on the Internet" day).

Re: JavaScript right on the hardware

#280

Post by esailija »

nfoz wrote: post #263
ontouchstart wrote: post #118

JavaScript is the most deployed dynamic embedded programming language in the world (consider all the web browsers on desktop computers and mobile devices). If we expland this environment to customer hardware, we also expand our view of UI/UX to a different level. We should thank Moore's law.

Are you implying that JS developers know more about UI/UX than others? Most websites have horrible usability, ranging from "everything in CSS popups!" to "every site uses a different widget toolkit, deficient in new and exciting ways"..... I hope I just don't understand your comment.

Yeah GUI widgets done in js in general for some reason have really poor quality and no attention to subtle details that make up the polished experience on desktop. Well at least they take 2 KB instead of 5 KB gzipped, that's totally a win.
Post reply on HN