Call me crazy, but I'm a huge fan of these type of editors (I guess IDLE can be included there too), especially Processing, Racket's Editor (DrRacket iirc) and I'm sure I've missed others (LINQPad also comes to mind!) they allow you to start out with zero knowledge, and in some cases some of these editors have some visual cues for beginners.
What I like most is that because they typically start you off with a simple file and a "run" button, there is no "how do I get this going" you just paste in your "Hello World" code sample, and you're off to see it live in seconds.
I would never use it to build a startup or some production tier work, but for prototyping its great and has significantly less distractions, you're in there to edit code and get out.
I wish Go, Rust, and even D had editors in a similar spirit to the ones I've mentioned. I feel like adoption rate for those languages (specifically D and Rust) would probably rise, especially if you bundle it all-in-one for beginners as some of these editors do (definitely Processing does!). This also would force Rust and D to consider the possibility of having a minimal built-in UI library, which I hate that these new languages do not go that route, it is why Electron is the lingua franca of UI these days.
Same. I started Java with BlueJ and if it is at all like it was in 2009 then I'd fully recommend it. It's a simple editor that doesn't overload you with information and I really like its UML-like project view with arrows between subclasses etc. It's a shame the concept would never scale to a real codebase because I really actually like the idea.
One example that comes to mind of where those fall apart is when I was trying out Racket, I was able to copy and paste sample Web code into DrRacket, and have a web server running in seconds, you (for understandably reasonable reasons) cannot do this in tools like repl.it but you can in these local editors.
Additionally, if you had these bundled editors, and offline copy of your docs for that language release, you could essentially have everything someone needs to learn a language in one shot, even if the internet is unavailable momentarily.
Your point is valid, however there is also a strong argument for doing things the hard(er) way, ie using a general text editor, and learning the compile/build process. I guess that this is how most of us here got up and running, and that time wasn't wasted. I'm a big fan of taking the longer route, and benefitting from everything I learn along the way.
I'm a seasoned developer, so this is not for me, but I am impressed. Especially the distinction between "ValueID" and "Value" that's a good way of explaining it to beginners, and a common source of error for junior software developers. My only two bits of constructive feedback would be:
1. F5 is unnatural on a Mac. Should be something like ^r (and ^R) or similar.
2. The interface looks very, um, VisualBasic or Microsoft Excel. That is fine. There is certainly a market for that. But it will turn off a huge segment of your market, namely those that aspire to be the lead in the TV show Mr. Robot. You may get some traction reskinning this whole thing to make it more slick like a machine gun you hide under your trench coat like in the Matrix and putting up a separate website or webpage and seeing which version gets more downloads.
>The interface looks very, um, VisualBasic or Microsoft Excel. That is fine. There is certainly a market for that. But it will turn off a huge segment of your market, namely those that aspire to be the lead in the TV show Mr. Robot.
I know that this is meant kind of in jest, but do younger people really have much opinion one way or another about computer UIs? There's so much UI fragmentation on the modern Windows desktop, the aggregate effect is an aesthetic mess no matter what you do.
Yes, they do, and it has nothing to do with purposeless decoration or pretending to be a leet haxor as others implied.
To even moderately experienced developers, a UI is a tool we use to interact with an application.
To everyone else, the UI is the application.
We developers need to develop an novice-level understanding of many things we touch but don't specialize in... Perhaps the domain we're developing software for, or networking, or database work. We also tend to get the classic novice overconfidence in those topics because we've never needed to know as much as the experts and therefore have never encountered problems we weren't qualified to solve... or so we think. UI design is one of those things.
I'm an art school educated UI designer, have done significant work in serious graphic design, and worked for a decade as a full-time back-end web developer for a reputable organization. The number of developers that have tried to explain UI design to me, even knowing my background, is astonishing. I'm male, but it looks exactly like mansplaining by my estimation.
UI design is a profession totally separate from software development and graphic design because making a good UI is a totally different process than either of those things– it's more akin to industrial design. Most developers don't understand its importance, and vastly overestimate their ability to create and evaluate interfaces themselves. I contribute code to open source projects all the time... but trying to contribute design work is a miserable experience. This is the reason independent open source alternatives will remain alternatives and never become standards.
I take supporting evidence from IDE market shares. All of the top results are either commercial software or mostly controlled by companies that have staff UI designers. The one org that controls a top contender that didn't seem to employ a dedicated UI designer is Eclipse, which is famous for its usability... Just not in a good way.
> UI design is a profession totally separate from software development
> ... trying to contribute design work is a miserable experience. This is the reason independent open source alternatives will remain alternatives and never become standards.
These statements contradict each other and show how design is not separate from at least some aspects of software development (frontend application development).
Most open source projects may leave the GUI as an afterthought or not even provide one. It makes all the sense in the world to separate the frontend from the backend especially if the goal is standardization.
You might want to try your hand at frontend dev after working for so long on the backend. The discipline sorely needs people who understand both design and backend. You sound like you'd do very well.
How are those statements contradictory? UI design is a separate discipline from software development just as automobile design is separate from automotive mechanical engineering. I am both a developer and designer.
While it was never my sole full-time job, I've done a few thousand hours of front-end development in various environments both professionally and for FOSS projects. I'm quite familiar with how all of these pieces fit together and completely comfortable with my chosen professional path.
Yes and no. There's a large segment of students who are not 100% passionate about programming in itself and follow what looks and feels nice over what's practical. But that's their los IMO.
Yes. I have been looked at with a certain amount of envy by youngsters with my "hacker looking" linux terminal at full screen typing like a madman on a train or in a cafe.
Kids are influenced by movies and they want to be cool and powerful.
I've used Thonny on the Raspberry Pi and find a few things frustrating about it. The only other Python IDE I've used is PyCharm on the Mac. I prefer PyCharm but where Thonny feels a little too bare-boned, PyCharm has too much going on for this newbie.
It would be really cool if there was an editor where the UI started out incredibly bare and progressively added panels/buttons/etc as you used the corresponding python features for the first time.
Thonny actually does this on the basic raspberry pi install. It launches into a basic mode with big tablet like buttons and then you can click "Advanced Mode" and it goes to a more normal Windows experience with drop down windows and more options. On a personal note, i've found thonny to be the easiest way to get started with raspberry pi pico development. You just plug your pico in, fire up thonny and select the Micropython interpreter and you are now live coding on a rp2040 microcontroller. It can even download the fresh U2F image to your pico. It is a very good/simple user experience.
I'm a seasoned developer, so this is not for me, but I am impressed.
This kind of take always shows up in threads about simpler tools and it always amazes me. This reads to me as "I'm a seasoned developer, so I'm too good for this." I'm not sure what you consider seasoned as I've only be developing software for 25 years but one day I hope to achieve these lofty heights.
namely those that aspire to be the lead in the TV show Mr. Robot
I work with loads of hackers who avoid "real IDEs" like the plague. I think you vastly misunderstand that crowd.
I think he means Thonny is good for freshman who learns by some toy examples, but far from a handy tool for projects of medium or large scale, which a "seasoned" developer would likely build.
I've used Thonny to teach programming to complete beginners with good results.
Most people love it and are loathe to switch to VS Code to PyCharm later on in the course.
What really works nicely for teaching is that after code is run from .py fle, session stays interactive and you can use commands from REPL and see variable values, types, ids.
Really helpful when starting out.
When switching to VS Code, students are confused why debugger is not "live" after code is run.
Some tiny pain points with Thonny:
I do wish a few keybindings were more "usual"
For example un/comment is Ctrl(Cmd)-3 . It makes sense for Python, but Ctrl-/ is pretty much standard everywhere else.
Also pop up help for functions and classes and tab completion does not work too well (at least on versions under 4).
Thonny has a nice built in interface to pip.
Unfortunately it used to conflict with Anaconda installations.
Had a case 2 years ago when half the class had problems with packages because Thonny was installed ahead of Anaconda.
Maybe those issues are fixed now in the latest version.
I didn't know about Thonny, but I teach some Python as well. In VSCode, I tell people to add #%% at the start of their script. Then ctrl-enter will run it in a nice interactive window with an interpreter below it for "live" debugging. (The Jupyter notebook integration is also working better than before, not sure what I prefer this days)
I actually only recently became aware of Thonny when working with MicroPython on a Raspberry Pi Pico. It made it really easy to work on a program and execute it on the device. I’ve worked with Arduino and such over the years, but the edit/execute cycle with MicroPython was much quicker. I didn’t do much with it beyond blinking some LEDs, but I came away pretty impressed.
I’ve been doing the same, except I went one step further. I’m currently extending Micropython to add a DMA class to the RP2 port.
I can build and debug Micropython via VSCode and use Thonny to write some Python to test.
I could with the setup being a bit quicker (maybe an 8GB pi 4 would help)
On the C source level you mean (and also on-device or rather the unix port or so?)? Or is there already functional Python-level debugging these days (I know there's basic trace module support)?
Yes, I can set breakpoints in the C code and run the firmware on a Pico.
It’s all running on a Pi4, so it was just a matter of adding the debug pins on the Pico and configuring vscode (instructions followed in docs).
I've had the best experience with Thonny working with MicroPython. I'm amazed at how seamless updating files and even flashing MicroPython on devices like the ESP8266 and Pico is. I do miss the Python coding experience of PyCharm when using it though.
My dad is nearing retirement and has never thought of himself as someone who is capable of programming. However, he is mechanically inclined. Was a mechanic for sometime and knows construction fairly well. This mechanical aptitude leads me to believe that he would be able to pick up programming just fine.
Anyway, I think this would be an excellent resource for him to take his first steps.
One obscure aspect of thonny i like is that the whole thing is a simple "executable" package (i.e. a normal package with a __main__.py file). That's it.
This is also my favourite way of packaging python apps. Excludes all need for layer upon layer of external packaging, dependency, and distribution requirements.
i think py_installer is for producing actual executables, i.e. where you don't need an interpreter installed.
but in any case, even if it werent, the point I'm making above is exactly that you dont have to use external programs to package, distribute, or manage your "app". it's just a normal python package, run as nature intended, so to speak.
I love Thonny. Used it to show my kids Python. It's not quite as easy as Swift Playgrounds, but it was fun showing them how to draw stuff with "turtle", and then collaboratively making a snake game with "arcade".
I'm not sure about your teaching experience. But when i teach function, i told my students: Function application is just substitution. That's it. Function is a template for you to substitue.
Higher order function ? Just more substitution !
Your source code is a long text template, no magic to it.
> Function application is just substitution.
>> No, no, no! This is wrong, and really bad pedagogy.
I would avoid the word "substitution" until after evaluation order has been covered. Python has applicative order evaluation like most languages. Pedagogically, since evaluation is just a basic concept, it should be explained before the student even gets to functions. Then, when you get to function application, it probably shouldn't take much more to explain that arguments are evaluated first and only then is the function applied on the evaluated values of those arguments. The values are then substituted wherever the parameter appears.
If side effects weren't in the picture, you could postpone discussion of evaluation order a little bit longer until you discuss the consequences evaluation rules have for runtime complexity (using pedagogically appropriate language, of course). So you could get away with allowing inaccurate ideas about substitution for a little while.
I teach the concept of a procedure since that's how functions are in most programming languages but I also emphasize the concept of a mathematical function. The procedure perspective looks into the box whereas the functional perspective thinks more about composition than the details inside the box.
4 → square_root → triple → ?
How does the square_root function work? It's an interesting question but often times assembling multiple atoms into a structure is more empowering and exciting; plus children will be using functions where the details elude them for quite awhile. Using functions with elusive details is also typical in math pedagogy so children should get used to reasoning around black boxes.
I rather see functions as transformations, in the mathematical sense. A function receives an input and produces an output, according to some logic that only the function is responsible for. A small logical block that can be reused into somehow bigger logical blocks (i.e. programs). I think it is much more realistic, lead you to good programming practice, and also much more fun.
I have tried to teach that and students have always (seem) to like & understand this approach. It was for student at university level, so maybe more able to understand this 'functional' view of functions.
Yes, but functions in Python are not that. Mathematical transformations don't support closures for one.
Dictionaries are more like functions and indeed I taught myself to understand hashmaps as "frozen functions" way back when. You can easily find the set-valued inverse of a function by saying
{v: [k for k in d.keys() if k[v]==v] for k, v in d.items()}
and that's close to the mathematical definition too.
It seems to be an intuitive way to explain it, which is probably why it found its way into the specs for some early languages.
The problem is that it gets very complicated real fast once you start dealing with non-trivial expressions as arguments, shadowed identifiers, and recursion.
A debugger! Thank you!! Step-by-step debuggers are crazy useful for beginners, yet most small IDEs targeted at beginners/non-programmers don't have them. Especially when dealing with loops and recursion, stepping through and seeing the values change and stack grow is invaluable for learning how a program executes and makes finding issues less frustrating.
I'm on a phone right now so I can't try it, but does it by any chance allow evaluation in the paused state? That's also been pretty handy for me when teaching beginners.
Thonny is deceptively good. I am a long-time developer and use it for MicroPython work on RP2040 (Pi Pico) and have written a 600 LOC firmware in it. It’s not the most Mac-like, but they keyboard shortcuts are changeable, and its configurable interface can be as slim as you like it (just text) on up to variables, the stack, and debugging. It’s also a great tool when I want to play in REPL — it just feels light and fun.
That's where I ran across it when I recently got some Picos. The tutorials I found use it and it seems to be the expected way to up them, at least if you're using micropython.
I used Thonny from when I was just starting to learn how to code. It was a great experience. Neat, much lighter than the PyCharm, easy-to-use, simple UI, adding packages is just about 2 clicks. Not much to complain, although sometimes the package installation dowsn't work.
Thanks for that. I spent part of the day fighting with my kid's Windows 11 PC to properly install the requests module in the Python IDLE, without success. He had Thonny already installed and installing requests was a snap.
There are a lot of features here I think even experts would find valuable - for example, I wouldn't mind having the step-through expression evaluator, the debugger, and even the variable panel on hand.
I used this to demonstrate a few basic programming techniques to my nephew on a Raspberry Pi a few years ago. I asked him what he wanted to see and he said "a square train!" (Kid loves Minecraft, wants to see everything modeled in little cubes.) So I imported Python's turtle module and had it draw a train with square wheels, square boxcars, a square smokestack, etc. Then I showed him something called "refactoring", by taking the instructions to draw, say, a wheel, and putting them into a function so we can draw as many wheels as we like, anywhere, by calling it.
Anyway, it must've helped give him the bug because a couple years later he was asking to help me load software onto his Raspberry Pi-powered car, entering Linux commands with ease.
He turns 12 this year. He's probably outgrown Thonny. I bet he's ready for Emacs.
When I saw that it has an AST-sensitive debugger, I was really impressed! And the code for it is quite something to behold - aside from the fact it could be broken into a couple files and have a few more comments, it's the type of thing that truly shows off how this is a well-designed codebase with a nearly self-documenting extension API!
This is the most QBasic-like IDE I could find to install on my son's laptop when he became code-curious. I found myself wishing documentation was better integrated somehow, but it's a very tasteful little app.
I hadn't even heard of it before I purchased one of the above (I'm well versed in just using vim or PyCharm), but it seems great for newbies. Things like this need to exist - UIs like PyCharm are overwhelming for starter programmers.
We developed a product using the RP2040 and had to use Thonny. PhCharm wasn't handling the upload/run/debug process well. If I remember correctly, it had to do with the mechanics of the console. We developed in PyCharm and simply used Thonny as a code uploader/debugger. This worked well. Not sure it would be a good fit for complex projects. Of course, that isn't the intended use case. It's a nice IDE and a commendable effort.
Is the main value to the expression debugger that it makes explicit the order of evaluation, or the specific intermediate values? (or is it pretty much both that provide the value?)
It makes explicit stuff like operator precedence, but it's especially helpful when you have to explain function calls and recursion.
For the latter specifically, Thonny has a mode where for every call stack frame, it opens up a separate child editor window that displays the code of the function in that frame, highlighting the current line. When you step through, the visual substitution of expression results happens in the window for the frame where it is happening. Thus, when you have a chain of recursive calls, you can see all the substitutions that it took to get there.
I love the idea, but I gotta say that this didn't make a great first impression for me.
I downloaded and installed the Mac version, I wrote a basic program to play with it, clicked the little "bug" on the top, and the entire program crashed, which is a pity because I think this could be really useful for my students.
Awesome, the debugger is exactly what I believe a beginner needs. And the variable -> value lie which can then be extended to variable -> address -> value, EXCELLENT! This is literally how I teach programming. I'm not a teacher, though, just got friends who want to learn.
It is ok if.... if I use it myself? It looks really neat!
And if I can add something, I feel like the addition of plugins might overcomplicate things and, at that point, maybe the users are ready to move into another IDE? Not saying it is bad, just maybe that not all IDEs need plugin support.
compared to Scratch, it looks pretty dull, not sure my kids would love it. And at first sight it lacks something I would find very useful, that is a timeline of execution (where you can go back and forth in time). However, the comments seem very clear and useful and I'm sure that helps a lot the students to understand.
I've used this IDE to teach my wife programming.
It's really great for beginners where they can just pick it up without worrying about which versions of Python they should use and how to import/delete packages!
I'm not too much of an IDE guy these days, but I appreciate that Thonny allows one to specify which interpreter to use, including one running on an attached MCU.
Taking a little inspiration from Sublime Text in terms of usage of screen real estate would do the author a lot of good. That said, functionally this is amazing.
What I like most is that because they typically start you off with a simple file and a "run" button, there is no "how do I get this going" you just paste in your "Hello World" code sample, and you're off to see it live in seconds.
I would never use it to build a startup or some production tier work, but for prototyping its great and has significantly less distractions, you're in there to edit code and get out.
I wish Go, Rust, and even D had editors in a similar spirit to the ones I've mentioned. I feel like adoption rate for those languages (specifically D and Rust) would probably rise, especially if you bundle it all-in-one for beginners as some of these editors do (definitely Processing does!). This also would force Rust and D to consider the possibility of having a minimal built-in UI library, which I hate that these new languages do not go that route, it is why Electron is the lingua franca of UI these days.