My heyday in programming was about five years ago, and I’ve really let my skills fade. I started finding myself making excuses for my lack of ability. I’d tackle harder ways to work around problems just so I wouldn’t have to code. Worst of all, I’d find myself shelving projects because I no longer enjoyed coding enough to do that portion. So I decided to put in the time and get back up to speed.
Normally, I’d get back into programming out of necessity. I’d go on a coding binge, read a lot of documentation, and cut and paste a lot of code. It works, but I’d end up with a really mixed understanding of what I did to get the working code. This time I wanted to structure my learning so I’d end up with a more, well, structured understanding.
However, there’s a problem. Programming books are universally boring. I own a really big pile of them, and that’s after I gave a bunch away. It’s not really the fault of the writer; it’s an awkward subject to teach. It usually starts off by torturing the reader with a chapter or two of painfully basic concepts with just enough arcana sprinkled in to massage a migraine into existence. Typically they also like to mention that the arcana will be demystified in another chapter. The next step is to make you play typist and transcribe a big block of code with new and interesting bits into an editor and run it. Presumably, the act of typing along leaves the reader with such a burning curiosity that the next seventeen pages of dry monologue about the thirteen lines of code are transformed into riveting prose within the reader’s mind. Maybe a structured understanding just isn’t worth it.
I wanted to find a new way to study programming. One where I could interact with the example code as I typed it. I wanted to end up with a full understanding before I pressed that run button for the first time, not after.
When I first read about literate programming, my very first instinct said: “nope, not doing that.” Donald Knuth, who is no small name in computing, proposes a new way of doing things in his Literate Programming. Rather than writing the code in the order the compiler likes to see it, write the code in the order you’d like to think about it along with a constant narrative about your thoughts while you’re developing it. The method by which he’d like people to achieve this feat is with the extensive use of macros. So, for example, a literate program would start with a section like this:
Continue reading “Learn To Program With Literate Programming”
Kids, and Hackaday editors, love robots! The Open Roberta project (OR) takes advantage of this to teach kids about programming. And while the main focus is building a robot programming language that works for teaching grade-school and high-school kids, it’s also a part of a large open source robotics ecosystem that brings a lot more to the table than you might think. We talked with some folks at Google, one of the projects’ sponsors, about where the project is and where it’s going.
Building a robot can be very simple — assembling pre-configured parts or building something small, quick, and cute — or it can be an endeavour that takes years of sweat and tears. Either way, the skills involved in building the ‘bot aren’t necessarily the same as those it takes to program the firmware that drives it, and then eventually the higher-level software that makes it functional and easy to drive.
OR, as an educational project, makes it very, very easy for kids to start off programming robots, but it’s expandable as the user gets more experienced. And since everything is open source, it’s part of a whole ecosystem that makes it even more valuable. We think it’s worth a look (along with something significantly more complex like ROS) if you’re playing around with robotics.
Open Roberta is the user-facing middleware in a chain of software and firmware bits that make a robot work in a classroom environment. For the students, everything runs inside a browser. OR provides a webserver, robot programming interface and language, and then converts the output of the students’ programs to something that can be used with the robots’ firmware. The robots that are used in classrooms are mostly based on the Lego Mindstorms EV3 platform because it’s easy to put something together in short order. (But if you don’t have an EV3, don’t despair and read on!)
The emphasis is on ease of entry for the students and the teachers supervising the class. Everything runs in a browser, so there’s nothing to install on the client side. The students connect to a server that directs the robots, communicating with the robots’ own operating system, and uploading the students’ programs.
Continue reading “Open Robots with Open Roberta”
A while back I wrote a piece titled, “It’s Time the Software People and Mechanical People Sat Down and Had a Talk“. It was mostly a reaction to what I believe to be a growing problem in the hacker community. Bad mechanical designs get passed on by what is essentially digital word of mouth. A sort of mythology grows around these bad designs, and they start to separate from science. Rather than combat this, people tend to defend them much like one would defend a favorite band or a painting. This comes out of various ignorance, which were covered in more detail in the original article.
There was an excellent discussion in the comments, which reaffirmed why I like writing for Hackaday so much. You guys seriously rock. After reading through the comments and thinking about it, some of my views have changed. Some have stayed the same.
It has nothing to do with software guys.
I definitely made a cognitive error. I think a lot of people who get into hardware hacking from the hobby world have a beginning in software. It makes sense, they’re already reading blogs like this one. Maybe they buy an Arduino and start messing around. It’s not long before they buy a 3D printer, and then naturally want to contribute back.
Since a larger portion of amateur mechanical designers come from software, it would make sense that when I had a bad interaction with someone over a design critique, they would be end up coming at it from a software perspective. So with a sample size too small, that didn’t fully take into account my positive interactions along with the negative ones, I made a false generalization. Sorry. When I sat down to think about it, I could easily have written an article titled, “It’s time the amateur mechanical designers and the professionals had a talk.” with the same point at the end.
Though, the part about hardware costs still applies.
I started out rather aggressively by stating that software people don’t understand the cost of physical things. I would, change that to: “anyone who hasn’t designed a physical product from napkin to market doesn’t understand the cost of things.”
Continue reading “Continuing The Dialog: “It’s Time Software People and Mechanical People Had a Talk””
With the advances in rapid prototyping, there’s been a huge influx of people in the physical realm of hacking. While my overall view of this development is positive, I’ve noticed a schism forming in the community. I’m going to have to call a group out. I think it stems from a fundamental refusal of software folks to change their ways of thinking to some of the real aspects of working in the physical realm, so-to-speak. The problem, I think, comes down to three things: dismissal of cost, favoring modularity over understanding, and a resulting insistence that there’s nothing to learn.
Continue reading “It’s Time the Software People and Mechanical People Sat Down and Had a Talk.”
After hour and hours spent in front of a terminal or IDE, a user begins to build a list of infuriating little things. That one pop-up box that happens every time you press that button by mistake. The noise the software makes when the compile fails. Or the horrible reality that your code just crashed because there wasn’t enough difference between uppercase ‘O’ and a zero. In comes the programming font.
The typical way to find a programming font is to troll forums for a user with a similar problem and see if they have a workable solution. [Koen Lageveen] went out and found nearly all of the free programming fonts out there and compiled a list. He then took one more step and wrote a web app that lets you test them out. Hopefully this will help those in the very real struggle for the perfect programming font. You can try out the tool for yourself, and if you really like it [Koen] has all the code up for it on his GitHub.
[via Hacker News]
Programmers and software engineers will always use the latest development environments, the trendiest frameworks, and languages they learned only 21 days ago. What if this weren’t the case? What if developers put care into their craft and wrote programs with an old world charm? What if Windows executables were made with the same patience as artisanal firewood, or free range granola? [Steve] has done it. He’s forging a path into the wilds of truly hand crafted executables.
The simplest executable you could run on a Windows box is just a simple .COM file. This is an extremely simple file format that just contains code and data loaded into 0100h, and a jump to another point in the code. The DOS .EXE file format is slightly more complicated, but not by much. [Steve]’s goal was to build a proper Windows executable without a compiler, assembler, linker, or anything else.
Continue reading “Bespoke, Artisanal, Hand Made Executables”
Today (September 13, 2015) is Programmer’s Day — a recognition day that started in Russia, but has been adopted by many countries. While it is great that there is a day recognizing the contribution of programmers to society, the really interesting part is why it is on September 13 (except on leap years).
The leap year part should be a clue. Today is Julian day 256. We’ll guess that anyone reading Hackaday doesn’t need to be told the rest of the story. While it might not be as good of an in-joke as May the 4th (be with you), it is satisfying to know that it isn’t just a random date from the calendar. Now if we could only get the day off as paid vacation…
Continue reading “Happy Programmer’s Day”