Linked by Thom Holwerda on Thu 20th Sep 2012 20:27 UTC, submitted by MOS6510
General Development "Online Python Tutor is a free educational tool that helps students overcome a fundamental barrier to learning programming: understanding what happens as the computer executes each line of a program's source code. Using this tool, a teacher or student can write a Python program directly in the web browser and visualize what the computer is doing step-by-step as it executes the program."
Order by: Score:
awesome!
by stabbyjones on Fri 21st Sep 2012 00:10 UTC
stabbyjones
Member since:
2008-04-15

This is really similar to how i taught myself python while at uni.

Python was the first language i enjoyed and helped me learn other languages by giving me the ability to look at things in a programmatic way.

Great to see stuff like this!

Reply Score: 5

RE: awesome!
by satsujinka on Fri 21st Sep 2012 02:42 UTC in reply to "awesome!"
satsujinka Member since:
2010-03-11

It's also similar to how Scheme is taught in SICP. Though it's better put together and interactive.

Reply Score: 2

RE: awesome!
by Tuishimi on Sat 22nd Sep 2012 22:51 UTC in reply to "awesome!"
Tuishimi Member since:
2005-07-06

I have a soft spot for python, tho' I never get to use it anymore.

Reply Score: 2

barrier...learning
by l3v1 on Fri 21st Sep 2012 00:44 UTC
l3v1
Member since:
2005-07-06

helps students overcome a fundamental barrier to learning programming: understanding what happens as the computer executes each line of a program's source


While the tool and the approach itself seems nice, I still think that it's done backwards. The students need to be explained and taught how a computer works, how code is executed, what happens when a program runs, how and what instructions do, and then the barrier will not exist anymore. Such tools can be useful in explaining all that, for sure, but not as a programming-learning tool, more a programming/language-understanding tool.

Reply Score: 2

RE: barrier...learning
by Alfman on Fri 21st Sep 2012 05:25 UTC in reply to "barrier...learning"
Alfman Member since:
2011-01-28

l3v1,


"While the tool and the approach itself seems nice, I still think that it's done backwards. The students need to be explained and taught how a computer works, how code is executed, what happens when a program runs, how and what instructions do, and then the barrier will not exist anymore."


Personally, I think the way you do. When I was starting out, I was not satisfied merely learning how to program in a language, I wanted to understand the technology behind my program. I delved into assembly, software interrupts, controlling peripherals directly, etc. I wouldn't have had it any other way. On the other hand, real CS skills are becoming marginalised. Few employers need us to work on CS problems any more, instead CS graduates are finding employment in generic IT roles where CS skills are not especially in demand.


The following rant is my view on the evolution of this field and my pessimistic view of the future in terms of jobs.

