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

311–320 of 320 posts

Re: JavaScript right on the hardware

#311

Post by TheZenPsycho »

Aldo_MX wrote: post #297
TheZenPsycho wrote: post #179

Earlier quoted context omitted.

Both javascript and lua were designed for very similar goals. It just so happens that the designers of Lua had more time to do it- plus they aren't burdened with the need to always be backwards compatible, so lua (now at version 5) breaks scripts written for older versions. So they each have their trade offs.

I'm pretty confident that if Lua were as widespread as JavaScript is, a backwards incompatible change would be less likely to happen, although with Corona SDK, I'm also confident that Lua will have an opportunity to shine :).

I"m not sure that "widespread" really would do it. The other difference between Javascript and Lua is that- while Javascript has been embedded in adobe software, modified to become actionscript, and is the scripting language in some games, its primary use has always been the web- with its specific DOM api. The web carries with it the backwards compatibility burden.

Lua doesn't have to be backwards compatible because nobody has to upgrade to the latest version of lua- and there isn't much of a standard library to break anyway- All the things you'd traditionally use a library for are provided by the outer application lua is embedded in- an application likely not written in lua itself- and so if you do decide to upgrade your app/game the only thing you break is individual scripts.

Re: JavaScript right on the hardware

#312

Post by zhemao »

Tichy wrote: post #239
wiredfool wrote: post #58

Earlier quoted context omitted.

I don't see a price yet for this one. I like the pi (and the beaglebone) because they've already got the network hardware, but the gpio isn't as robust as on the arduino (3.3v vs 5v, very low current capacity on the pi, and no analog io). I can't say I particularly want the javascript, but if they've got wifi and arduino compatible gpio for ~ $25, then I can find a use for it.

Does the Pi have WiFi, though? Mine doesn't, but perhaps I don't have the latest model.

No it doesn't, but since it has USB ports you can augment it with a USB wifi module. A word of warning though. If you're thinking of buying one of these, make sure to check that it has good Linux support.

Re: JavaScript right on the hardware

#313

Post by fsniper »

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++?

Of course some people do know Javascript inside out, but how many?

Re: JavaScript right on the hardware

#314

Post by catwell »

tomlu wrote: post #283
coreyja wrote: post #109

Earlier quoted context omitted.

Slightly off topic, but is it just me or has Lua gotten a lot of attention on HN in the past weekish? I haven't heard much of Lua before but recently it seems to have come up a lot more. And even more off topic (sorry), what makes Lua better/different than other scripting languages? EDIT: On jacobwcarlson suggestion, I Googled Lua vs Python, and found this Wiki, http://lua-users.org/wiki/LuaVersusPython Not a speed c…

Lua is elegant, small and fast, especially when you're using LuaJIT. It's the language I reach for first when I need to embed a scripting language in a system (perhaps to replace configuration files). Its only real drawback is a lack of libraries/package manager compared to, say, Python/Ruby (respectively). I guess some people might miss built-in support for classes.

There are package managers for Lua. The main one is called LuaRocks.

Re: JavaScript right on the hardware

#315

Post by Ygg2 »

pjmlp wrote: post #285
Ygg2 wrote: post #237

Earlier quoted context omitted.

As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting? People's curiosity is what motivates them to experiment and learn new things, not how or what language they learn (I started with Basic which apparently causes brain damage and I'm getting along fine). If they are curious on their own, they'll pick up da…

> As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting? Uau!? Do such universities exist?

You can write Java in any language if you are persistent enough.

Re: JavaScript right on the hardware

#316

Post by Aldo_MX »

TheZenPsycho wrote: post #311
Aldo_MX wrote: post #297

Earlier quoted context omitted.

I'm pretty confident that if Lua were as widespread as JavaScript is, a backwards incompatible change would be less likely to happen, although with Corona SDK, I'm also confident that Lua will have an opportunity to shine :).

I"m not sure that "widespread" really would do it. The other difference between Javascript and Lua is that- while Javascript has been embedded in adobe software, modified to become actionscript, and is the scripting language in some games, its primary use has always been the web- with its specific DOM api. The web carries with it the backwards compatibility burden. Lua doesn't have to be backwards compatible because…

With a widespread adoption more security-related issues and bugs get discovered, with new security-related issues and bugs comes new fixes, and those fixes (especially the security-related ones) IMO are the incentive to update.

Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment.

Your product exist because it solves a problem, and the moment your product gives more problems than the ones it solves, you discourage your users to use your product and they begin to look for options, and if an option that meets their needs doesn't exist they will stall (ex. Windows XP).

This means extra effort, since you have to maintain at least the most used major versions, and at the very least provide security updates to your users. Fragmentation is a headache migraine that you want to avoid whenever it's possible...

With a widespread adoption you have to evaluate deeply whether the fragmentation troubles are worth the value the backwards-incompatible changes will provide. It's not the same trouble having a hundred users, than having a billion users.

Re: JavaScript right on the hardware

#317

Post by takikawa »

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.

> Last time I tried Racket, there wasn't even a library for JSON.

That's changed since then: http://docs.racket-lang.org/json/index.html

Re: JavaScript right on the hardware

#318

Post by TheZenPsycho »

Aldo_MX wrote: post #316
TheZenPsycho wrote: post #311

Earlier quoted context omitted.

I"m not sure that "widespread" really would do it. The other difference between Javascript and Lua is that- while Javascript has been embedded in adobe software, modified to become actionscript, and is the scripting language in some games, its primary use has always been the web- with its specific DOM api. The web carries with it the backwards compatibility burden. Lua doesn't have to be backwards compatible because…

With a widespread adoption more security-related issues and bugs get discovered, with new security-related issues and bugs comes new fixes, and those fixes (especially the security-related ones) IMO are the incentive to update. Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment. Your product exist because it solves a problem, and the moment…

You're not wrong, but I think with lua the fragmentation problem is pushed out to the app developers who embed lua in their various games and applications. Do the developers of lua concern themselves much with this? I suppose slightly, but mostly in the form of documenting what's different and how to convert old code to new code. The lua philosophy seems to be that a simpler/smaller implementation trumps backwards compatibility.

Re: JavaScript right on the hardware

#319

Post by Aldo_MX »

TheZenPsycho wrote: post #318
Aldo_MX wrote: post #316

Earlier quoted context omitted.

With a widespread adoption more security-related issues and bugs get discovered, with new security-related issues and bugs comes new fixes, and those fixes (especially the security-related ones) IMO are the incentive to update. Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment. Your product exist because it solves a problem, and the moment…

You're not wrong, but I think with lua the fragmentation problem is pushed out to the app developers who embed lua in their various games and applications. Do the developers of lua concern themselves much with this? I suppose slightly, but mostly in the form of documenting what's different and how to convert old code to new code. The lua philosophy seems to be that a simpler/smaller implementation trumps backwards co…

You are also right, but when a project has small adoption, usually the users are people that feel identified with and like the project.

But suddenly the project becomes a product, and the product gets adoption (every time more).

The users will use your product because of different reasons (ex. it's what other people use / it's what can solve better X problem / it's what I got recommended / etc.), the users that like and feel identified with the project become a small niche in comparison with the people that need the product.

The users become the ones that shape the product, you have to balance between:

Feature A. Which is what you want to do for the project. Feature B. Which people are telling you they need for the product.

Will you develop exclusively "Feature A"s, because you are following a philosophy?

Think for a moment what would had happened if Microsoft had adopted Lua for IE3 instead of reverse engineering Netscape's JavaScript (assuming that IE would have still won the 90's Browser Wars thanks to Lua). Are there flying cars in that parallel universe? Is Lua uglier than today's JavaScript? Has Douglas Crockford written Lua: The Good Parts yet? :)

Re: JavaScript right on the hardware

#320

Post by 14113 »

naunga wrote: post #287
14113 wrote: post #277

Earlier quoted context omitted.

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.

C++ was grown organically? I think Bjarne Stroustrup would disagree.

By that I'd mean the way more and more complexity has been layered on over the years.
Post reply on HN