Why I Believe Scratch Is the Future of Programming
elearningindustry.com
elearningindustry.com
What's described in the article is indeed true, you can build stuff without syntax, you can extend it, etc.
But who is this for? I am not a fan of the "Let's teach everyone to code" rhetoric, because this is same as "let's teach everyone to play the piano", or "Let's teach everyone to be good at math!". People who will code will code even if you don't push them to. And most others, well they have other better things to do in their lives like making art, becoming a scientist, or becoming a doctor.
With this type of "programming", I think their trouble is they don't know who they're building this for. Here's what actually happens:
1. People who want to do serious programming will immediately find out how inefficient this method is compared to "writing syntax", and switch to real programming.
2. People who are hobbyists will find that it's not so hard to learn "real programming" once they get into programming.
3. People who want to learn to program to get a job, will of course learn real programming
4. People who want to build things but can't learn programming languages will maybe use this to write a prototype, but then immediately hire a "real programmer" once they see any sign of taking off.
5. The "education" purpose is also out of touch too. If I wanted to teach my kid how to program I would teach him python. It's not that hard.
6. Most other people won't and shouldn't care about coding. There are thousands of other interesting things to do in life.
I am all for making it easier to build things, and I appreciate that they built this so the world can experience what it feels like to try something like this, but I really can't see any possible use case for this.
That's why I said if I was teaching my kid to code I would teach python. It's easier to learn, copy and paste (for instant gratification), and it is an actual programming language. I really can't see where this Scratch thing has any benefit over these other languages.
When I tried teaching him Python however, his spelling and typing skills held him back significantly. It took him almost a minute to type 5 words.
Unfortunately, this is becoming more common, as more kids are growing up without using a computer much at all, in favor of tablets and smartphones.
No. Simply no.
Source: Taught First/Second/Third graders scratch once a week for 2 full years. The no syntax (no writing) part is extremely important. I've seen first graders completely crate a game from scratch (no pun) that I and other adults actually enjoyed playing as an honest to goodness challenging game. There's absolutely no comparison with "grown up" programming languages... even BASIC (that I myself programmed as a kid but that was only in middle school and later).
The blocks are much easier to understand--they constrain what you can create and that avoids syntax errors and many other problems. Also, the visual element is certainly good and makes it fun.
You can take a look at http://pencilcode.org.
By "made-up" language, what are you suggesting?
Using a main stream language would make re-use and integration easier as well as making it easier for users to move both from Scratch to more conventional methods and from them to Scratch.
Also I'm not a big fan of the just learning to code approach. software development is more than just hammering on the keyboard. It is about thinking about the right data structures, or data generally, it is about architecture.
Finally, if you have internet you have access to so much material to learn coding, why should you start with Scratch if there are thousands of free courses, books, tutorials for every other language. Think about learning Swift on the iPad, C# in the browser, ...
I strongly recommend reading Dweck's work on mindsets to dissuade you of the belief that aptitude for things like Mathematics is a fixed trait rather than something that can be changed.
I think it's also helpful to recognise that the group that are exposed to programming under the right conditions to start of their own accord are a subset (I would posit a small subset) of the people who would be an asset to the industry.
I'm sorry, I'm having hard time finding where I said that. Please do point me to an excerpt.
Cool. This (below) was the bit I must have misunderstood. It read as if you were saying that coders naturally find coding, and that people who don't naturally find coding are better off not coding.
"People who will code will code even if you don't push them to. And most others, well they have other better things to do in their lives like making art, becoming a scientist, or becoming a doctor."
The booming industry of coding boot camps shows that there are a large number of people who want to code but didn't have the opportunity or knowledge to learn until they were old enough and wealthy enough to pay for private tuition. I would argue that is strong evidence that your assertion is wrong - it's a reasonable assumption there are a number of people who are capable of coding and who want to code but can't afford private lessons and therefore won't ever become a coder.
Lowering the barrier to starting, to the point where it's as simple as running an app without any cost (beyond access to a computer), is a very good thing that greatly benefits a huge number of people.
But I don't think coding boot camps are evidence for great love for coding for its own sake. People who really want to code will find some way to do it no matter what. They don't need paid tuition.
Having talked with over 200 of them, I'd suggest that just like people in most career training programs, there's something about the job (as they imagine it) that attracts them relative to other jobs. "Huh, that looks like a good job, and I suspect I can do it, maybe I should invest some time and money into finding out!"
I don't think anyone thinks it's a get-rich-quick plan; no one expects it to be easy. And if they do think that, they revise their estimates on the first day of bootcamp. But many of them DO suspect that as a career, coding pays well relative to the amount of work it is, and has good growth prospects. I too believe that, so I'm sympathetic to their perspective, although I doubt it's the BEST career in those aspects (I hear trades are really quite lucrative). The degree of "passion" for various particular aspects of the career is variable (e.g. desire to do the act of coding, e.g. desire to produce software, e.g. desire to work in startups, e.g. desire to make mad bank, e.g. desire to have flexible working conditions, e.g. desire to get paid to do math). Few of them have had wildly successful careers in other domains (I believe that between 1% and 3% of my sample were already making six figures in another career), so the majority are hoping that this will be their successful career.
In summary, it is true that all of them expect that learning to code might be somewhat economically productive, but your phrasing is condescending and nasty. Don't be nasty.
Disclaimer: I have a vested interest in bootcamps being at least somewhat successful.
But sure, some of the people jumping on the train then and now are lifers.
It's the certificate and contacts they're after (and pay dearly for).
The opportunity of access to extensive mentorship and a solid curriculum. Those things make a good boot camp a more efficient way to learn than doing it entirely on your own, not least because you don't have to discover all the blind alleys and mistakes for yourself. (Like I did! But I started at age six. An adult looking to learn a trade skill has not the luxury of a whole lifetime to spend doing so.)
If you were unfortunate enough to attend a school that didn't have any sort of computing classes, after school groups, etc, or you lived somewhere rural that didn't have those programmes outside of school then you would have had no access to a mentor who can guide you.
If they have 3 months to go to a camp, surely they could as well learn at home for those 3 months.
In order to learn on your own you need some knowledge to start with. If you sit down in front of a computer with zero knowledge of a subject then you don't even know what to put in to Google, and if you start with a search like "how to code" you have no way to assess whether the websites you find are actually useful or a waste of time.
Languages like Scratch can teach someone to code when they have no external input. They might teach "bad" ideas, but those can be unlearned and replaced with better concepts later. Most of us learned by starting with something like BASIC and have gone on to learn better techniques. There's no reason why someone learning today has to start with a "good" language like Python.
Heck, I started with Visual Basic 6. That's was far worse than Scratch as far as teaching bad practices go.
I grew up in a small Greek village at a time when very few people knew what a computer was. My first exposure to programming was finding a CD with all sorts of things in it, including Visual Basic 4. I had no internet, so literally the only thing I had to go on was the VB language reference (the reference, as in, this function does that), and a two-page tutorial on making a temperature converter.
I taught myself programming using just that reference and tutorial, and nothing else. I don't believe courses are necessary if you want to learn programming.
You're wrong. There are lots of developers who are self-taught, and just like you they didn't need a course. That's awesome. Similarly though there are lots of other developers who aren't self-taught, and for whom the process of how to think about code didn't "click" with them until they were taught the basics. Those developers needed a course.
People aren't all the same, so what works for one person won't necessarily work for another, and given the number of developers society will need in the future we will have to afford opportunities to every type of learner.
It really is 1999 all over again. :-( :-)
I would be very surprised if you honestly can't conceive of people who would struggle immensely to teach themselves the way you did. Or even if they could succeed in doing so, that it might take too long or be too financially risky.
I personally know plenty of people like that. Some of them are very intelligent as well.
Agree with your general sentiment, but this kind of made me smile. I'm teaching a general programming class next quarter and I plan to say the opposite of this, that the students don't have anything better to do in their lives than to learn programming -- at least for the 10 weeks that they've signed up for.
I actually do believe that, but only in the way that I feel it would be shortsighted to tell an aspiring doctor, "don't mind the literacy thing, just be a good doctor!"
It's not just about learning to program. Building systems with these blocks trains problem solving and abstract thinking skills, which are also helpful in many areas outside of software development or mathematics. That's part of the reason why schools and universities have students lern mathematics even if they're not going to use those exact mechanics later in their profession.
And such a gamification helps catching their interest where raw code might just scare them away.
Also, while being able to create your own blocks is important, you still need to create the blocks before you can use them. There's no top-down approach to programming; you need to build your blocks first.
I gave a small programming course at my son's school last year using Blockly (similar to scratch, but simpler and more guided) for 6 and 7 year olds, and that worked fine, but I still intend to teach my son a real programming language soon. (Ruby or Python, probably.)
My son can not really read yet, so for that stage scratch (or rather, Snap, which works without Flash) is fine. But for more complex things I imagine it will get inconvenient quickly.
What is nice is to have a display of the available commands. I actually learned programming on a ZX Spectrum, which had all the available Basic commands available on the keyboard (reachable with different key combinations). For learning that was great, as it also sparked my curiosity ("what does command x do?").
So maybe that could be emulated somehow - blocks are just one way to show the available commands.
Apart from that, I also find the Scratch environment not very intuitive to use. It's very confusing to me that there are no start, stop and pause buttons. But granted, that is one thing that can be overcome with experience (I googled that basically you have to reset state programmatically at the start of your program).
It's not being used by any schools that I have checked out, but the ideas that I first saw with scratch are widely used across all kinds of early education technology.
I wouldn't say that anything like this is the future. RAD tools are fantastic, but they have their place. There's nothing that beats the performance and control of a low level language and they've all gotten better over the years with tooling (save assembly - which from my perspective has remained relatively stagnant).
Still - the ability for non-programmers to get reasonably complex work done given a set of fundamental skills isn't just an inevitability, it's a necessary component for the next era. When the techies aren't bogged down with keeping tracking systems of all sorts up and running, they can focus on innovation that just isn't happening at the same pace that it once was.
Kudos to the Scratch team for seeing the problem that's been glaring at us all since Logo disappeared and made a valiant effort at addressing it effectively. (I know... Logo didn't exactly disappear, but it has faded significantly)
However there are some problems. If you have too many nodes in a script it's very hard to navigate and understand what's going on. So I'd say that there's place for both, because it's easier for quick prototyping, but I don't think it'll ever replace programming to that extent. It's just another tool for the toolbox.
The original Scratch was written in Smalltalk and it was possible (once you were ready!) to access the underlying Objects and do 'real programming' The current Scratch2 is Flash (I think) and that's no longer possible. I think that's a shame.
I think this is a good start. I mean you learn programming while doing it and don't have to remember everything. Should be easy to map this to other programming languages.
I mean, many of us programmers started with copying code around.
I did my first mIRC chat bot that got news via sockets by copying the socket code from another script. I didn't even know what arrays were back then.
That said, I think there is huge potential for visual programming environments in general, particularly in education. At my university, a custom Scratch-like environment is used in the introductory programming module, and it helps students to learn the fundamental programming constructs (sequencing, selection and iteration) without worrying about syntax or compilation. I think it's important that those first learning to code are able to experiment and easily get things running, and that is something visual programming environments are good at enabling.
Here an interesting quote from Alan Kay:
"The best teacher I had in graduate school spent the whole semester destroying any beliefs we had about computing. He was a real iconoclast. He happened to be a genius, so we took it. At the end of the course, we were free because we didn’t believe in anything. We had to learn everything, but then he destroyed it. He wanted us to understand what had been done, but he didn’t want us to believe in it."
The fault is more with you, for automatically associating the phrase "I believe" with implicit brainwashing.
believe bɪˈliːv/ verb 1. accept that (something) is true, especially without proof.
Attempts to introduce today's complex real-world programming paradigms into school will fail, so the obvious next step will be for real-world programming environments to become more like the ones used for teaching. The challenge will be to ensure that these programming tools of the future are well-engineeered so that the code they produce is maintainable.
Of course if they're interested, why not, as long as it is fun.
Most business systems are built off of the concept of the "enterprise infrastructure" being the printing press for the front end infrastructure, and the back office being the back end infrastructure. When the Xerox printer was first introduced, you had a "rapid prototyping" system for business processes inwhich the xerox machine represented the front end and back office being the back end.
The "Next Gen" of business systems and processes was computerization and mobilization. We had mainframes and then the litany of "enterprise" architectures such as .net\SQL, Java\Oracle, LAMP, or SAP, and "rapid prototyping" architectures such as Paradox, MS Access, and so forth. That produced an alphabet soup of system types, jargon, TLA's, and business processes and lots of profound thought into designing businesses.
These "program a flowchart" languages we've seen, which are largely driven by certain MS SQL server features, are really great at building business processes because all of these systems have always had menu's, forms, data, and reports as the building blocks of the business process. By flow charting the business process as part of the programming, you end up with better visibility by management into the flow of the business system. The revolutionary item with filebound is backing up the flowchart with the data (so we know how things used to be done), being able to show changes to the flowchart and make notes (are we repeating the same mistakes?), being able to separate structured and unstructured data (hint: your "enterprise class" business system should be rigid and scalable, and should is your data structure), supports modularity (filebound in particular supports vb and powershell scripts as blocks in the chart), all while proving a certain degree of access to management to build and play with things like the original xerox machine did. Filebound also has some really nice automation capibilities; e.g. you can sit one end-user with minimal education and have them configure the system to structure data out of e-mail, e-mail attachments, or scans, and you can report on their accuracy and any errors that occur as examples, all using some pretty advanced OCR. Building forms is click and drag as well. Best part is, if management needs to really understand the system, print out the flowchart on 11x17 and hand it to them. Even the oldest coot will "get it".
Not that I'm plugging their software in particular, but when I saw a few short demo's, it left a real impression as to the future of business system programming. Imagine taking several flowcharts and exporting them as a business process; management would become very familiar with the data structure and system structure and where it's deficits and benefits are, and that is a good thing because you are forcing them to understand the structure of their business.
There's always going to be a place enterprise class business systems because scalability and rigidity are features. When the auditors show up, they know what great plains database tables to go look at. That's a benefit to them. When you have all sorts of things modified, they begin asking lots of rough questions.
"Real programming" is going to live everywhere else there aren't business systems and there's a lot of places where it'll fit in. You are not going to be able to build cad to cam software using a flowchart. No freggin' way. Try doing nested tree's. HA!
The reality is although they can make life easier they don't take away the need to be able to decompose a requirement into its relevant parts. You still need to think like a programmer to use them well.
Managers are a reactive occupation, business analysts are a proactive occupation. Where they meet and compromise is on the business system. Good business analysts understand the market play and plan the reactions of the managers.
Advertising and Sales often targets victim's "reptilian brains", finding methods to control conversations and execute methods of exploit that force an endorphin dump. I've found it quite useful to criticize managers in very cruel ways, e.g. "That Sales guy gave us nothing solid; lots of power words, metered speech, and other sales tricks, and a whole lot of managers around a table endorphin-dumping themselves over it. What an incredible circus." From there you can carefully deconstruct sentences and show management their understanding of what they are getting into is very abstract and fluid.