I think Linux is the right choice, but I also think it would be nice to have a distro that was aimed at encouraging the kind of tinkering the 8 bit home computer empowered.
That means:
- A scripting language within easy reach (compare with BASIC)
- Easy access via simple APIs to 'cool stuff' - sound and graphics. (compare with BASIC's DRAW and SOUND keywords)
- Enough power to break the system
- Easy to return to a stable state (on 8 bit, this would have been a power cycle)
The Raspberry Pi isn't aimed at university students, it's aimed at schoolchildren. So it follows that when they talk about textbooks, they're referring to school textbooks.
If the students need monitors, mice & keyboards at each location, they may as well just carry around a USB thumb stick with a custom LiveOS and put the Pi or other processing core at the work station. That sounds a LOT like my son's middle school.
I think the vision is for the kid to be coding at home. The people running the project will remember Western kids learning to code in front of the family TV, hunched over a home computer on the floor. Having to go to a lab to do this is not as good.
Are we getting confused here between undergraduate textbooks and the kind of textbooks used by, say, 12 year olds?
I'm seeing the RP as something to be used by under-16s to get their introduction to software tinkering -- just as so many of us did with our 8 bit home computers.
When written in the Crockford-approved idiom, I find it awfully verbose: MyClass.prototype.myMethod = function (x,y) {... }
When working in a functional style (and it would be a shame not to) I find bracket management terribly fiddly. It's common to find yourself struggling with ')})});' -- it's worse than LISP, since at least with LISP all the brackets are of the same type!
But mostly, it's a subjective feeling that there's a load of punctuation and fluff on screen that gets in the way of the meaning of the code.
I keep forgetting that parentheses are optional in CoffeeScript function calls; I always feel the code is clearer when I remove them.
streams[i].pipe(streams[i+1])// versus streams[i].pipe streams[i+1]
What's wrong is that jQuery is NOT CoffeeScript. In the computer science world, someone (must) come along to invent a new language to satisfy his own inflated ego. If I take a wild guess, I'd say that behind all the mumble jumbo, putting his name on a language, and eventually publishing a book about it is the real motivation.
You might claim that Ruby is the product of an inflated ego, since it postdates Python. Or that Guido's egotism was what led him to create Python, rather than us all stick with Perl. I would disagree with you -- but at least it wouldn't be a nonsensical claim.
But CoffeeScript is not an attempt to supersede or replace jQuery. CoffeeScript is a compiler that produces Javascript. jQuery is a Javascript library for DOM manipulation and event processing.
CoffeeScript and jQuery happen to complement each other very well.
I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project.
For the second time this week, I find myself arguing that strong static typing is not something that particularly helps you with large projects. If you write something big, you should be modularising it, and type mismatches aren't easy mistakes to make when communicating between modules.
No, strong static typing is most useful when you're writing the small, detailed, bit-twiddling parts of your code.
Fortunately, that kind of work is seldom what you're doing in Javascript.
But the biggest frustration for me with JavaScript is that, as implemented in web browsers, trying to simple test datatypes and null objects is a major exercise in frustration.
Coffeescript: solipsism = true if mind? and not world?
emits the Javascript: if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
solipsism = true; }
(example taken from the CS homepage)
someone really needs to clean up JavaScript itself
I think the JS community is united in recognising the defects JS has. What's recognised is that the install base is there, and if you want to develop for real people with real browsers, you're stuck with it. Crockford has done a great job in recognising the bad parts, recognising the good parts, and carving out a subset of the language that allows you to code in an elegant, efficient manner. The community has developed a number of conventions that work around Javascript's nastiest aspects in a pretty satisfactory way -- for example the export/require module system used by Node.js and elsewhere.
CoffeeScript has the nice property of working within these guidelines.
When you're debugging, you debug Javascript. Then you figure out what part of the CoffeeScript generated that Javascript. This tends to be straightforward.
To be sure, it's a negative. But it's vastly outweighed by the legibility of the CoffeeScript, how much faster it is to write, the code quality it engenders.
Can you expand on that point about variable scoping please?
My perception is that CoffeeScript does the same as Javascript, except that globals are harder to create (good!)
The JS generated by CoffeeScript pushes variable declarations to the top of the function, so it's clear what the scope is. That's a real gotcha for JS newbies.
If you already know Javascript, I reckon it'll take you less than 3 hours to learn CoffeeScript.
The brief documentation at http://jashkenas.github.com/coffee-script/ , is pretty much all you need. On the same page, you can type CoffeeScript in, and see the generated JS. You'll be there in no time.
CoffeeScript isn't really a whole other language. It's Javascript, but with a new and -- arguably -- nicer syntax. There's an awful lot more to a language than syntax. Syntax is one of Javascript's weakest areas.
Why do people choose Javascript? Not, generally, because it's a beautiful language. More because it's the only language natively available for manipulating the DOM in a browser.
Node.js is an interesting rebuttal to that argument. It seems to be very popular, despite there being plenty of alternatives on servers. I sense a few of reasons for this. One is a bunch of web developers have JS skills they honed on the browser, for the reason given above. Another reason is that the callback oriented programming style required by Node.js is familiar to people writing JS for the browser. And finally -- a technical reason -- because you can now write code once, and run it both on the client and the server.
I really like CoffeeScript. It takes an afternoon to learn, it protects you from some of JS's nastiest gotchas (e.g. the weirdness of '=='). It frees you up from the parenthesis hell you get in JS, especially when using anonymous functions as parameters to function calls.
Slashdot Mirror
You are replying to a thread that includes the words "It also has an analogue TV out"
I think Linux is the right choice, but I also think it would be nice to have a distro that was aimed at encouraging the kind of tinkering the 8 bit home computer empowered.
That means:
- A scripting language within easy reach (compare with BASIC)
- Easy access via simple APIs to 'cool stuff' - sound and graphics. (compare with BASIC's DRAW and SOUND keywords)
- Enough power to break the system
- Easy to return to a stable state (on 8 bit, this would have been a power cycle)
As MROD observes, an acorn is a fruit.
At the time we had Apple, Apricot, Acorn all on the market. Then it went quiet until Blackberry came along...
Shut it, n00b. ;)
The Raspberry Pi isn't aimed at university students, it's aimed at schoolchildren. So it follows that when they talk about textbooks, they're referring to school textbooks.
If the students need monitors, mice & keyboards at each location, they may as well just carry around a USB thumb stick with a custom LiveOS and put the Pi or other processing core at the work station. That sounds a LOT like my son's middle school.
I think the vision is for the kid to be coding at home. The people running the project will remember Western kids learning to code in front of the family TV, hunched over a home computer on the floor. Having to go to a lab to do this is not as good.
Are we getting confused here between undergraduate textbooks and the kind of textbooks used by, say, 12 year olds?
I'm seeing the RP as something to be used by under-16s to get their introduction to software tinkering -- just as so many of us did with our 8 bit home computers.
I'm perfectly happy to delegate "real control" to someone I'm paying. However being locked in to a single provider scares me.
Bring on the competition! Anyone should be able to put up a competing service that provides the same APIs.
I note that AppDrop hasn't seen a commit since 2008 - but it shows what can be done.
A Mac Mini isn't a PC?
First time I've heard this mentioned. This really is the successor to the BBC Micro!
Fruit-based name.
Comes in "Model A" and "Model B" versions
It just needs a picture of an owl on it now.
at least for high power mains projects
"The device should run well off 4xAA cells"
Although I agree Arduino probably will use less power. Different design goals.
I did not for one second intend to demean LISP.
In the common usage, "extensive" means "having a large extent".
In agriculture and physics, it can be used as the opposite of "intensive", but it would only be understood among subject expert peers.
Without being too exhaustive...
When written in the Crockford-approved idiom, I find it awfully verbose:
... }
MyClass.prototype.myMethod = function (x,y) {
When working in a functional style (and it would be a shame not to) I find bracket management terribly fiddly. It's common to find yourself struggling with ')})});' -- it's worse than LISP, since at least with LISP all the brackets are of the same type!
But mostly, it's a subjective feeling that there's a load of punctuation and fluff on screen that gets in the way of the meaning of the code.
I keep forgetting that parentheses are optional in CoffeeScript function calls; I always feel the code is clearer when I remove them.
streams[i].pipe(streams[i+1])
streams[i].pipe streams[i+1]
What's wrong is that jQuery is NOT CoffeeScript. In the computer science world, someone (must) come along to invent a new language to satisfy his own inflated ego. If I take a wild guess, I'd say that behind all the mumble jumbo, putting his name on a language, and eventually publishing a book about it is the real motivation.
You might claim that Ruby is the product of an inflated ego, since it postdates Python. Or that Guido's egotism was what led him to create Python, rather than us all stick with Perl. I would disagree with you -- but at least it wouldn't be a nonsensical claim.
But CoffeeScript is not an attempt to supersede or replace jQuery. CoffeeScript is a compiler that produces Javascript. jQuery is a Javascript library for DOM manipulation and event processing.
CoffeeScript and jQuery happen to complement each other very well.
I thought the problem with javascript was it was weakly typed , dynamic and not typesafe so it was very hard to maintain a really large javascript project.
For the second time this week, I find myself arguing that strong static typing is not something that particularly helps you with large projects. If you write something big, you should be modularising it, and type mismatches aren't easy mistakes to make when communicating between modules.
No, strong static typing is most useful when you're writing the small, detailed, bit-twiddling parts of your code.
Fortunately, that kind of work is seldom what you're doing in Javascript.
it's an interesting little language but it's syntax when doing callbacks could be cleaner and it's return policy is not so fun in node.js
Odd. I find it very convenient for callback based programming, especially in Node.js. Lots of Node programmers use CS.
I was experimenting with stream processors with a functional-programming flavour.
wc = new InjectStream 0, (acc, line) ->
acc + line.split(' ').length
emits the JS:
wc = new InjectStream(0, function(acc, line) {
return acc + line.split(' ').length;
});
It tends to be nice and neat, as long as the callback is the final argument -- which is usually the case.
I personally find all those '});' -- and worse -- bracket clusters in JS and Java, distasteful.
But the biggest frustration for me with JavaScript is that, as implemented in web browsers, trying to simple test datatypes and null objects is a major exercise in frustration.
Coffeescript:
solipsism = true if mind? and not world?
emits the Javascript:
if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
solipsism = true;
}
(example taken from the CS homepage)
someone really needs to clean up JavaScript itself
I think the JS community is united in recognising the defects JS has. What's recognised is that the install base is there, and if you want to develop for real people with real browsers, you're stuck with it. Crockford has done a great job in recognising the bad parts, recognising the good parts, and carving out a subset of the language that allows you to code in an elegant, efficient manner. The community has developed a number of conventions that work around Javascript's nastiest aspects in a pretty satisfactory way -- for example the export/require module system used by Node.js and elsewhere.
CoffeeScript has the nice property of working within these guidelines.
In practice, it's not that hard.
When you're debugging, you debug Javascript. Then you figure out what part of the CoffeeScript generated that Javascript. This tends to be straightforward.
To be sure, it's a negative. But it's vastly outweighed by the legibility of the CoffeeScript, how much faster it is to write, the code quality it engenders.
Can you expand on that point about variable scoping please?
My perception is that CoffeeScript does the same as Javascript, except that globals are harder to create (good!)
The JS generated by CoffeeScript pushes variable declarations to the top of the function, so it's clear what the scope is. That's a real gotcha for JS newbies.
If you already know Javascript, I reckon it'll take you less than 3 hours to learn CoffeeScript.
The brief documentation at http://jashkenas.github.com/coffee-script/ , is pretty much all you need. On the same page, you can type CoffeeScript in, and see the generated JS. You'll be there in no time.
Think of CoffeeScript as a Javascript generator. You can generate any JS with it, including JS that calls qooxdoo, or whatever you like.
You can even embed literal Javascript, although I've never needed to do it.
CoffeeScript isn't really a whole other language. It's Javascript, but with a new and -- arguably -- nicer syntax. There's an awful lot more to a language than syntax. Syntax is one of Javascript's weakest areas.
Why do people choose Javascript? Not, generally, because it's a beautiful language. More because it's the only language natively available for manipulating the DOM in a browser.
Node.js is an interesting rebuttal to that argument. It seems to be very popular, despite there being plenty of alternatives on servers. I sense a few of reasons for this. One is a bunch of web developers have JS skills they honed on the browser, for the reason given above. Another reason is that the callback oriented programming style required by Node.js is familiar to people writing JS for the browser. And finally -- a technical reason -- because you can now write code once, and run it both on the client and the server.
I really like CoffeeScript. It takes an afternoon to learn, it protects you from some of JS's nastiest gotchas (e.g. the weirdness of '=='). It frees you up from the parenthesis hell you get in JS, especially when using anonymous functions as parameters to function calls.
Mmm, zombies are so slow! You can just walk around them.
But if there's millions of them, it gets trickier.
Or is there anyone here who manages to use distributed processing on most apps on their desktop?
I very frequently invoke a massive network of distributed computing nodes to perform internet searches for me. I expect you do too.