151–160 of 320 posts
Forgive me for not being hip but why try so hard to put JS in new places? It seems to be just an unfortunate historical accident that JS is one of the most popular languages in the world - does anyone actually like it compared to other modern scripting languages? Could we invest in CoffeeScript instead, at the very least?
So much negativity in this thread & on HN in general. Not everyone has hardware experience, and this looks great for newcomers.
Totes. Seems like a lot of that energy would be better spent making an equivalent device that runs . Want it to run coffeescript? go make a product designed around coffeescript. Want it to run Lua? Go make a product designed around Lua. etc. The market has room for diversity. Just because it's not the diversity you prefer, doesn't make it any less valid.
Once you've got to that level you've got a whole family of related microcontrollers that you can move onto from the same principles. With this javascript device you've got no such thing. You're stuck in a dead end if/when it turns out not to have what you need, as you can't progress to "the next level".
Forgive me for not being hip but why try so hard to put JS in new places? It seems to be just an unfortunate historical accident that JS is one of the most popular languages in the world - does anyone actually like it compared to other modern scripting languages? Could we invest in CoffeeScript instead, at the very least?
Earlier quoted context omitted.
It's extremely simple - basically everything is a hash. It has full lambda, not just crippled lambda like Python. It's very fast (I think it is the fastest scripting language except for Lua, and getting faster because of the browser wars). It usually doesn't require a lot of boilerplate code. What is not to like? The one thing I worry about is the limited range of integers.
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…
The prototype system is less powerful .. - No. Just different.
The language will never have continuations.. - Generators help here. We use them with node --harmony
Scoping. - Fat arrows and block scoping coming in ES6.
These features can be used today in node, by enabling the harmony flag. Otherwise wait until next year.
Earlier quoted context omitted.
Very nice analogy (the lingua franca ). The state of CS and the convergence we're seeing toward the web worries me though.
Can I ask why it worries you? Honestly just curious. Is it the performance hits of more levels of abstraction? Or fear of all data being in the "cloud"?
A common rebuttal to that is "it allows people to get into programming more easily". I personally think this is horseshit. There are a multitude of ways to get started with programming, and javascript is in many ways the one that teaches the worst practices and patterns of them all.
Earlier quoted context omitted.
Looks like the JavaScript bindings for Tessel are better. Comparing the demo for blinking an LED: var b = require('bonescript'); var state = 0; b.pinMode("USR3", 'out'); setInterval(function() { state = state ? 0 : 1; b.digitalWrite("USR3", state); }, 100); vs var tessel = require('tessel') tessel.led(1).blink() If they can give human-friendly names to stuff like "USR3" and "P9_40" and "P9_36" out of the box, then I'…
And what happens when you need to specify a pin mode on the Tessel? If you don't have at least tri-state support (which isn't compatible with human-friendly abstractions like "blink"), you're going to burn out a lot of sensors. Most modern microcontrollers have anywhere from 3 to 5 possible pin states, and I don't think it's possible to safely wrap these up in a nice, human-friendly function like "blink". For example…
Where's the blink getting the timer from? What happens if I update the main PLLs? I'll refrain from making assumptions however until I can see their driver libraries. I'm hopeful, but having played around with the 1830 it's not a simple chip.
Earlier quoted context omitted.
Why it's always C/C++ (not even Pascal or Oberon) in another corner of the ring? If hardware is powerful enough to sustain Node.JS, why not use OCaml, Racket or, maybe, some JVM-based language? Or, if the scripting is a requirement, Lua, Tcl or maybe Python.
C/C++ is always in one corner because it's the go-to language (heh) for code that needs to do direct hardware access and manipulation. That said, if I don't strictly have to run C/C++, I'd much rather run Haskell or Python. And you'd be surprised where you can run high-level languages like Python; one project I work on runs Python in the GRUB2 bootloader to test BIOS and hardware, giving Python full ring0 privileges,…
180mhz ARM Cortex-M3 LPC1830
32mb SDRAM
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.