If that were true they would be demanding Java, or C#, or C++. Heck even Spin is more object oriented than Python.
By the way, schools have had perhaps 30 years to think about OOP. Just now the front line of development has realized it's a bad idea:)
With the exception of maybe Java those languages are compiled languages. When teaching programming the "instant" feedback of scripting languages or interactive langauges (basic or forth for example).
Then, a company purchased multi-million dollar (capital purchase) mainframe that had software services (people) bundled in with the contract.
Now, a company purchases $20K worth of commodity hardware and has several $150K/year plus programmers writing code for it. Employees are all expense dollars. An agile team costs $1M a year in expense money, hardware costs will never come close to that.
Your bottom line doesn't recognize fast, tight code, it recognizes speed to market and contract programmers.
pypy is interesting. May actually be useful around here. Thanks for the heads up on that.
pythonb on the other hand, well, it's amusing:)
@ValeT
Why not.
There are little issues like memory space and raw speed to consider. I have a feeling that a Python run time just wont fit and if it did it would be too slow to think about.
Then there are issues of things like, how Python can handle integers with thousands of digits, or it's dynamic types which I'm sure Spin byte codes are not designed to handle. A variable is not just a simple memory location in Python.
@4x5n,
"compiled or interpreted" is orthogonal to "object oriented or not".
As it happens both C# and Java are similar in being compiled to byte codes which are then interpreted. Neither of them have that instant feed back of the REPLs of Scheme, Python, JavaScript, Forth, Perl, BASIC etc.
I do agree that the instant feed back of a REPL is a great help in the early steps of learning to program. Well, even a great help all the time after that.
It does depend though on what you are trying to teach. If you want to teach algorithms and how and why different algorithms for doing the same thing can have massive difference in performance then the details of the language in use are indeed trivial. Better to use the language that has the least amount of hassle and go straight to the topic at hand.
Selecting the "right" language and using it efficiently might get you a speed up of a few times. But using the wrong algorithm will wipe all that out by being thousands of times slower!
"compiled or interpreted" is orthogonal to "object oriented or not".
As it happens both C# and Java are similar in being compiled to byte codes which are then interpreted. Neither of them have that instant feed back of the REPLs of Scheme, Python, JavaScript, Forth, Perl, BASIC etc.
I do agree that the instant feed back of a REPL is a great help in the early steps of learning to program. Well, even a great help all the time after that.
It isn't REPL, but LINQPad is a great tool for working with C#, it also supports VB.Net, F#, SQL but I have not tried it with them.
I've been getting a co-worker up to speed on C# and it has been a very valuable tool. I also use it regularly to test small sections of code and as a simple test harness.
If the requirement is "must run python on the prop", then I think the answer is "won't fit".
However, if the requirements is "prop must talk to python on the (linux, windows,etc) PC/workstation/node", then its easy, all we need is to define the interfaces. Then whatever on the prop can be implemented in whatever language or tool is handy, and the results would be easy to test. But, this would probably be no fun since its too easy, and anybody could do it that way.
On a decent CPU, with a SSD and plenty of RAM, the time to compile your average 'learning' program is as fast as an interpreted language.
Yep, but there still are basic differences. One of those is state. Interactive environments can present a state to a user, who can incrementally build things up. And if the environment is spiffy, they can be doing that while things are going on.
A UNIX shell is one such environment. Open a coupla windows, or just one, and start processes, background them, set environment, sort data, etc... This is a powerful thing. Of course, one could write a program to do those things, and let's say it was really fast to do. It still is "outside" the task, and when that "run it" button is pressed, everything starts over. Or, can start over. On an OS that has sufficient capability, one can break things into processes and get a result similar to the shell, but I don't see that as being the norm.
Personally, I always wanted to add just a few things to a BASIC, such as ON COG DO: where it really does allow for some backgrounding, multi-process type interactive work...
And on the P2, we sort of got that with the little monitor. I would run for long periods of time, pushing code to it, doing stuff while other code was running, etc...
Anyway, regardless of where any of us land in the scheme of things, there is more than "time to make it happen" when considering interactive and compiled programming. And that can impact how people learn.
As far as Python in education MIT switched over to Python from scheme a while back. This was somewhat controversial as many people absolutely love the SICP book. If you're interested just search a little and you can find Sussman's comments.
Also these days Minecraft is a trend in education. Of course it's not just about programming, but it just so happens that there's a port to the Raspberry Pi which can be scripted from Python. You can of course do this on PCs and Macs. But take a look at this ongoing kickstarter for an example of the available funding for this type of thing:
How much programming and electronics will kids learn on such a platform? How could the propeller help?
I haven't taken a look at the book "Adventures in Minecraft" but it does have an electronics related chapter. The propeller might be useful as an I/O expander for a PC/Mac in such an application.
I would think that a PC/Mac + I/O expander would be a far superior platform to the Piper one as pictured. Or even just a Pi with a better monitor and keyboard would be an improvement. But the concept of portability seems to demo well. It looks like they're just making a case with a built in display, writing software, and bundling a minimal amount of parts. Given that piper says they are going to open up their source, it looks like anyone should be able to assemble something similar if they are interested. Maybe they'll have a server component for teachers as their secret sauce.
Anyways Minecraft on Propeller with python scripting - impossible ;-)
Then, a company purchased multi-million dollar (capital purchase) mainframe that had software services (people) bundled in with the contract.
Now, a company purchases $20K worth of commodity hardware and has several $150K/year plus programmers writing code for it. Employees are all expense dollars. An agile team costs $1M a year in expense money, hardware costs will never come close to that.
Your bottom line doesn't recognize fast, tight code, it recognizes speed to market and contract programmers.
The above applies to the application development space.
For the embedded space, I think "tighter, faster code" is more relevant. Saving 50 cents on a part because you can code it tighter and faster has the quantity-sold multiplier in the equation. There, the savings to the bottom line are worth pursuing.
One of Parallax's best selling points is the BASIC Stamp series since it's been around for years and will be around for many more.
How many other companies continue to make and support the same product for decades?
For example, look at all the Arduinos that are no longer supported.
Spin is a great language because it's easy to learn yet powerful.
Just like the BASIC Stamp, Chip knew what he was doing when he created Spin.
Spin is a great tool for teaching programming and Parallax should create a series of texts that teach programming techniques such as structured or object oriented programming, as well as the process of "software engineering."
As others have said, students should concentrate on the programming process, and the advantage of using a Parallax product is that years from now it will still be around.
No one likes wasting their time on things that are here today and gone tomorrow.
Parallax will still be here along with the BASIC Stamps, the Propeller, and whatever new creation(s) Chip dreams up next.
This is a foundation subject in modern software development techniques for engineering and information technology. The design and development of component-based software (using C# and .NET) is covered; data structures and algorithms for modeling, analysis, and visualization; basic problem-solving techniques; web services; and the management and maintenance of software. Includes a treatment of topics such as sorting and searching algorithms; and numerical simulation techniques. Foundation for in-depth exploration of image processing, computational geometry, finite element methods, network methods and e-business applications. This course is a core requirement for the Information Technology M. Eng. program.
he course is broken into four phases, each of which lasts approximately one month. Phase I will give you a grounding in the basics of Object Oriented Programming and the C++ language. Phase II will introduce Java® and some of the basic algorithms and data structures, such as arrays, trees, searching, sorting, geometric reasoning etc. Phase III will introduce the Java® programming language, which will be used for your term projects. Phase IV will be a final project to give you a chance to put your new knowledge into practice on a challenging project. The project this year will focus on building a simulation to demonstrate a physical principle of your choice.
In summary:
Phase I: C++ and OOP
Covers classes and objects, inheritance, virtual functions, abstract classes, polymorphism
Phase II: Algorithms
Searching and sorting methods
Phase IV: Project
Selected advanced topics in Java® and C++. Simulation (term project) using Java® and/or C++.
That's quite a collection of items to tackle with a series of texts using Spin and the Propeller.
I don't see the Propeller and Spin as a Software Engineering learning platform but it certainly has a number of features that make for a very good Embedded Engineering learning platform.
Instead of interpreting Python on the Propeller microcontroller, or offloading the interpreter to another microcontroller, it may be a more viable option to compile the Python code using Propeller GCC, for example by running it through Cython.
The resulting C source is 1734 lines long.
The compiled and stripped executable is 13456 bytes.
Can you provide type guidelines to shrink that ?
How much does it grow, with the same code repeated (new variable names) ?
(often there is some base-load / framework code, so the results may be less kb/line added )
I have no idea about type guidelines. I'm no regular Python user.
Recursive fibo:
def fib(n):
if n == 0:
return 0
elif n == 1:
return 1
else:
return fib(n-1) + fib(n-2)
print fib(5)
Compiles to 2630 lines of C and a 23760 byte stripped executable.
Adding back code similar to my first example a few times, with different variable names, adds about 63 lines to the C code each time. Which seems to equate to 500 odd bytes in the executable size.
All chicken feed compared to the support libraries.
I have no idea about type guidelines. I'm no regular Python user.
Adding back code similar to my first example a few times, with different variable names, adds about 63 lines to the C code each time. Which seems to equate to 500 odd bytes in the executable size.
What types does the C code declare the variables as ?
Looks like Python can 'sort of' be persuaded to pass type information, so as a trial you could code one of each of these Array types (ie sum the first two array elements into the 3rd, with constant indexes )
My understanding is that the SICP (Structure and Interpretation of Computer Programming) class was one of those love it or hate it classes. Some people say it changed their whole view of programming. Check out the interesting review distribution on Amazon if you're curious.
Dirt cheap CPU cycles and near infinite memory pretty much squashed the need for fast, tight code.
So it doesn't matter if a IDE takes a gig of RAM to run or for a OS just to start up. You simply throw more cycles and memory at the problem until it goes away.
I've been toying with the idea of building a Propeller resident Python interpreter on top of the Tachyon VM using the microSD (or serial Flash) to hold the virtual memory files. Since the Tachyon VM and O/S does fit on a standard Propeller and supports virtual memory while the VM itself is very fast and compact it seems logical to compile to this model while also supporting the resident Python interpreter. A cross-compiler IMO would lose the interactive flavor of Python and basically be reduced to "another glorious PC compiled language" that could just as easily be cross-compiled to an ARM etc but would always pale in comparison to a resident interpreter.
Then I had a look at the C source code for a Python interpreter and it was as I expected, HUGE, but from my experience it's only impossible when you look up at the mountain of code and think of climbing it rather than looking for a better way. Sometimes it's better not to look at the mountain in the first place, just do it. That is what I'm doing at present (amongst other things) and I believe it's possible (oh boy, I'm sweating) to tweak and enhance the text interpreter part of Tachyon to evaluate typical Python expression. In my experiments some expressions require very little internal tricks to compile directly to Tachyon bytecode. I have as much memory as an SD card will hold and it's possible to use overlays or even "interpret" bytecode from file using a caching technique similar to what I did with the dictionary when I first put it in SD, so that sections of code and loops still run at full speed.
I'm not saying all this is easy but I don't think it's impossible either although it certainly is a challenge and a half. As I am thinking of material to include in my Circuit Cellar article for the IoT5500 then mentioning the possibility of a future Python interpreter might prove beneficial for Parallax also, after of course when I have demonstrated that this is possible and viable that is.
Personally the reason I don't favor certain "languages" is simply for the reason that they don't run directly and interactively on the target = Propeller. Either way implementing Python may change that and really "propel the Propeller" and pave a ready and hungry market for the P2. Of course for more performance you can always drop down to Forth
Though this scares me, I do however love a challenge, nothing better to get you motivated and focused I say!
Maybe I'm dreaming. What do you think? Am I mad? Will I regret it? Basic would be a lot easier.....
So what did you decide? Are you going to do this? Your Tachyon system is pretty fast and capable. I can't wait to see what you do with Python or Basic!
Lately I've had many requests for Python on the Propeller, from middle school through university.
Thanks,
Ken Gracey
Hi Ken,
I'm not sure if you're following this post anymore but do you know what people who asked for Python on the Propeller were looking for? Did they just want to run Python programs on the Propeller or did they want the interactive experience of being able to type Python directly on a serial port connected to a Propeller or even on a PS2 keyboard plugged into a Propeller connected to a VGA monitor? Is it the interactive experience they were after?
Cython certainly looks unfit for embedded unless it's target is a Raspberry or BB Black.
Strangely enough I just found out that cython was used in the first prototypes of the Raspberry Pi idea. However it did not have that name at the time and it was based on some ATMEL ATMEGA644 chip. That early machine generated TV Video and 3D graphics!
Strangely enough I just found out that cython was used in the first prototypes of the Raspberry Pi idea. However it did not have that name at the time and it was based on some ATMEL ATMEGA644 chip. That early machine generated TV Video and 3D graphics!
Comments
Why not? Is Python just to broad ( large number of commands, etc ) to do that?
With the exception of maybe Java those languages are compiled languages. When teaching programming the "instant" feedback of scripting languages or interactive langauges (basic or forth for example).
Hear hear!
Whatever happened to fast, tight code?
Then, a company purchased multi-million dollar (capital purchase) mainframe that had software services (people) bundled in with the contract.
Now, a company purchases $20K worth of commodity hardware and has several $150K/year plus programmers writing code for it. Employees are all expense dollars. An agile team costs $1M a year in expense money, hardware costs will never come close to that.
Your bottom line doesn't recognize fast, tight code, it recognizes speed to market and contract programmers.
pypy is interesting. May actually be useful around here. Thanks for the heads up on that.
pythonb on the other hand, well, it's amusing:)
@ValeT There are little issues like memory space and raw speed to consider. I have a feeling that a Python run time just wont fit and if it did it would be too slow to think about.
Then there are issues of things like, how Python can handle integers with thousands of digits, or it's dynamic types which I'm sure Spin byte codes are not designed to handle. A variable is not just a simple memory location in Python.
@4x5n,
"compiled or interpreted" is orthogonal to "object oriented or not".
As it happens both C# and Java are similar in being compiled to byte codes which are then interpreted. Neither of them have that instant feed back of the REPLs of Scheme, Python, JavaScript, Forth, Perl, BASIC etc.
Oddly there is an interpreter for that most compiled of languages C++ ! https://root.cern.ch/drupal/content/cint
I do agree that the instant feed back of a REPL is a great help in the early steps of learning to program. Well, even a great help all the time after that.
Mickster,
Whatever happened to fast, tight code?
Indeed.
It does depend though on what you are trying to teach. If you want to teach algorithms and how and why different algorithms for doing the same thing can have massive difference in performance then the details of the language in use are indeed trivial. Better to use the language that has the least amount of hassle and go straight to the topic at hand.
Selecting the "right" language and using it efficiently might get you a speed up of a few times. But using the wrong algorithm will wipe all that out by being thousands of times slower!
On a decent CPU, with a SSD and plenty of RAM, the time to compile your average 'learning' program is as fast as an interpreted language.
It isn't REPL, but LINQPad is a great tool for working with C#, it also supports VB.Net, F#, SQL but I have not tried it with them.
I've been getting a co-worker up to speed on C# and it has been a very valuable tool. I also use it regularly to test small sections of code and as a simple test harness.
C.W.
However, if the requirements is "prop must talk to python on the (linux, windows,etc) PC/workstation/node", then its easy, all we need is to define the interfaces. Then whatever on the prop can be implemented in whatever language or tool is handy, and the results would be easy to test. But, this would probably be no fun since its too easy, and anybody could do it that way.
Yep, but there still are basic differences. One of those is state. Interactive environments can present a state to a user, who can incrementally build things up. And if the environment is spiffy, they can be doing that while things are going on.
A UNIX shell is one such environment. Open a coupla windows, or just one, and start processes, background them, set environment, sort data, etc... This is a powerful thing. Of course, one could write a program to do those things, and let's say it was really fast to do. It still is "outside" the task, and when that "run it" button is pressed, everything starts over. Or, can start over. On an OS that has sufficient capability, one can break things into processes and get a result similar to the shell, but I don't see that as being the norm.
Personally, I always wanted to add just a few things to a BASIC, such as ON COG DO: where it really does allow for some backgrounding, multi-process type interactive work...
And on the P2, we sort of got that with the little monitor. I would run for long periods of time, pushing code to it, doing stuff while other code was running, etc...
Anyway, regardless of where any of us land in the scheme of things, there is more than "time to make it happen" when considering interactive and compiled programming. And that can impact how people learn.
Also these days Minecraft is a trend in education. Of course it's not just about programming, but it just so happens that there's a port to the Raspberry Pi which can be scripted from Python. You can of course do this on PCs and Macs. But take a look at this ongoing kickstarter for an example of the available funding for this type of thing:
https://www.kickstarter.com/projects/withpiper/piper-a-minecraft-toolbox-for-budding-engineers
There are other Minecraft related startups such as http://minecraftedu.com/ and http://www.learntomod.com/ that either help teachers manage classrooms or teach programming.
How much programming and electronics will kids learn on such a platform? How could the propeller help?
I haven't taken a look at the book "Adventures in Minecraft" but it does have an electronics related chapter. The propeller might be useful as an I/O expander for a PC/Mac in such an application.
I would think that a PC/Mac + I/O expander would be a far superior platform to the Piper one as pictured. Or even just a Pi with a better monitor and keyboard would be an improvement. But the concept of portability seems to demo well. It looks like they're just making a case with a built in display, writing software, and bundling a minimal amount of parts. Given that piper says they are going to open up their source, it looks like anyone should be able to assemble something similar if they are interested. Maybe they'll have a server component for teachers as their secret sauce.
Anyways Minecraft on Propeller with python scripting - impossible ;-)
Wow! Funded in 3 days, at almost 200% funding with 17 days to go and a 12 month delivery window on many of the rewards! WOW!
The above applies to the application development space.
For the embedded space, I think "tighter, faster code" is more relevant. Saving 50 cents on a part because you can code it tighter and faster has the quantity-sold multiplier in the equation. There, the savings to the bottom line are worth pursuing.
How many other companies continue to make and support the same product for decades?
For example, look at all the Arduinos that are no longer supported.
Spin is a great language because it's easy to learn yet powerful.
Just like the BASIC Stamp, Chip knew what he was doing when he created Spin.
Spin is a great tool for teaching programming and Parallax should create a series of texts that teach programming techniques such as structured or object oriented programming, as well as the process of "software engineering."
As others have said, students should concentrate on the programming process, and the advantage of using a Parallax product is that years from now it will still be around.
No one likes wasting their time on things that are here today and gone tomorrow.
Parallax will still be here along with the BASIC Stamps, the Propeller, and whatever new creation(s) Chip dreams up next.
That's quite a collection of items to tackle with a series of texts using Spin and the Propeller.
I don't see the Propeller and Spin as a Software Engineering learning platform but it certainly has a number of features that make for a very good Embedded Engineering learning platform.
Along those lines, I thought this article was interesting: The education of embedded systems software engineers: failures and fixes[url][/url]
Indeed it was. Thanks!
Never heard of cython, interesting.
A quick download and compile later and I have the following result.
The Python program: The resulting C source is 1734 lines long.
The compiled and stripped executable is 13456 bytes.
It depends on libraries, particularly the python run time support libpython3.4m.so.1.0. A mere 4.2 MegaBytes !
And a bunch of other libraries.
Yeah, that ain't gonna fit.
Can you provide type guidelines to shrink that ?
How much does it grow, with the same code repeated (new variable names) ?
(often there is some base-load / framework code, so the results may be less kb/line added )
I have no idea about type guidelines. I'm no regular Python user.
Recursive fibo:
def fib(n): if n == 0: return 0 elif n == 1: return 1 else: return fib(n-1) + fib(n-2) print fib(5)Compiles to 2630 lines of C and a 23760 byte stripped executable.Adding back code similar to my first example a few times, with different variable names, adds about 63 lines to the C code each time. Which seems to equate to 500 odd bytes in the executable size.
All chicken feed compared to the support libraries.
What types does the C code declare the variables as ?
Looks like Python can 'sort of' be persuaded to pass type information, so as a trial you could code one of each of these Array types (ie sum the first two array elements into the 3rd, with constant indexes )
https://docs.python.org/3/library/array.html
https://docs.python.org/3/library/functions.html#bytes
and see how that passes-thru into C code.
Cool, I see Python has a divmod(a, b) supported, - how does that pass into C ?
CPU cycles are a lot cheaper than programmers salaries
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00-introduction-to-computer-science-and-programming-fall-2008/syllabus/
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-01sc-introduction-to-electrical-engineering-and-computer-science-i-spring-2011/Syllabus/
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-02-introduction-to-eecs-ii-digital-communication-systems-fall-2012/Syllabus/
My understanding is that the SICP (Structure and Interpretation of Computer Programming) class was one of those love it or hate it classes. Some people say it changed their whole view of programming. Check out the interesting review distribution on Amazon if you're curious.
So it doesn't matter if a IDE takes a gig of RAM to run or for a OS just to start up. You simply throw more cycles and memory at the problem until it goes away.
I'm not sure if you're following this post anymore but do you know what people who asked for Python on the Propeller were looking for? Did they just want to run Python programs on the Propeller or did they want the interactive experience of being able to type Python directly on a serial port connected to a Propeller or even on a PS2 keyboard plugged into a Propeller connected to a VGA monitor? Is it the interactive experience they were after?
You can see that prototype running at the start of this video: https://www.youtube.com/watch?v=P5KEiuTT_E8
It does not have an accompanying RAM chip like the Proto Pi so no 3D graphics I guess.