And I don't think it's necessarily correlated to the rigor/prestige of the program. I had a discussion with Stanford professor who is building a course that involves hands-on work with real-world data problems...he undertook this initiative after finding that some PhD students, while brilliant in their research and coursework, did not know where to begin with relatively easy data cleaning work. I don't know exactly what the disconnect was, but I'm guessing it wasn't because data cleaning is particularly difficult as a CS problem. But it does require the ability to "see the big picture"...not just how different code modules and components can be designed to talk to each other, but the context and general who-gives-a-shit in regards to a given data/computational problem.
So yeah, thinking about small projects to code for is a great way to make things "click". Can't wait to see what examples Zed comes up with.
However it only started to really click when I was faced with actual real world problems and was able to solve them slowly, but one after another. We needed a simple product catalog (no ecommerce yet) with syncing capabilities from our internal FileMaker system and that small project has turned out to be the most valuable learning experience on my ongoing path of mastering Rails.
I think this is a great idea for him. I'm glad that he's taking CS education seriously. We all benefit.
My argument: Haskell and Lisp are just as practical as Python, Java, C#, or C++ for r/dailyprogrammer problems.
Brainfuck is impractical, I can agree with that.
Haskell is used in the real world. For instance I write Haskell for my day job right now.
Lisp is also used in the real world and was even used to create Lisp Machines. I got contacted by a recruiter for a Clojure job a couple days ago.
I can kind of see why you'd call Assembly impractical for the projects on r/dailyprogrammer, but would like to make sure you aren't claiming Assembly itself is impractical.
I don't think the languages are universally impractical or unusable for development (BF excluded). However, I _do_ think that they lack the resources important for beginners that are available with much more widely used languages. Not saying they don't have resources geared to beginners, but I've been bitten enough in many fields (programming, cooking, you name it!) by using something not as mainstream that I can comfortably say "Learn the popular way first, then explore." I guess though, if the goal is to go from zero to a job writing Haskell, then the "popular way" would be to learn Haskell!
Assembly.. I love doing trivial routines in assembly because it feels like a puzzle, but I struggle to think of where I would practically use it. Even on uCs such as ATtiny2313, I gain so much from being able to do control flow in C. The most assembly I've written from college is actually in TIS-100, hah.
I mean of course the companies that use some of the languages you mentioned to build large software systems every day.
One of my favorites was having people build a URL shortener using flask and SQLite. The general requirements were something like:
1. Server a web page in flask with a form.
2. Accept URL as POST from form in flask app.
3. Hash URL.
4. Store hash and URL in database.
5. Return new hash URL (ie, myshortener.com/?hash=12345) as a new page or with ajax.
6. Accept GET requests with hashes.
7. Lookup hashes in database and 301 to URL or 404.
I'm about to publish a book of simple programming practice problems based on my curriculum and experience teaching programming. Each section asks the reader to rely on more fundamental concepts, from basic input processing on to reading files, working with lists, and consuming third party APIS.
And at the end, there are some projects like what Zed is envisioning.
And I have the URL shortener in there, because it's really a fantastic programming exercise.
Like you, I believe it's really important to get people thining about solving problems with code, and I think the real key to doing that is getting them to practice.
But also, the title isn't finalized.
At work I write a lot of PowerShell scripts, and I think the reason I took to it so quickly is because the need was there. It was never ambiguous what I was going to build: I knew what I wanted to make easier, what tool I wanted to use to accomplish that goal, and it set me to learning quite quickly.
No pun intended, honestly.
Personally, though, I find no excitement in building a log searching tool. Something a bit more magical (I think something involving web scraping or markov chains would be interesting) would probably entice people to move forward much more.
Not that this tool wouldn't be useful, just that if I look at the end result, it doesn't give me the want to build it.
It wasn't until I got tasked with writing something I had no interest in as part of a recruitment process that I realised programming would always be a hobby for me, not a profession.
The sooner one realises that, the better I'd say!
The other extreme is the link in the OP, that is minimal in assistance. I think the sweet spot is somewhere in between. There shouldn't be hand-holding, but you don't want to leave the person clueless either.
Yes, kinda like in well-balanced computer games where the difficulty is just enough to be challenging yet not frustrating.
Just enough is more.
It uses Sinatra & DataMapper to take the developer through some simpler projects (URL Shortener, Microblog, etc...)
Building up from "hello world" to something with interesting learning-experience challenges involves a lot of boilerplate work. It's almost guaranteed that you won't learn the core skills surrounding managing and limiting complexity in medium and large projects, or even why these things are valuable.
It's not much work to get a build environment up for a real-world program the student might use, then have them do projects to modify it (games are great for this). This can be really rewarding, it exposes the learner to realistic, large-scale code, and it serves to get them a gut feeling for "none of this is magic, it's just a bunch of code".
When you know nothing about software and are working on a big existing code base everything is magic. It wasn't until I implemented a web app from scratch that I really understood how the web worked, and it wasn't until I wrote complex applications from scratch that I felt like I understood software.
Certainly having high quality examples of software is good for learning how a good architecture works, but at least in my experience if you don't have a good grasp of all the fundamentals (including a good mental model of object oriented concepts) everything in a complex piece of software seems like magic.
I disagree; in my experience learning how to fit your changes into an existing codebase is much more difficult for beginners.