
Why I Believe Scratch Is the Future of Programming - kiyanwang
https://elearningindustry.com/scratch-the-future-programming
======
cocktailpeanuts
The future of programming is programming.

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.

~~~
onion2k
_People who will code will code even if you don 't push them to._

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.

~~~
mrob
I suspect the majority of those coding boot camp customers do not want to
code, but want money, and see coding as an easy way to get it.

~~~
onion2k
You have no evidence for that, and it's a pretty horrible thing to say about
the people who take those courses.

~~~
mrob
What's horrible about that? People doing things for the money is the driving
force behind capitalism, the best economic system yet invented. It improves
everybody's quality of life. I have no objection to people going to coding
boot camps because they think it will help them make money, and I hope they
succeed.

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.

~~~
onion2k
People wanting money is fine. It was the assertion that they "see coding as an
easy way to get it" that's too harsh. In my experience people who have been
through coding bootcamps are very aware that they're learning something hard
and that they'll need to put in a lot of effort, and that they're starting a
new career where they'll be a junior in their first role unless they're very
lucky.

------
mcv
I don't quite agree that there's no syntax, it's just that the syntax is more
visual. You need to put the round things in the round holes and the square
things in the square holes. I remember when I played around with Scratch (only
a little, admittedly) there was still a lot that wasn't immediately obvious.
There's a lot of digging around through the many blocks to find the one you
need, and then puzzling how to use it.

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.)

~~~
smoyer
I've seen Scratch used in several introductory programming classes and while I
don't agree with the author's premise, Scratch just might be the future BASIC.

~~~
mcv
BASIC is a good comparison. It's a great tool to start with, but as soon as
you really want to do something deeper or bigger, you'll want something more
like Python at least.

------
facepalm
Personally, I hope to get away from it as fast as possible. Dragging blocks
around is rather cumbersome and also messy.

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).

------
elcapitan
Why I Believe Annoying Site Visitors With Desktop Notifications Is Not The
Future

~~~
welly
Surely you don't let your browser approve _all_ desktop notifications?

------
Steeeve
I was a little disappointed to see the lack of scratch adoption early on, but
it needed a good deal of polishing.

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)

------
_hao
Unreal Engine's scripting language called Blueprints -
[https://docs.unrealengine.com/latest/INT/Engine/Blueprints/](https://docs.unrealengine.com/latest/INT/Engine/Blueprints/).
It's pretty cool and useful - you can make everything in Blueprints that you
can in C++ in UE (10% slower than pure C++ code).

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.

------
pedrow
My daughter (9 years old) loves Scratch. For her I think the benefit is that
she can do the part of programming that involves analysing a problem and
extracting the logical steps that a computer could process, without all the
fiddly matching up of brackets etc.

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.

~~~
k__
It seems like Scratch is simply programming language tokens "visualized" as
blocks instead of text.

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.

------
leonatan
Just a side note - opening this article on mobile opened no less than two
popups. I really hope this is not the future of web.

------
ldjb
Scratch is a decent tool for learning to code and for prototyping (you can get
something visual and interactive up and running insanely quickly). However, I
wouldn't use it for building anything remotely serious (i.e. something I'm
paid for), and I don't think Scratch was ever intended to be used in that way.

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.

------
brakmic
"Scratch does NOT require syntax" \--> this sentence alone disqualifies the
whole article.

~~~
thinkMOAR
That plus the word 'believe' in the title. If i simply had to accept what
others believe as to be the truth...

~~~
danso
Huh? That's kind of an unfair criticism. The word "believe" is more or less an
explicit expression from the author that the article is, well, his belief. As
a programmer, I like explicit declaration when reading someone else's "code".

The fault is more with you, for automatically associating the phrase "I
believe" with implicit brainwashing.

~~~
thinkMOAR
That is what you are doing yourself now. Dictionary however states something
different,

believe bɪˈliːv/ verb 1\. accept that (something) is true, especially without
proof.

------
ern
With policiticans buying into the "everyone must code" hype, the gap between
what students will be forced to learn in grade school and what they need to
become professional programmers is going to be glaringly obvious.

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.

------
setori88
Not sure if it's valid, but there's an implementation of a flow-based
programming system over at
[https://github.com/fractalide/fractalide](https://github.com/fractalide/fractalide).
Although it's not quite at the boxes and lines stage yet, the components are
reusable and efficient.

------
wav-part
Oh I thought it would be about Scratchpad Memory [1] which is the future :).

[1]
[https://en.wikipedia.org/wiki/Scratchpad_memory](https://en.wikipedia.org/wiki/Scratchpad_memory)

------
andrewclunn
I get that scratch doesn't require that a child can read or type yet, but
really, shouldn't those be fundamentals that they learn first anyways?

~~~
tonyjstark
and also, why need a child so young start with programming? I heard playing
outside is rather healthy and socializing.

Of course if they're interested, why not, as long as it is fun.

------
gibbitz
The future of programming runs on Flash :(

------
TheBobinator
We demo'd a software called filebound earlier this year when looking at a
document management solution and it left a hell of an impression on me.

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!

~~~
tonyedgecombe
In my experience where these products struggle is they are often sold as a
solution where the users can create a system without being programmers.

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.

~~~
TheBobinator
100% agree.

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.