In the past, most businesses needed CS people because they developed software & databases in-house from the ground up. In my very early experience as a summer intern, many of these systems were written in pascal & C using simple binary flat records, typically reserving some empty filler in each record. These records were loaded strait into memory and displayed on a textual user interface. Some programs were simple, others much more complex, but CS developers were in high demand (although as an intern in high school, I wasn't actually paid).

Fast forward to today, businesses use off the shelf software instead of writing it themselves. Now instead of a CS guy, a business actually needs more of an IT guy. The software companies selling this software still need CS guys, but the trend has been for them to consolidate and lay-off such that one software package could be installed at a multitude of client companies who would no longer need their own CS guy. This undoubtedly made businesses more efficient on the whole. The demand for IT went up, but CS went down.

Now we're in the midst of another trend, the shift away from off the shelf products towards software as a service ones. It's being sold as way for companies to become more cost effective by outsourcing it's in-house IT functions to the provider. (Email, documents, databases, etc). There are strong proponents of either side, and there's still doubts as to whether it will pan out or not. But one thing is for sure, if the promise of SaaS cost effectiveness is to ring true, then IT spending will have to decrease proportionally to revenue. In other words the future demand for IT is likely to plunge as SaaS improves business efficiency.

Edited 2012-09-21 05:36 UTC

Reply Score: 2

RE: barrier...learning
by dnebdal on Fri 21st Sep 2012 07:27 UTC in reply to "barrier...learning"
dnebdal Member since:
2008-08-27

"helps students overcome a fundamental barrier to learning programming: understanding what happens as the computer executes each line of a program's source


While the tool and the approach itself seems nice, I still think that it's done backwards. The students need to be explained and taught how a computer works, how code is executed, what happens when a program runs, how and what instructions do, and then the barrier will not exist anymore. Such tools can be useful in explaining all that, for sure, but not as a programming-learning tool, more a programming/language-understanding tool.
"


I don't necessarily think that's the best approach for everyone. Starting at the high-end helps ease the student into thinking in an appropriately structured way. There is a certain barrier in understanding just how rigidly things are interpreted, and just how generic the building blocks are - and how to structure something to get the intended results. With that in place, digging deeper is easier: If you can understand not-entirely-trivial python programs, it's possible to understand (roughly!) how the python interpreter has to work, and from there on to "it's also (maybe indirectly) (sys-)calling the kernel to get certain things done" isn't a giant leap. The details of what makes the kernel special (memory mapping & swapping, interrupts, locking, IO, etc.) follow naturally, and somewhere in that it makes sense to look at how a CPU actually works.

Starting top-down does probably lead to more sloppy programmers, since they might not care as much about the lower levels when they feel they can already do something useful. Starting bottom-up will probably bore some potentially good future programmers to death (since they won't see the use yet), and does probably lead to more myopic programmers (the microƶptimization above structure - type).

And no, I'm really not sure what the best solution is. "Everything at once" would be great, but that might not be completely doable...

Reply Score: 2

RE[2]: barrier...learning
by Neolander on Fri 21st Sep 2012 09:24 UTC in reply to "RE: barrier...learning"
Neolander Member since:
2010-03-08

I don't necessarily think that's the best approach for everyone. Starting at the high-end helps ease the student into thinking in an appropriately structured way. There is a certain barrier in understanding just how rigidly things are interpreted, and just how generic the building blocks are - and how to structure something to get the intended results. With that in place, digging deeper is easier: If you can understand not-entirely-trivial python programs, it's possible to understand (roughly!) how the python interpreter has to work, and from there on to "it's also (maybe indirectly) (sys-)calling the kernel to get certain things done" isn't a giant leap. The details of what makes the kernel special (memory mapping & swapping, interrupts, locking, IO, etc.) follow naturally, and somewhere in that it makes sense to look at how a CPU actually works.

Starting top-down does probably lead to more sloppy programmers, since they might not care as much about the lower levels when they feel they can already do something useful. Starting bottom-up will probably bore some potentially good future programmers to death (since they won't see the use yet), and does probably lead to more myopic programmers (the microƶptimization above structure - type).

And no, I'm really not sure what the best solution is. "Everything at once" would be great, but that might not be completely doable...

In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture. It has been done before, and seems to work quite well...

Reply Score: 2

RE[3]: barrier...learning
by dnebdal on Fri 21st Sep 2012 11:07 UTC in reply to "RE[2]: barrier...learning"
dnebdal Member since:
2008-08-27


In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture. It has been done before, and seems to work quite well...


Certainly, and I've been in both kinds - but that doesn't really solve the question of "if we want programmers that care a bit about the lower-level effects of the code they write, while still being decent at high-level code and structure - what's the optimal order to teach in?"

Reply Score: 2

RE[4]: barrier...learning
by Neolander on Fri 21st Sep 2012 11:54 UTC in reply to "RE[3]: barrier...learning"
Neolander Member since:
2010-03-08

Well, both courses can be taught simultaneously, isn't it ?

Reply Score: 2

RE[5]: barrier...learning
by dnebdal on Fri 21st Sep 2012 17:00 UTC in reply to "RE[4]: barrier...learning"
dnebdal Member since:
2008-08-27

Sure, though that could also be argued to be the only way they can learn both without benefiting from already having learned the other. ;)

Reply Score: 2

RE[4]: barrier...learning
by renox on Fri 21st Sep 2012 14:08 UTC in reply to "RE[3]: barrier...learning"
renox Member since:
2005-07-06

I think that it may depends on the student..
Me, I find learning low level first easier because when something "magic" happens in a high level language you can look at how it is implemented to better understand it.

Reply Score: 2

RE[5]: barrier...learning
by satsujinka on Fri 21st Sep 2012 16:05 UTC in reply to "RE[4]: barrier...learning"
satsujinka Member since:
2010-03-11

I find that a low-level description is actively harmful for most new students. It's simply too irrelevant for their attempts at learning the language at hand and only adds to the information they have to memorize. Of course, I may be misunderstanding what you mean by low-level. I take it to mean explicitly detailing what op codes/assembly instructions and registries are/do.

Typically, I find that functional languages are easier to teach because everyone has some experience with math and can do basic substitution (even if that's not how things are actually evaluated, substitution is a good enough model to start with.)

Reply Score: 2

RE[6]: barrier...learning
by Alfman on Fri 21st Sep 2012 18:31 UTC in reply to "RE[5]: barrier...learning"
Alfman Member since:
2011-01-28

I guess low level is a bit vague, but when I use it I'm referring to understanding what the hardware is doing at a hardware level. Conversely high level for me would mean hiding the hardware behind abstractions.

As much as I appreciate the low level stuff, I think it's hard to make a case for why most students would ever need it.

Reply Score: 2

RE[7]: barrier...learning
by Neolander on Sat 22nd Sep 2012 07:05 UTC in reply to "RE[6]: barrier...learning"
Neolander Member since:
2010-03-08

I guess low level is a bit vague, but when I use it I'm referring to understanding what the hardware is doing at a hardware level. Conversely high level for me would mean hiding the hardware behind abstractions.

As much as I appreciate the low level stuff, I think it's hard to make a case for why most students would ever need it.

I can think of quite a few big market who might actually need it, such as embedded stuff or hardware development. Now, I guess what you implied is that "one doesn't really need the low-level stuff to build user-mode software".

I'd say that this, too, can be debatable, though. As an example, when people know so little about computer memory hierarchies and their management that they end up considering memory allocation as a magic thing that brings extra objects to their code whenever they need it, memory management overhead will cause performance problems in their software in the long run.

Edited 2012-09-22 07:06 UTC

Reply Score: 2

RE[6]: barrier...learning
by renox on Sun 23rd Sep 2012 13:05 UTC in reply to "RE[5]: barrier...learning"
renox Member since:
2005-07-06

I find that a low-level description is actively harmful for most new students. It's simply too irrelevant for their attempts at learning the language at hand and only adds to the information they have to memorize. Of course, I may be misunderstanding what you mean by low-level. I take it to mean explicitly detailing what op codes/assembly instructions and registries are/do.


Not *that* detailled, but for example learning how virtual functions work by looking at vtables and the pointer.


Typically, I find that functional languages are easier to teach because everyone has some experience with math and can do basic substitution (even if that's not how things are actually evaluated, substitution is a good enough model to start with.)


Provided you don't want to teach about performance..
Otherwise at some point you have to look at the binary generated, which is not too bad with C/C++ but with Haskell..

Reply Score: 2

RE[3]: barrier...learning
by Alfman on Fri 21st Sep 2012 14:33 UTC in reply to "RE[2]: barrier...learning"
Alfman Member since:
2011-01-28

Neolander,

"In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture."

Don't most students start programming well before they reach university? Even by high school, those who have an interest are probably already programming.

In any case, my university didn't do it that way. All first year courses were taught in Eiffel, a relatively obscure high level language. I'm not even sure we touched C except in specialty electives. After us, they replaced Eiffel with Java in our program, but I doubt they increased emphasis on low level fundamentals.

Reply Score: 2

RE: barrier...learning
by ilovebeer on Fri 21st Sep 2012 19:56 UTC in reply to "barrier...learning"
ilovebeer Member since:
2011-08-08

While the tool and the approach itself seems nice, I still think that it's done backwards. The students need to be explained and taught how a computer works, how code is executed, what happens when a program runs, how and what instructions do, and then the barrier will not exist anymore. Such tools can be useful in explaining all that, for sure, but not as a programming-learning tool, more a programming/language-understanding tool.

You have to be careful not to throw too much at someone new to coding. It can quickly become overwhelming and actually make things harder for them to understand. The fine print and advanced details can come later, after they've gotten a minimal/basic foundation for the language and the logical thinking.

I know decent coders who don't know every last in & out, and I know crap coders who do so part of the equation is the actual person and not simply to quantity of detail they've memorized.

Reply Score: 2

RE: barrier...learning
by ndrw on Sat 22nd Sep 2012 05:01 UTC in reply to "barrier...learning"
ndrw Member since:
2009-06-30

Both low-level and high-level skills are useful and partially overlap but at the beginner level, if you don't plan your career in softrare engineering, you just have to pick one of them. And even if you do, you should start with both simultaneously (e.g. C on Arduino and Python programming on PC).

Given that an educated person is more likely to use programming languages for automating stuff or writing simple one-off utility programs, starting from Python makes a lot of sense. In a way, an interactive enviromnent eliminates many of the problems you are talking about.

Reversing your point, you can't (or won't) learn programming well (breaking down the problem, structuring the program so that you don't end up with a spaghetti code, learning about data structures, OOP and FP idioms etc.). Just like Python is not the best tool for learning about a PC memory model, C is a poor choice for getting familiar with anything else.

Reply Score: 2

Like WinDbg
by JeeperMate on Fri 21st Sep 2012 07:51 UTC
JeeperMate
Member since:
2010-06-12

This is essentially akin to WinDbg, but for Python plus fancy visuals minus debugging symbols minus OS dependency.

I see how this is useful for those who have no prior programming knowledge. Back in the days, I learned C and C++ by littering my source codes with #define macros, #ifdef, and #endif to print out code execution path, which get really messy very quickly -- Internet was a luxury at the time, so we couldn't just look up something everytime we hit a wall, and there was nothing similar to CodeReview. I ended up learning some Assembly to be more efficient in debugging and to better understand the implication of every single line of code I write.

I like Python, but I haven't got a chance to build real software with it. I do use it for quickly testing ideas in code form and, to a degree, prototyping.

Reply Score: 3

Visualizing code execution
by kwan_e on Fri 21st Sep 2012 12:05 UTC
kwan_e
Member since:
2007-02-18

Whenever I look at someone else's code, I do tend to visualize an execution.

Reply Score: 2