| News | Features | Interviews |
| Blog | Contact | Editorials |
| Learn programming by visualizing code execution |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-20 20:27:39 |
| "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." |
|
| awesome! |
| By stabbyjones on 2012-09-21 00:10:12 |
|
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! |
 - Score: 5 |
| barrier...learning |
| By l3v1 on 2012-09-21 00:44:30 |
|
> 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-unders tanding tool. |
| - Score: 2 |
| RE: awesome! |
| By satsujinka on 2012-09-21 02:42:41 |
| It's also similar to how Scheme is taught in SICP. Though it's better put together and interactive. |
| - Score: 2 |
| RE: barrier...learning |
| By Alfman on 2012-09-21 05:25:24 |
|
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 |
| - Score: 2 |
| RE: barrier...learning |
| By dnebdal on 2012-09-21 07:27:51 |
|
> > 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-unders tanding 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... |
| - Score: 2 |
| Like WinDbg |
| By JeeperMate on 2012-09-21 07:51:15 |
|
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. |
| - Score: 3 |
| RE[2]: barrier...learning |
| By Neolander on 2012-09-21 09:24:01 |
|
> 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... |
| - Score: 2 |
| RE[3]: barrier...learning |
| By dnebdal on 2012-09-21 11:07:16 |
|
> 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?" |
| - Score: 2 |
| RE[4]: barrier...learning |
| By Neolander on 2012-09-21 11:54:21 |
| Well, both courses can be taught simultaneously, isn't it ? |
| - Score: 2 |
| Visualizing code execution |
| By kwan_e on 2012-09-21 12:05:42 |
| Whenever I look at someone else's code, I do tend to visualize an execution. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |