We need better, approachable routes into programming.
I love Python and in many ways it's an ideal introductory language but it's roots are in the command line and you have to learn a lot of Unix cruft that shouldn't be strictly necessary to get started.
Processing (or maybe Nodebox and it's kin) are the spiritual heirs to Logo but don't help bridge the gap from fun to useful.
HTML+CSS+JS are available on every single machine with nothing but a text editor needed to get started but - oh the cruft you have to imbibe to get anything useful done...
Someone once said that Excel is the dark matter of the software universe. It probably accounts for most running software in the world that any other environment/language and has a lot going for it:
1. it's immediately practical and positioned well to help people solve real problems.
2. The transition from "I'm not coding" to "This is pretty much coding" is gradual and imperceptible
3. It has a very visual environment with lots of immediate feedback
However - it doesn't help you get from the final stage of "amazing feats of wonder that should never have been done in Excel" to "a real program in a sane environment". Many people who construct those amazing feats of wonder don't even realise that what they are doing IS programming.
Many people who construct those amazing feats of wonder don't even realise that what they are doing IS programming.
Maybe that should be the goal?
For thousands of years, scribes were a separate profession. Today everybody can write. When you make post-it note or shopping list, you probably don't think to yourself:
"Hmm, I'm being a scribe here, I wonder what real scribes use to make high-quality notes..."
Using formulas in a spreadsheet is like assembly language programming: explicit memory addressing, jump as the primary control structure, etc. It's all place based. The nice library of subroutines doesn't change how low level the design of a spreadsheet has to be.
Processing _is_ Java. If you learn Processing, the only things holding you back from writing "real" programs in Java are making a main() entrypoint, learning a few new APIs (depending on what you're making) and applying a few more access modifiers than you're used to. I use it regularly to ease beginners into programming with Java and the transition has always been a snap.
Just to put some context on "you have to learn a lot of Unix cruft that shouldn't be strictly necessary to get started" (andybak; my emphasis. I just did an intro course on Python - it's not my first programming and I'm pretty familiar with Linux command lines.
That said after much trial and error I settled on PyCharm - installation can be done using GUI tools (it's in Ubuntu repos) and you don't need to leave the PyCharm interface to run interactive programs.
Then there are things like iPython, IDLE (part of raspbian I believe). The whole course used a purpose-made browser based interpreter so one didn't have to install if you didn't want to.
I actually took the course as I was seeing Python crop up in educational contexts and wanted a jump start on my children.
> However - it doesn't help you get from the final stage of "amazing feats of wonder that should never have been done in Excel" to "a real program in a sane environment". Many people who construct those amazing feats of wonder don't even realise that what they are doing IS programming.
And sometimes if they do realize it's programming, they use that as a reason to pass the buck to a developer. At my first job, I inherited a number of Excel "codebases" in this way.
My first program at all was in HyperCard when I was 8. I don't think I consciously decided I wanted to program, but I certainly haven't stopped programming since then.
I've played with LiveCode and have to admit that it still seems a lot more complex than HC/SC. Maybe I'm biased or nostalgic because HC had a really profound influence on how I develop software. I was ready to give up on programming the Apple Mac (possibly on programming altogether, and I thought that I was a good programmer) when along came HC.
The challenge for LiveCode is that in the intervening years, of course the complexity of the system has gone through the roof. I think HC represented a conscious choice to limit its own feature set in order to make it presentable to novices, which opened it up to criticism from commercial programmers who thought it was a toy.
I honestly don't know how to create a tool that satisfies the pro's without blowing away beginners and hobbyists. Possibly the magic of Python is that the basic package simply doesn't come with any advanced features (they are installed as packages), allowing for an uncluttered learning environment.
Oh, I didn't know that they went open source. That's cool.
They now have online "academies" that can bring people up to speed. It has more features than HC/SC but also the basic stuff from those days still work.
I wonder what would happen if Google started to add some HyperTalk-like scripting to Google Presentations and eventually allowed it into integrate with Sheets?
It wouldn't be an Excel killer, but it could inspire a new round of developers just like HC did (and like it did for me).
HyperCard was a revelation for me. I was a pretty accomplished programmer (so I thought, famous last words) on MS-DOS and stuff of that ilk. Then I went to work at a company that used the Apple Mac.
Some of the engineers had installed a programming language or two, and bought all of the volumes of Inside Macintosh and the typical pattern was to get just past Hello World and give up. The system was so complex and the documentation was so bad that nobody could wrap their head around it.
I'm sure Windows was just as bad, but Windows came with a stodgy but lightweight API called MS-DOS. The majority of small throw-away engineering apps (like cross assemblers) continued to be written for DOS for almost a decade, and only gradually migrated to Windows.
HyperCard obviously broke down the complexity wall of programming a windowed computer environment. I loved HyperCard -- even wrote a cross assembler in it, and a crude but workable printed circuit design program in SuperCard.
Perhaps an additional tribute to HyperCard is that folks really didn't get into Windows programming until something similar came along for Windows -- Visual Basic. The other tool that opened up programming for people was of course Excel.
People keep saying this about HyperCard. Could someone explain why it's so easy to use and accessible? Some magic combination of properties that hasn't really been replicated since?
It may have had something to do with what was available at the time... For myself I had an old Mac plus and it had basic and HyperCard. Creating graphical games was HARD in basic. In HyperCard I could just draw a picture in it, make areas clickable add some script and voila! I made little cheesy Myst-like games.
As it progressed they made it easier to play music on queue and play video. Eventually I moved onto the web but the web was also complicated by JavaScript which I avoided for years.
Hypercard had a really nice programming language with automatic formatting and (eventually) an excellent debugger. The code was both easy to read AND write, and it was pretty easy for a competent programmer to understand clean up dodgy code written by a novice.
The view hierarchy was very simple: card controls, card, background controls, background. And the event hierarchy matched it and added a couple of higher levels.
All variables were strings. (This turned out to be a significant problem when it came to adding features.)
At a time when string manipulation tools in most languages was quite hard, it was insanely easy in HyperCard (e.g. the concept of "split" was intrinsic to the "chunk" system for string manipulation).
The environment itself was incredibly stable, and by default all your work was persistent and everything you did was persistent (making things volatile was extra work). E.g. if you changed the name of a button with code, the name change stayed. By the same token data and code lived together in this persistent world.
It was all based on direct manipulation. Want to create a button? Draw a button. Want to change its script? Command-option click on it OR go into edit mode and double-click on it.
The drawbacks of HyperCard were more interesting, especially since efforts to produce third party replacements usually managed to address "obvious" shortcomings, while losing key bits of magic (e.g. stability).
Years after moving away from HyperCard I did a bit of Toolbook development -- of all the HyperCard clones I tried, it was probably the best (and certainly addressed a lot of HyperCard's shortcomings).
The "card" metaphor added an artificial constraint to programming that helped a lot of people figure out what they wanted to do and get it done quickly.
You weren't handed a command line and told "okay, now make a program out of this and, oh yeah, you'll need a UI". The UI stuff was pretty much baked into the system. Cards were your screens, and elements could be quickly dropped into place.
Things done to cards stayed put when you traveled back and forth through the stack. That's an important nuance. Also, most of the UI elements were already set up to do some simple things and make the stack work, but later they could be scripted into doing more advanced stuff.
WIMP UIs were still a really really new thing in 1986, but HyperCard was the first construction kit that let you play with that system without learning all the underlying toolkit code.
Interestingly, some folks built a Hypercard like environment with Python called PythonCard. The intention was to give easy access to Python programming in the same way that Hypercard gave developers a start. It hasn't been updated in years until someone recently forked it and began work to update it here https://code.google.com/p/gui2py/
If you are a Python coder, it is worth a look, especially if you have kids or do something were you can mentor young people.
25 comments
[ 5.8 ms ] story [ 43.4 ms ] threadI love Python and in many ways it's an ideal introductory language but it's roots are in the command line and you have to learn a lot of Unix cruft that shouldn't be strictly necessary to get started.
Processing (or maybe Nodebox and it's kin) are the spiritual heirs to Logo but don't help bridge the gap from fun to useful.
HTML+CSS+JS are available on every single machine with nothing but a text editor needed to get started but - oh the cruft you have to imbibe to get anything useful done...
Someone once said that Excel is the dark matter of the software universe. It probably accounts for most running software in the world that any other environment/language and has a lot going for it:
1. it's immediately practical and positioned well to help people solve real problems. 2. The transition from "I'm not coding" to "This is pretty much coding" is gradual and imperceptible 3. It has a very visual environment with lots of immediate feedback
However - it doesn't help you get from the final stage of "amazing feats of wonder that should never have been done in Excel" to "a real program in a sane environment". Many people who construct those amazing feats of wonder don't even realise that what they are doing IS programming.
Maybe that should be the goal?
For thousands of years, scribes were a separate profession. Today everybody can write. When you make post-it note or shopping list, you probably don't think to yourself:
"Hmm, I'm being a scribe here, I wonder what real scribes use to make high-quality notes..."
That said after much trial and error I settled on PyCharm - installation can be done using GUI tools (it's in Ubuntu repos) and you don't need to leave the PyCharm interface to run interactive programs.
Then there are things like iPython, IDLE (part of raspbian I believe). The whole course used a purpose-made browser based interpreter so one didn't have to install if you didn't want to.
I actually took the course as I was seeing Python crop up in educational contexts and wanted a jump start on my children.
Python, and a ton more programming languages are available in repls, eg http://repl.it/languages/Python.
And sometimes if they do realize it's programming, they use that as a reason to pass the buck to a developer. At my first job, I inherited a number of Excel "codebases" in this way.
The challenge for LiveCode is that in the intervening years, of course the complexity of the system has gone through the roof. I think HC represented a conscious choice to limit its own feature set in order to make it presentable to novices, which opened it up to criticism from commercial programmers who thought it was a toy.
I honestly don't know how to create a tool that satisfies the pro's without blowing away beginners and hobbyists. Possibly the magic of Python is that the basic package simply doesn't come with any advanced features (they are installed as packages), allowing for an uncluttered learning environment.
Oh, I didn't know that they went open source. That's cool.
* It can build apps for Windows, Mac OS X, Linux, Android and iOS.
* It has a web engine similar to PHP that allows to use HyperCard like language mixed with HTML code.
* LiveCode authoring environment runs on Mac OS X, Windows and Linux. Older versions run on Mac OS Classic as well and can generate powerPC code.
* They are working on HTML5 deployment.
* The language is dual licensed. You can have the GPL community edition for free with source and/or a commercial edition.
* Its one of the best development community out there. They've been doing this for decades and are very friendly.
It wouldn't be an Excel killer, but it could inspire a new round of developers just like HC did (and like it did for me).
Some of the engineers had installed a programming language or two, and bought all of the volumes of Inside Macintosh and the typical pattern was to get just past Hello World and give up. The system was so complex and the documentation was so bad that nobody could wrap their head around it.
I'm sure Windows was just as bad, but Windows came with a stodgy but lightweight API called MS-DOS. The majority of small throw-away engineering apps (like cross assemblers) continued to be written for DOS for almost a decade, and only gradually migrated to Windows.
HyperCard obviously broke down the complexity wall of programming a windowed computer environment. I loved HyperCard -- even wrote a cross assembler in it, and a crude but workable printed circuit design program in SuperCard.
Perhaps an additional tribute to HyperCard is that folks really didn't get into Windows programming until something similar came along for Windows -- Visual Basic. The other tool that opened up programming for people was of course Excel.
As it progressed they made it easier to play music on queue and play video. Eventually I moved onto the web but the web was also complicated by JavaScript which I avoided for years.
The view hierarchy was very simple: card controls, card, background controls, background. And the event hierarchy matched it and added a couple of higher levels.
All variables were strings. (This turned out to be a significant problem when it came to adding features.)
At a time when string manipulation tools in most languages was quite hard, it was insanely easy in HyperCard (e.g. the concept of "split" was intrinsic to the "chunk" system for string manipulation).
The environment itself was incredibly stable, and by default all your work was persistent and everything you did was persistent (making things volatile was extra work). E.g. if you changed the name of a button with code, the name change stayed. By the same token data and code lived together in this persistent world.
It was all based on direct manipulation. Want to create a button? Draw a button. Want to change its script? Command-option click on it OR go into edit mode and double-click on it.
The drawbacks of HyperCard were more interesting, especially since efforts to produce third party replacements usually managed to address "obvious" shortcomings, while losing key bits of magic (e.g. stability).
Years after moving away from HyperCard I did a bit of Toolbook development -- of all the HyperCard clones I tried, it was probably the best (and certainly addressed a lot of HyperCard's shortcomings).
You weren't handed a command line and told "okay, now make a program out of this and, oh yeah, you'll need a UI". The UI stuff was pretty much baked into the system. Cards were your screens, and elements could be quickly dropped into place.
Things done to cards stayed put when you traveled back and forth through the stack. That's an important nuance. Also, most of the UI elements were already set up to do some simple things and make the stack work, but later they could be scripted into doing more advanced stuff.
WIMP UIs were still a really really new thing in 1986, but HyperCard was the first construction kit that let you play with that system without learning all the underlying toolkit code.
If you are a Python coder, it is worth a look, especially if you have kids or do something were you can mentor young people.