They've never even read manuals. Different mindset from ours. You could do big apps in Blockly, but it seems like a heck of a push. Nothing beats good old 7-bit ASCII. What Blockly does is make SYNTAX disappear. No need to remember anything.
Manuals aren't getting read on a wide scale. I'm involved in a 3D printing related startup. People just will not do this. So, I'm making videos. People like videos a lot. I'm finding they do not require much in the way of production values either, which is nice. I use my phone most of the time. Some light editing, insert media assets, such as images, and it's fine.
Solution: Put the text in the video
As for the mindset, I'm hoping some of that gets A/B tested. There are some of the peeps slogging along in blockly. The few who grok the text wiz by, and the educator can make it clear those kids are the ones who will make the Blockly program for the rest to use.
I used to be old school command line, but these days I prefer IDEs. So, I still type out all my code. I can't stand blockly for doing anything for myself, but I totally support it for introductory education for young kids.
As for spin features, I don't see advanced features and ease of use as mutually exclusive. It's just a matter of making sure we implement them properly.
IMHO, text is never, ever gonna die. I do suspect "syntax" will translate in to "behaviors", animated bits that "want" to do things when in proximity to other things. Programmer could drop one in, see it's behavior, then nudge it toward their specific intent. You can see a little of this in games, and or gesture based interfaces today. People move their cursor, or touch, and are presented with dynamic, on the fly, options.
But doing that is going to require we get one heck of a lot better at live evaluation of code and or video game level interface resources. Meanwhile, text is fine over 9600 baud and vi, if one wants to.
I used to be old school command line, but these days I prefer IDEs.
Me too. They offer a lot of features. I don't write super big things very often. For me, Sublime and a build script is just fine. Or, something like PropTool is fine too. I'm pretty flexible there. It's all good.
My favorite about PTool is live build and test, then save. It's far more intuitive than, save, build. Could just be me. Autocomplete is addictive.
Augmenting text is a good thing. I would argue most people who come up on an IDE can grok a command line, especially if they get multi-windows or screens to work with, easily enough. They may not like it, and that's OK fine too. They can do it. (Important, IMHO)
These days, I don't *need* those skills too often. Our stuff is mostly working. But, there are times still. And it's super nice to not worry so much. Do a quick syntax review, because forgetting happens, then go.
Heater,
You complain about C++ slow compile linkage times, but this is only an issue if you go #include crazy (and it's because of file system overhead more than anything). I can compile the OpenSpin.exe in about 2 seconds total, 1.5 for compiling and 0.5 for linking. It;s not a huge project, but seems like a pretty reasonable amount of time to compile for what it is. Also, that's a release/optimized build.
I used to be old school command line, but these days I prefer IDEs.
Me too. They offer a lot of features. I don't write super big things very often. For me, Sublime and a build script is just fine. Or, something like PropTool is fine too. I'm pretty flexible there. It's all good.
My favorite about PTool is live build and test, then save. It's far more intuitive than, save, build. Could just be me. Autocomplete is addictive.
Augmenting text is a good thing. I would argue most people who come up on an IDE can grok a command line, especially if they get multi-windows or screens to work with, easily enough. They may not like it, and that's OK fine too. They can do it. (Important, IMHO)
These days, I don't *need* those skills too often. Our stuff is mostly working. But, there are times still. And it's super nice to not worry so much. Do a quick syntax review, because forgetting happens, then go.
I use Sublime as well and also BBEdit on the Mac. I certainly use IDEs some of the time. I use Xcode on the Mac occasionally and various IDEs under Windows. They are certainly handy. But I don't have any issue with using a command line and the vi editor if the need arises.
I hear kids nowadays think textual programming is "old school"....
No doubt.
But isn't that the tail wagging the dog?
When I was 5 years old I kicked and screamed like hell the day I found I had to go to school. I might have said I was quite happy with my picture books. But no, they wanted me to read and write, do sums and learn multiplication tables. Good grief what a pain. It's like being sent to prison, with hard labor, for 10 years.
Programming is basically mathematics. Manipulation of symbols. All be it with the help of a machine.
Is it really possible to do mathematics purely pictorially?
Do those people creating the graphical programming tools actually use those tools to do it?
I hear kids nowadays think textual programming is "old school"....
No doubt.
But isn't that the tail wagging the dog?
When I was 5 years old I kicked and screamed like hell the day I found I had to go to school. I might have said I was quite happy with my picture books. But no, they wanted me to read and write, do sums and learn multiplication tables. Good grief what a pain. It's like being sent to prison, with hard labor, for 10 years.
Programming is basically mathematics. Manipulation of symbols. All be it with the help of a machine.
Is it really possible to do mathematics purely pictorially?
Do those people creating the graphical programming tools actually use those tools to do it?
I wonder if academics are devolving into entertainment. Everyone going to college. Many can't write a sentence. Fewer people needed every day to produce for the rest.
I'm kind of interested in using graphical representation to show code sitting and running, even though the code is textual. We spend a lot of time writing code, and it would be neat to be able to see it from different perspectives, in function, memory usage, and time profile, for example. It could prevent a lot of frustration as limits were approached.
I used to be old school command line, but these days I prefer IDEs.
Wait a minute. Can we make a distinction between command line and editors and IDE's and graphical programming?
Nobody much has done command line programming since the 1970's when we typed BASIC into teletypes. Editing lines in our source by entering the same line number again followed by the new text.
Actual editors that allow one to see and move around many lines in a file came later. With the green screen CRT monitors. Still with us with vim or notepad or your editor of choice.
IDEs come with Borland, and Visual Basic etc. Basically an editor that understands your source, can offer hints and tips, highlight syntax errors, build the program on a click etc.
So far we are still dealing with programming as an exercise in writing text.
Tools like Blockly are a whole different idea. One never has to enter any text. Except perhaps for filling in text dialogues some times.
I wonder if academics are devolving into entertainment. Everyone going to college.
Oh Chip, don't start me on that.
Back in the day nobody got an education unless they were rich. There were few universities, like Oxford and Cambridge. Yeah, I can only talk about England but I get the feeling the same applies to the USA.
By the 1960's came the idea that everyone should have an opportunity, no matter where you came from or how much money your parents had. So the 10% or so of smart kids had a chance to get to uni. They would be subsidized with grants to make that possible.
Today everyone is expected to go to college and get a degree. Not only that they have to borrow money to do so. A great industry for banks loaning money and the many new universities serving up crappy degree courses.
The end result of all this is that as a graduate they will check what university you come from. Oxford, Cambridge, and a few other old and respected institutions. No? Sorry.
I'm kind of interested in using graphical representation to show code sitting and running, even though the code is textual. We spend a lot of time writing code, and it would be neat to be able to see it from different perspectives, in function, memory usage, and time profile, for example. It could prevent a lot of frustration as limits were approached.
If you've never seen the Bret Victor videos, then take a look sometime and you may find some inspiration.
Heater,
You complain about C++ slow compile linkage times, but this is only an issue if you go #include crazy (and it's because of file system overhead more than anything). I can compile the OpenSpin.exe in about 2 seconds total, 1.5 for compiling and 0.5 for linking. It;s not a huge project, but seems like a pretty reasonable amount of time to compile for what it is. Also, that's a release/optimized build.
I can attest to this as well - One of the things I typically do at work is just write a single .c file that #includes all my other .c files (renamed to .inc) for a given module. On a modern OS, the bulk of compilation is spent reading the #include files. If you have 3 small code files that each #include "Windows.h", the size of the code is eclipsed by the content of the headers by several orders of magnitude. If you concatenate all your code together, you only pay the #include cost once, instead of once per file.
Taken to the extreme, one of the Need for Speed titles (Playstation 2 era) compiled with gcc from the command line, in release mode, from scratch, in 28 seconds. Other projects I worked on at that time took more than a minute to do an incremental compile / link cycle (IE, a single source file change), whereas NFS recompiled *completely* in 28 seconds.
The short version: It's often not the tools, but the ways we use them, that are the problem.
Until our educational customers can't do what they want to do I'm not all sure it's that necessary, to be honest. What might push us into it is the expectation from them, whether they need it or not.
Blockly doesn't require C compilers underneath. It requires a programming language that lets us easily build blocks. We had spent so much time making things really, really high-level in our C libraries so they quickly extended themselves to Blockly. So many awesome capabilities from Spin/ASM were made even easier in C, which simplified our job a bit more.
As for people needing entertainment in education, it's really more like they have higher expectations for quick results. Our old-school educators still prefer the BASIC Stamp because timing matters and not much is hidden, but students are starting to want more, faster. . .and it has to connect to their phone, and their web site. . .
I think it's fine. Looks like a hot tool to me. I can see education jumping on something like this.
Frankly, once we get to developing "cool" stuff, there should be some compelling and fun "blocks" for people to use. Why not?
If nothing else, it will do what a lot of things have done, and that's sort the students out. Those with a strong affinity will be obvious and they can jump into other things, while everyone else gets a good sense of programming.
Chip, one thing you'd absolutely obsess over in Blockly is the colors. Thankfully, Matt has some instincts with this kind of thing so he made it look really nice - except for the "terminal" set of blocks which kinds stick out like rotten plums in an otherwise gentle landscape of pastel fruits and veggies.
It would be nice if the block colors could be customized by the user, but I don't think that's readily accessible for customization.
Ken,
P2 will open up a whole new world of sound and music and visualizations, and I think those things could provide a richer environment for kids to learn in. That's why I think you'd want blockly on P2.
Imagine running the blockly environment directly on the P2 with a monitor and keyboard/mouse attached (or just a touch screen)? Could be pretty grand.
No-one wanted to work on a standard for mailboxes. Tried many times. So did RossH. No joy.
I remember. The idea was motivated by the desire to be able to easily reuse PASM driver code and such with Spin or GCC or Catalina etc. If I recall correctly.
Nobody bought into the idea. Those that did could not agree on how to do it. And Spin actively works against it by so tightly integrating PASM with the high level Spin.
But now Spin 2 is coming. If the new Spin formalized such a code reuse and message passing mechanism. Perhaps even baking it into the syntax or supplied builtins, then that would become the standard for others to follow.
My youngest grand daughter just turned one, and when staying with us for a couple of days, she had picked up my wife's cellphone and called her mommy. All because of a graphical interface.
We got into textual programming because that's all we had, kids are going to take an easy route to do anything. A graphical interface is going to get them involved, where they take that will be up to them.
As far as graphical programming Snap! (Build Your Own Blocks) is supposed to be a much more powerful version of Scratch, but I couldn't get to the website this morning.
"...allows you to Build Your Own Blocks. It also features first class lists, first class procedures, and continuations. These added capabilities make it suitable for a serious introduction to computer science for high school or college students."
Without client-resident hosting software, Javascript apps do not have access to the user's file system or ports. It was designed that way to be safe. So a pure JS IDE would not be able to upload Spin programs to a Prop or store them on the client machine. It could only simulate them in its own sandbox.
Without client-resident hosting software, Javascript apps do not have access to the user's file system or ports. It was designed that way to be safe. So a pure JS IDE would not be able to upload Spin programs to a Prop or store them on the client machine. It could only simulate them in its own sandbox.
Except that is not true anymore.
If you have the right version of Google Chrome or Opera on the right platform a web IDE in JS can program devices via Bluetooth. As demonstrated by the ARM based Puck.js https://www.espruino.com/Puck.js+Quick+Start
Without that one can wrap any JS web IDE in Electron which makes it into a local application with node.js and all the access to local files and ports you like to allow: http://electron.atom.io/
I think we're saying the same thing. Electron is the "client-resident hosting software" I referred to above. Google is doing something similar with Chrome Apps.
Ah yes the great Bret Victor. You mean like this famous demo:
Some of the other videos might be interesting for Parallax. For example his video on MakerSpaces and data visualization. I wonder how many students would benefit from something like ViewPort integrated into the Parallax tools for visualization? (I think that Omnia Creator also had data visualization.) When I was working with software engineers who were developing GNSS software, data visualization was critical. e.g. visualizing how the chip was using resources over time to search and track satellites, as well as visualizing the constellation and environment that the user was operating in.
I remembered some other examples of graphical programming environments. There's Pure Data (Pd) for audio/music and multimedia. And ThoughtStem's LearnToMod for Minecraft mods. The latter is going after young students.
For Heater: I don't know about the latest, but ThoughtStem was using something called ScriptCraft at one point. Yeah - based on javascript. I believe that's thanks to Rhino.
I think we're saying the same thing. Electron is the "client-resident hosting software" I referred to above.
Not quite. You missed a point there.
With the Bluetooth API, in the browser, one can go straight from web page, fetched from a web site, to talking to your attached Bluetoth devices. Nothing installed locally at all. No Electron or Chrome App installation required.
I think we're saying the same thing. Electron is the "client-resident hosting software" I referred to above.
Not quite. You missed a point there.
With the Bluetooth API, in the browser, one can go straight from web page, fetched from a web site, to talking to your attached Bluetoth devices. Nothing installed locally at all. No Electron or Chrome App installation required.
That seems like splitting hairs. You do have to install something locally: a recent version of a web browser that supports the Bluetooth API. The only difference is that the web browser just happens to be something that users will already have installed.
*sigh* hold on... this is whole IDE/tool thing has hijacked the original topic, which is: what should the new Spin have in it? Can we get back to that topic? If IDEs and such are worth discussing at this point, can that be moved to a separate thread?
On the topic of Spin, a couple thoughts:
In terms of adding capability to Spin 2, I'm having a hard time seeing how to keep its simplicity. Not because of all the features people are asking for (yes, that would also make it less simple), but for all of the new features that exist in P2. If Spin 2 is going to make everything available without having to resort to PASM, I suspect the language is going to get complicated.
At what point do these changes make Spin something else? We've already had many conversations about whether P2 is a Propeller or something else. Can anyone (preferably Chip) define what makes Spin unique in such a way that it could be used as a litmus test for proposed new features? Then, if a proposed feature doesn't fit the definition, leave it out. Or add it in and call it something other than Spin.
Traditionally browsers and the JS in them, were disconnected from your computers file system and I/O devices. For obvious security reasons.
With the new HTML5 stuff that is no longer true. The plan is that a browser can store data in your file system. Access your camera, microphone, GPS, Bluetooth etc etc.
All in the name of a "fluid user experience" of course.
So, if the plan comes together, very soon any machine you buy with whatever OS will of course come with a browser which will be able to access all these things.
No pesky special download and installation required.
Comments
Manuals aren't getting read on a wide scale. I'm involved in a 3D printing related startup. People just will not do this. So, I'm making videos. People like videos a lot. I'm finding they do not require much in the way of production values either, which is nice. I use my phone most of the time. Some light editing, insert media assets, such as images, and it's fine.
Solution: Put the text in the video
As for the mindset, I'm hoping some of that gets A/B tested. There are some of the peeps slogging along in blockly. The few who grok the text wiz by, and the educator can make it clear those kids are the ones who will make the Blockly program for the rest to use.
Heh
As for spin features, I don't see advanced features and ease of use as mutually exclusive. It's just a matter of making sure we implement them properly.
But doing that is going to require we get one heck of a lot better at live evaluation of code and or video game level interface resources. Meanwhile, text is fine over 9600 baud and vi, if one wants to.
Me too. They offer a lot of features. I don't write super big things very often. For me, Sublime and a build script is just fine. Or, something like PropTool is fine too. I'm pretty flexible there. It's all good.
My favorite about PTool is live build and test, then save. It's far more intuitive than, save, build. Could just be me. Autocomplete is addictive.
Augmenting text is a good thing. I would argue most people who come up on an IDE can grok a command line, especially if they get multi-windows or screens to work with, easily enough. They may not like it, and that's OK fine too. They can do it. (Important, IMHO)
These days, I don't *need* those skills too often. Our stuff is mostly working. But, there are times still. And it's super nice to not worry so much. Do a quick syntax review, because forgetting happens, then go.
You complain about C++ slow compile linkage times, but this is only an issue if you go #include crazy (and it's because of file system overhead more than anything). I can compile the OpenSpin.exe in about 2 seconds total, 1.5 for compiling and 0.5 for linking. It;s not a huge project, but seems like a pretty reasonable amount of time to compile for what it is. Also, that's a release/optimized build.
But isn't that the tail wagging the dog?
When I was 5 years old I kicked and screamed like hell the day I found I had to go to school. I might have said I was quite happy with my picture books. But no, they wanted me to read and write, do sums and learn multiplication tables. Good grief what a pain. It's like being sent to prison, with hard labor, for 10 years.
Programming is basically mathematics. Manipulation of symbols. All be it with the help of a machine.
Is it really possible to do mathematics purely pictorially?
Do those people creating the graphical programming tools actually use those tools to do it?
I wonder if academics are devolving into entertainment. Everyone going to college. Many can't write a sentence. Fewer people needed every day to produce for the rest.
I'm kind of interested in using graphical representation to show code sitting and running, even though the code is textual. We spend a lot of time writing code, and it would be neat to be able to see it from different perspectives, in function, memory usage, and time profile, for example. It could prevent a lot of frustration as limits were approached.
Nobody much has done command line programming since the 1970's when we typed BASIC into teletypes. Editing lines in our source by entering the same line number again followed by the new text.
Actual editors that allow one to see and move around many lines in a file came later. With the green screen CRT monitors. Still with us with vim or notepad or your editor of choice.
IDEs come with Borland, and Visual Basic etc. Basically an editor that understands your source, can offer hints and tips, highlight syntax errors, build the program on a click etc.
So far we are still dealing with programming as an exercise in writing text.
Tools like Blockly are a whole different idea. One never has to enter any text. Except perhaps for filling in text dialogues some times.
Back in the day nobody got an education unless they were rich. There were few universities, like Oxford and Cambridge. Yeah, I can only talk about England but I get the feeling the same applies to the USA.
By the 1960's came the idea that everyone should have an opportunity, no matter where you came from or how much money your parents had. So the 10% or so of smart kids had a chance to get to uni. They would be subsidized with grants to make that possible.
Today everyone is expected to go to college and get a degree. Not only that they have to borrow money to do so. A great industry for banks loaning money and the many new universities serving up crappy degree courses.
The end result of all this is that as a graduate they will check what university you come from. Oxford, Cambridge, and a few other old and respected institutions. No? Sorry.
Basically back to where we started from!
If you've never seen the Bret Victor videos, then take a look sometime and you may find some inspiration.
http://worrydream.com
Notice how he is always working in source text there. Even if the output is very graphical.
Notice how functions can individually be updated on the fly to change program behavior.
Notice how it's all done in Javascript.
It's not clear to me how this can be done in Spin or traditional micro-controller languages.
It can of course be done with the Espruino JS engine on an STM32 MCU.
I can attest to this as well - One of the things I typically do at work is just write a single .c file that #includes all my other .c files (renamed to .inc) for a given module. On a modern OS, the bulk of compilation is spent reading the #include files. If you have 3 small code files that each #include "Windows.h", the size of the code is eclipsed by the content of the headers by several orders of magnitude. If you concatenate all your code together, you only pay the #include cost once, instead of once per file.
Taken to the extreme, one of the Need for Speed titles (Playstation 2 era) compiled with gcc from the command line, in release mode, from scratch, in 28 seconds. Other projects I worked on at that time took more than a minute to do an incremental compile / link cycle (IE, a single source file change), whereas NFS recompiled *completely* in 28 seconds.
The short version: It's often not the tools, but the ways we use them, that are the problem.
Until our educational customers can't do what they want to do I'm not all sure it's that necessary, to be honest. What might push us into it is the expectation from them, whether they need it or not.
Blockly doesn't require C compilers underneath. It requires a programming language that lets us easily build blocks. We had spent so much time making things really, really high-level in our C libraries so they quickly extended themselves to Blockly. So many awesome capabilities from Spin/ASM were made even easier in C, which simplified our job a bit more.
As for people needing entertainment in education, it's really more like they have higher expectations for quick results. Our old-school educators still prefer the BASIC Stamp because timing matters and not much is hidden, but students are starting to want more, faster. . .and it has to connect to their phone, and their web site. . .
Ken Gracey
Frankly, once we get to developing "cool" stuff, there should be some compelling and fun "blocks" for people to use. Why not?
If nothing else, it will do what a lot of things have done, and that's sort the students out. Those with a strong affinity will be obvious and they can jump into other things, while everyone else gets a good sense of programming.
It would be nice if the block colors could be customized by the user, but I don't think that's readily accessible for customization.
P2 will open up a whole new world of sound and music and visualizations, and I think those things could provide a richer environment for kids to learn in. That's why I think you'd want blockly on P2.
Imagine running the blockly environment directly on the P2 with a monitor and keyboard/mouse attached (or just a touch screen)? Could be pretty grand.
And Minecraft?
Well not really! No-one wanted to work on a standard for mailboxes. Tried many times. So did RossH. No joy.
So I use a mailbox in my Prop OS. You can swap std input and std output drivers, even on the fly if you wanted to.
BTW I too started on spin. But within an hour or two, was onto PASM projects. Must be something to do with age
Nobody bought into the idea. Those that did could not agree on how to do it. And Spin actively works against it by so tightly integrating PASM with the high level Spin.
But now Spin 2 is coming. If the new Spin formalized such a code reuse and message passing mechanism. Perhaps even baking it into the syntax or supplied builtins, then that would become the standard for others to follow.
Not holding out much hope though.
We got into textual programming because that's all we had, kids are going to take an easy route to do anything. A graphical interface is going to get them involved, where they take that will be up to them.
"...allows you to Build Your Own Blocks. It also features first class lists, first class procedures, and continuations. These added capabilities make it suitable for a serious introduction to computer science for high school or college students."
From the wayback machine: https://web.archive.org/web/20161109170000/http://snap.berkeley.edu/about.html
For Heater: "Snap! runs in your browser. It is implemented using Javascript"
-Phil
If you have the right version of Google Chrome or Opera on the right platform a web IDE in JS can program devices via Bluetooth. As demonstrated by the ARM based Puck.js https://www.espruino.com/Puck.js+Quick+Start
Without that one can wrap any JS web IDE in Electron which makes it into a local application with node.js and all the access to local files and ports you like to allow: http://electron.atom.io/
Which is how Microsoft created the wonderful Visual Studio Code IDE.https://code.visualstudio.com/
Javascript escaped from its "sandbox" some years ago.
I think we're saying the same thing. Electron is the "client-resident hosting software" I referred to above. Google is doing something similar with Chrome Apps.
-Phil
Some of the other videos might be interesting for Parallax. For example his video on MakerSpaces and data visualization. I wonder how many students would benefit from something like ViewPort integrated into the Parallax tools for visualization? (I think that Omnia Creator also had data visualization.) When I was working with software engineers who were developing GNSS software, data visualization was critical. e.g. visualizing how the chip was using resources over time to search and track satellites, as well as visualizing the constellation and environment that the user was operating in.
I remembered some other examples of graphical programming environments. There's Pure Data (Pd) for audio/music and multimedia. And ThoughtStem's LearnToMod for Minecraft mods. The latter is going after young students.
For Heater: I don't know about the latest, but ThoughtStem was using something called ScriptCraft at one point. Yeah - based on javascript. I believe that's thanks to Rhino.
With the Bluetooth API, in the browser, one can go straight from web page, fetched from a web site, to talking to your attached Bluetoth devices. Nothing installed locally at all. No Electron or Chrome App installation required.
Do the security implications of this worry you?
Me too.
See here: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
That seems like splitting hairs. You do have to install something locally: a recent version of a web browser that supports the Bluetooth API. The only difference is that the web browser just happens to be something that users will already have installed.
*sigh* hold on... this is whole IDE/tool thing has hijacked the original topic, which is: what should the new Spin have in it? Can we get back to that topic? If IDEs and such are worth discussing at this point, can that be moved to a separate thread?
On the topic of Spin, a couple thoughts:
In terms of adding capability to Spin 2, I'm having a hard time seeing how to keep its simplicity. Not because of all the features people are asking for (yes, that would also make it less simple), but for all of the new features that exist in P2. If Spin 2 is going to make everything available without having to resort to PASM, I suspect the language is going to get complicated.
At what point do these changes make Spin something else? We've already had many conversations about whether P2 is a Propeller or something else. Can anyone (preferably Chip) define what makes Spin unique in such a way that it could be used as a litmus test for proposed new features? Then, if a proposed feature doesn't fit the definition, leave it out. Or add it in and call it something other than Spin.
Well, yeah, OK.
But that is the whole point.
Traditionally browsers and the JS in them, were disconnected from your computers file system and I/O devices. For obvious security reasons.
With the new HTML5 stuff that is no longer true. The plan is that a browser can store data in your file system. Access your camera, microphone, GPS, Bluetooth etc etc.
All in the name of a "fluid user experience" of course.
So, if the plan comes together, very soon any machine you buy with whatever OS will of course come with a browser which will be able to access all these things.
No pesky special download and installation required.