Scratch teaches the fundamentals of traditional imperative programming structures like variables, loops and branches, input and output. Because all the constructs are drag-and-drop, it's literally impossible to get a syntax error. That's a big deal for a 5-year-old.
All of those concepts will carry forward to a text-based imperative programming language. Python seems like a good next step to me. For, say, a 7 year old who's got good at Scratch, Python is going to look:
- faster to write and modify -- typing is quicker than finding elements to drag and drop
- easier to get wrong -- since there's new opportunities for syntax errors
- more powerful -- a bright child will probably 'invent' a wish list of missing features in Scratch, such as functions; and will find them in Python.
So you'd expect the child who's taken to Scratch, will be strongly motivated to move to a more powerful 'real' language like Python, seeing the tradeoff of power versus hand-holding as worthwhile.
Sure, but $300 doesn't seem too shabby for a turnkey system, with a full support infrastructure.
That director mode looks cool - have it do pre-programmed camera moves like pans and crane shots. If I was an amateur film-maker I'd be getting one in a flash.
Mm, but a tyre has 15 PSI (1 standard atmosphere) on the outside to counteract the 35 PSI on the inside.
This'll have 15 PSI on the inside, close to zero on the outside.
But I guess (can anyone confirm) that the strain on the skin is proportional to internal pressure minus external pressure, so I take your point that we're not talking massive numbers here.
If you're thinking about the fragility of flexible walls, Wikipedia says:
Bigelow Aerospace anticipates that its inflatable modules will be more durable than rigid modules.[13] This is partially due to the company's use of several layers of vectran, a material twice as strong as kevlar, and also because, in theory, flexible walls should be able to sustain micrometeoroid impacts better than rigid walls. In ground-based testing, micrometeoroids capable of puncturing standard ISS module materials penetrated only about half-way through the Bigelow skin. Operations director Mike Gold commented that Bigelow modules also wouldn't suffer from the same local shattering problems likely with metallic modules. This could provide as much as 24 hours to remedy punctures in comparison to the more serious results of standard ISS skin micrometeoroid damage.
I'm curious about pressure though. In the vacuum of space, if it's inflated to human-habitable pressures, won't the pressure difference between inside and outside put an enormous strain on the fabric?
Java chooses to be pure and consistent - all executable statements reside in a method, in a class, and you don't get implicit class and method declarations. So you must have explicit declarations of these. And I'd say, when you're ready for Java, that this is quite a good thing, because the fact that you're writing a class with a main() method isn't hidden.
I think it's good that Java is consistent; I think it's good that it's explicit - it's not right for all purposes; use a different language when you want to. But given those design choices, it would be wrong for Java to allow a true one-line Hello World.
But, you only have to *write* one line, because all the rest is boilerplate, in a sensible IDE. That is: new class; fill in dialog box, type 'System.out.println "Hello World\n";', run-as-Java-application.
Similarly in C all executable statements reside in a function, so it's immediately clear to the learner that they're writing a main() function.
Now, in something like Groovy, for example, everything is still in a method, in a class, and when you run it it still constructs a new object then calls its main() method, because under the covers, it's still Java. If you write a Groovy one-liner - 'println "Hello World"', it behoves you to know that it's shorthand for declaring a class and putting that code into main().
I wouldn't recommend Java as a first language precisely because it shoehorns you into OO. I wouldn't recommend Groovy as a first language because it's a language that only really makes sense if you already have a grounding in Java.
- Valve write FPS games
- Valve are specifying this hardware
- Therefore Valve will specify hardware suitable for FPSs
- Miracast is too laggy for FPSs
- Therefore Valve won't specify systems using Miracast
It's more or less logically sound. But Gabe Newell's on record as saying that the low-grade SteamBoxes *will* use Miracast or similar. So one of the axioms must be wrong.
My guess is that Valve doesn't agree that Miracast lag is unacceptable.
RPi was my first instinct for this because I already know how to program it. I had an idle look at Android programming, but when getting the tools to talk to a phone over USB (on Windows) didn't work first time, I decided not to spend any more time on it.
I suppose there's a time lapse camera app out there I could use as-is.
Yes, it runs MAME (whyever would it not? It's more powerful than the 486 I first used for MAME).
It'll run the old 8 bit emulations with ease; I guess there might be newer games it'll struggle with.
I wasn't able to find a viable way to make it drive a 15KHz arcade monitor, so you'd have to use a VGA monitor. For me that detracts from the authenticity. There are x-in-1 arcade boards of dubious legality that do a wonderful job of putting vintage arcade games on a real JAMMA cab.
Now make me one that compiles thirty+ files in subdirectories, links into something like GTK libraries, support multiple targets (one static and non-debug, say, and the other dynamic and debug), checks dependencies, compiles only unchanged objects, can be updated simply when a new file is added, etc.
Sure, it can be done. But it's learning another language, not a simple, intuitive tool.
Make is very flexible, so yes, it is like learning another language. But it is not a complicated language, and all of the things you've mentioned are common things to do, which Make will achieve with aplomb. Read the Make documentation, look at an open source project's Makefile for examples, and you'll be fine.
And if GNU Make was so good, CMake and SCons wouldn't exist. Both are, it has to be said, equally bad too.
GNU Make is exactly the tool I'm referring to as horrendous and atrocious. Honestly, tab-stops that break files in the 21st century...
I don't know anything about SCons, but CMake's raison d'etre is portability - that is, you want to build using Make on Unix, and MSVC on Windows, so CMake build Makefiles on Unix, and does whatever VC wants on Windows.
The tab thing is irritating; but get over it.
Nobody has managed to make a build tool that's a no-brainer to use. CMake, autoconf, Make, Ant -- all are complex enough to warrant a whole printed book each. If you wrote one that was as simple as you hope for, it would lack the power developers demand.
Also, a 5MP camera addon is imminent. I'll be sorely tempted to get another Pi for some low budget Kite Aerial Photography. Just set it to take a photo every 10 seconds, and launch it.
It runs Linux. It can do anything Linux can do, as long as you can live with somewhat limited RAM and CPU speed.
I added a USB hard drive to mine, grabbed a SqueezePlug SD card image, and I'm using it as the MP3 server for my Squeezebox audio players. SqueezePlug started as a bundle of Debian + Logitech Media Server built for PogoPlugs, then also various NAS devices. The Raspberry Pi turned out to be such perfect hardware for the purpose, that the developer has dropped support for other devices.
Prior to that, I left my Mac Mini up 24/7 running Logitech Media Server. It would leak memory and leave the OSX desktop unusable. The Pi uses less power, it's easier to admin, and it's silent.
I do feel I should experiment with other uses -- mine has never had a mouse, keyboard or monitor connected. Just a USB hard disk and ethernet.
This thinking is like saying "a full piano is too difficult, so if we give people a little toy piano they'll be able to learn to play".
When I was young I had a little Casio keyboard with auto-accompaniment. It allowed me to experiment with chord progressions using major, minor, major 7th and minor 7th chords, before learning to play those chords manually. It's not a bad thing. 30 years later, I'm able to transcribe chord progressions almost without thinking - something a number of my musical friends find astonishing.
Perhaps I'd have developed that skill without the dumbed down learning tool - but it definitely lowered the barriers to entry.
... one line, excluding the other lines. Where, exactly, does it display "hello, world"?
In the Eclipse console, which is "a special place where the output of your program goes", as far as the beginner needs to be concerned. However, as I said I wouldn't start anyone off with Java, nor with Eclipse (unless someone came up with a radically simplified Eclipse perspective).
How the hell do you start Ruby and Python? Think of it from the high school teacher perspective. Given Macbook, masters degree in education, and a small budget, how do you do that? Those of us who are artifacts of the time before windows understand the DOS prompt and xterms. We're now pretty close to cretaceous.
Even if you've never seen a CLI in your life before, I don't think it's all that challenging to double-click the Terminal icon, then type "python helloworld.py" or "ruby helloworld.rb". Budget, zero.
I think that various efforts by the Raspberry Pi community are creating a Python IDE aimed at children, though.
You're thinking about too large a scale of program. If it's big enough to ask a team (or even a lone programmer) to do, it probably does need a 'real' programmer.
Think more along the lines of typing. In the 1970s, companies had a typing pool. Nowadays almost everybody does their own typing.
I think lots of people would benefit from the ability to write simple scripts -- the kind many/.ers would consider throwaway.
Do what's actually happened here is that you've set a higher bar for your definition of "programming" than TFA's author.
TFA *is* talking about the very basic scripting skills I describe. Every advanced programmer started with that level of simplicity. Even if you never advance beyond that level of simplicity, scripting is useful. At the moment, lots of people who *could* benefit from scripting, do not, because the applications they use are not scriptable, or because the scriptability is not clearly signposted.
Likewise, if someone wrote an article about attracting more people into learning a musical instrument, people getting good enough to take paid jobs gigging at restaurants would not be foremost in their mind.
`Hello World` in Java is one line, excluding stuff that the IDE does for me. While I do hate it when IDEs generate screeds of boilerplate code, I think Java keeps it to a minimum, and I like what Java makes explicit. I wouldn't say it was an ideal beginner's language though.
Hello World is one line in Groovy, Python, Ruby, Perl. Ruby and Python are languages I might recommend to an absolute beginner.
Your argument akin to saying somebody that can carry around a brick and put it somewhere is able to build a house that is comfortable and durable. Not so, rather obviously.
And again, you're not allowing people to be non-experts.
Not everybody can architect a house. Almost everyone can learn enough in a day to build a garden wall.
But TFA isn't about everyone becoming Donald Knuth.
Millions of people derive great satisfaction from mediocre guitar skills (I know people who get a lot of pleasure from their guitars, who can hardly keep rhythm). There's a class of people who could get value from *very* basic programming skills.
Difficult problems are difficult to solve, and require talent, experience and insight. Easy problems are easy to solve, and don't require as much talent, experience or insight.
Example: an artist using Photoshop decides he needs 20 layers in progression of shades. Creating each layer takes 8 mouse clicks, including a fiddly colour dialogue. Or, he could write a for() loop in some scripting language or other, and create the layers in a few seconds -- and add the tiny script to their arsenal for reuse.
Slashdot Mirror
Scratch teaches the fundamentals of traditional imperative programming structures like variables, loops and branches, input and output. Because all the constructs are drag-and-drop, it's literally impossible to get a syntax error. That's a big deal for a 5-year-old.
All of those concepts will carry forward to a text-based imperative programming language. Python seems like a good next step to me. For, say, a 7 year old who's got good at Scratch, Python is going to look:
- faster to write and modify -- typing is quicker than finding elements to drag and drop
- easier to get wrong -- since there's new opportunities for syntax errors
- more powerful -- a bright child will probably 'invent' a wish list of missing features in Scratch, such as functions; and will find them in Python.
So you'd expect the child who's taken to Scratch, will be strongly motivated to move to a more powerful 'real' language like Python, seeing the tradeoff of power versus hand-holding as worthwhile.
Sure, but $300 doesn't seem too shabby for a turnkey system, with a full support infrastructure.
That director mode looks cool - have it do pre-programmed camera moves like pans and crane shots. If I was an amateur film-maker I'd be getting one in a flash.
Did not know that, but it makes sense now that you point it out - how would a tyre pressure gauge measure absolute pressure?
Thanks.
Mm, but a tyre has 15 PSI (1 standard atmosphere) on the outside to counteract the 35 PSI on the inside.
This'll have 15 PSI on the inside, close to zero on the outside.
But I guess (can anyone confirm) that the strain on the skin is proportional to internal pressure minus external pressure, so I take your point that we're not talking massive numbers here.
Er, high to low pressure.
Absolutely. Anyone who's done a CESA while learning to dive, knows you can basically exhale forever as you go from low to high pressure.
If you're thinking about the fragility of flexible walls, Wikipedia says:
Bigelow Aerospace anticipates that its inflatable modules will be more durable than rigid modules.[13] This is partially due to the company's use of several layers of vectran, a material twice as strong as kevlar, and also because, in theory, flexible walls should be able to sustain micrometeoroid impacts better than rigid walls. In ground-based testing, micrometeoroids capable of puncturing standard ISS module materials penetrated only about half-way through the Bigelow skin. Operations director Mike Gold commented that Bigelow modules also wouldn't suffer from the same local shattering problems likely with metallic modules. This could provide as much as 24 hours to remedy punctures in comparison to the more serious results of standard ISS skin micrometeoroid damage.
I'm curious about pressure though. In the vacuum of space, if it's inflated to human-habitable pressures, won't the pressure difference between inside and outside put an enormous strain on the fabric?
I'm not sure what core point we're debating here.
Java chooses to be pure and consistent - all executable statements reside in a method, in a class, and you don't get implicit class and method declarations. So you must have explicit declarations of these. And I'd say, when you're ready for Java, that this is quite a good thing, because the fact that you're writing a class with a main() method isn't hidden.
I think it's good that Java is consistent; I think it's good that it's explicit - it's not right for all purposes; use a different language when you want to. But given those design choices, it would be wrong for Java to allow a true one-line Hello World.
But, you only have to *write* one line, because all the rest is boilerplate, in a sensible IDE. That is: new class; fill in dialog box, type 'System.out.println "Hello World\n";', run-as-Java-application.
Similarly in C all executable statements reside in a function, so it's immediately clear to the learner that they're writing a main() function.
Now, in something like Groovy, for example, everything is still in a method, in a class, and when you run it it still constructs a new object then calls its main() method, because under the covers, it's still Java. If you write a Groovy one-liner - 'println "Hello World"', it behoves you to know that it's shorthand for declaring a class and putting that code into main().
I wouldn't recommend Java as a first language precisely because it shoehorns you into OO. I wouldn't recommend Groovy as a first language because it's a language that only really makes sense if you already have a grounding in Java.
Ack, be explicit.
I think what you're saying is:
- Valve write FPS games
- Valve are specifying this hardware
- Therefore Valve will specify hardware suitable for FPSs
- Miracast is too laggy for FPSs
- Therefore Valve won't specify systems using Miracast
It's more or less logically sound. But Gabe Newell's on record as saying that the low-grade SteamBoxes *will* use Miracast or similar. So one of the axioms must be wrong.
My guess is that Valve doesn't agree that Miracast lag is unacceptable.
That's a pretty good idea.
RPi was my first instinct for this because I already know how to program it. I had an idle look at Android programming, but when getting the tools to talk to a phone over USB (on Windows) didn't work first time, I decided not to spend any more time on it.
I suppose there's a time lapse camera app out there I could use as-is.
Yes, it runs MAME (whyever would it not? It's more powerful than the 486 I first used for MAME).
It'll run the old 8 bit emulations with ease; I guess there might be newer games it'll struggle with.
I wasn't able to find a viable way to make it drive a 15KHz arcade monitor, so you'd have to use a VGA monitor. For me that detracts from the authenticity. There are x-in-1 arcade boards of dubious legality that do a wonderful job of putting vintage arcade games on a real JAMMA cab.
It *is* the minimum, unless the language takes the step of making class and method declarations implicit.
Now make me one that compiles thirty+ files in subdirectories, links into something like GTK libraries, support multiple targets (one static and non-debug, say, and the other dynamic and debug), checks dependencies, compiles only unchanged objects, can be updated simply when a new file is added, etc.
Sure, it can be done. But it's learning another language, not a simple, intuitive tool.
Make is very flexible, so yes, it is like learning another language. But it is not a complicated language, and all of the things you've mentioned are common things to do, which Make will achieve with aplomb. Read the Make documentation, look at an open source project's Makefile for examples, and you'll be fine.
And if GNU Make was so good, CMake and SCons wouldn't exist. Both are, it has to be said, equally bad too.
GNU Make is exactly the tool I'm referring to as horrendous and atrocious. Honestly, tab-stops that break files in the 21st century...
I don't know anything about SCons, but CMake's raison d'etre is portability - that is, you want to build using Make on Unix, and MSVC on Windows, so CMake build Makefiles on Unix, and does whatever VC wants on Windows.
The tab thing is irritating; but get over it.
Nobody has managed to make a build tool that's a no-brainer to use. CMake, autoconf, Make, Ant -- all are complex enough to warrant a whole printed book each. If you wrote one that was as simple as you hope for, it would lack the power developers demand.
You're not alone. I program for a living. I could not wrap my head around AppleScript.
Also, a 5MP camera addon is imminent. I'll be sorely tempted to get another Pi for some low budget Kite Aerial Photography. Just set it to take a photo every 10 seconds, and launch it.
It runs Linux. It can do anything Linux can do, as long as you can live with somewhat limited RAM and CPU speed.
I added a USB hard drive to mine, grabbed a SqueezePlug SD card image, and I'm using it as the MP3 server for my Squeezebox audio players. SqueezePlug started as a bundle of Debian + Logitech Media Server built for PogoPlugs, then also various NAS devices. The Raspberry Pi turned out to be such perfect hardware for the purpose, that the developer has dropped support for other devices.
Prior to that, I left my Mac Mini up 24/7 running Logitech Media Server. It would leak memory and leave the OSX desktop unusable. The Pi uses less power, it's easier to admin, and it's silent.
I do feel I should experiment with other uses -- mine has never had a mouse, keyboard or monitor connected. Just a USB hard disk and ethernet.
This thinking is like saying "a full piano is too difficult, so if we give people a little toy piano they'll be able to learn to play".
When I was young I had a little Casio keyboard with auto-accompaniment. It allowed me to experiment with chord progressions using major, minor, major 7th and minor 7th chords, before learning to play those chords manually. It's not a bad thing. 30 years later, I'm able to transcribe chord progressions almost without thinking - something a number of my musical friends find astonishing.
Perhaps I'd have developed that skill without the dumbed down learning tool - but it definitely lowered the barriers to entry.
... or, http://www.learnpython.org/
Type 'print "Hello World" ' into a textbox in a browser window, and click "run".
Yes, but they do have to be taught. Bricklaying is not an inate skill, and neither is computer programming..
... and whoever said either of them are?
TFA is about reducing the barriers to learning, and creating motivators for learning.
... one line, excluding the other lines. Where, exactly, does it display "hello, world"?
In the Eclipse console, which is "a special place where the output of your program goes", as far as the beginner needs to be concerned. However, as I said I wouldn't start anyone off with Java, nor with Eclipse (unless someone came up with a radically simplified Eclipse perspective).
How the hell do you start Ruby and Python? Think of it from the high school teacher perspective. Given Macbook, masters degree in education, and a small budget, how do you do that? Those of us who are artifacts of the time before windows understand the DOS prompt and xterms. We're now pretty close to cretaceous.
Even if you've never seen a CLI in your life before, I don't think it's all that challenging to double-click the Terminal icon, then type "python helloworld.py" or "ruby helloworld.rb". Budget, zero.
I think that various efforts by the Raspberry Pi community are creating a Python IDE aimed at children, though.
You're thinking about too large a scale of program. If it's big enough to ask a team (or even a lone programmer) to do, it probably does need a 'real' programmer.
Think more along the lines of typing. In the 1970s, companies had a typing pool. Nowadays almost everybody does their own typing.
I think lots of people would benefit from the ability to write simple scripts -- the kind many /.ers would consider throwaway.
Do what's actually happened here is that you've set a higher bar for your definition of "programming" than TFA's author.
TFA *is* talking about the very basic scripting skills I describe. Every advanced programmer started with that level of simplicity. Even if you never advance beyond that level of simplicity, scripting is useful. At the moment, lots of people who *could* benefit from scripting, do not, because the applications they use are not scriptable, or because the scriptability is not clearly signposted.
Likewise, if someone wrote an article about attracting more people into learning a musical instrument, people getting good enough to take paid jobs gigging at restaurants would not be foremost in their mind.
`Hello World` in Java is one line, excluding stuff that the IDE does for me. While I do hate it when IDEs generate screeds of boilerplate code, I think Java keeps it to a minimum, and I like what Java makes explicit. I wouldn't say it was an ideal beginner's language though.
Hello World is one line in Groovy, Python, Ruby, Perl. Ruby and Python are languages I might recommend to an absolute beginner.
Your argument akin to saying somebody that can carry around a brick and put it somewhere is able to build a house that is comfortable and durable. Not so, rather obviously.
And again, you're not allowing people to be non-experts.
Not everybody can architect a house. Almost everyone can learn enough in a day to build a garden wall.
But TFA isn't about everyone becoming Donald Knuth.
Millions of people derive great satisfaction from mediocre guitar skills (I know people who get a lot of pleasure from their guitars, who can hardly keep rhythm). There's a class of people who could get value from *very* basic programming skills.
Difficult problems are difficult to solve, and require talent, experience and insight.
Easy problems are easy to solve, and don't require as much talent, experience or insight.
Example: an artist using Photoshop decides he needs 20 layers in progression of shades. Creating each layer takes 8 mouse clicks, including a fiddly colour dialogue. Or, he could write a for() loop in some scripting language or other, and create the layers in a few seconds -- and add the tiny script to their arsenal for reuse.