I've read a few books for a couple of programming languages (go, rust), but I still need some kind of project to really see the big picture and think deeply.
What kind of project (besides some CHIP-8 emulator) would you recommend?
Thank you and I'm more than curious about your answers.
For example, if you're into some kind of sports, build a software that helps you keep track of it. If you like cooking, build a recipe tracker. You know the gist.
By building something that helps you with some of your passions, you'll feel more connected to it and more engaged with the project.
This does not need to be a product, or something you'd try to sell or market. Build it for you. Share it with those people you like, if you feel like doing it, but build it for you.
Also, you will find you end up with a somewhat different feature set, get to fix what annoys you.
That depends on what your goal is. If your aim is to learn the programming language, code up that program/task/tool even if someone else has already done it.
If you get stuck on a solution chances are someone else has already solved it in your language of choice which can also be great for learning.
It should make you have go into text and file processing (including regexps) and basic data structures (lists/arrays, hashmaps, trees, graphs). Maybe GUIs or image processing: it's never essential, but sometimes it helps in debugging a puzzle, or it's just fun to make a visualization of the solution. Even simple parsers.
However, typically you wouldn't touch things like async, networking or writing a server. Though you could try writing an HTTP API client that automates downloading inputs, many people do it.
I'd still recommend it mostly because it's very fun, in my experience, which keeps you motivated.
In the past I have made a point of doing AOC in a language I didn't know or was planning to learn. Maybe rust this year...?
That forces you to think real world usability etc
It doesn’t have to be a problem with actual value to anyone, but once you start thinking about it, you will probably find it engaging to solve.
[1] https://knowing.net/posts/2006/06/15-exercises-to-know-a-pro...
[2] https://knowing.net/posts/2006/06/15-exercises-to-know-a-pro...
[3] https://knowing.net/posts/2006/06/15-exercises-to-know-a-pro...
I think building non-web GUIs may have become harder since 2006, depending on platform/language.
I don't always release it publicly, but it's a 'solved' program that I don't have to spend time reworking how the core of it works (needs a hex grid with number tiles, mouse or keyboard input, a menu system, computer opponents, etc), although I might rework some things or add new features to it.
I've done this to learn C# (and XNA), Java (and J2ME), Objective-C (and OpenGL ES), Swift (and SpriteKit), and LUA (with Pico-8).
I've also made versions in Python (text console), for Kindle, and the original was in Flash, but I knew the tech ahead of time.
I recommend it. Can be anything relatively simple. Make a blackjack game, a version of tetris, a Todo app, a Sudoku solver, a web service, whatever seems interesting to you.
Trying to figure out a way so potentially hundreds of viewers on Twitch can play along with a Twitch streamer, essentially joining a team and voting for where to place their tile, or just play like normal. Had to take a break working on it recently (job hunting), but I hope to jump back into it after I get settled at a new job.
I need to do a newer update video (you can play a full game now, more focused on adding menus and streamer support right now), but you can see kind of what I'm doing with the third game here, if you're curious. There's videos of Proximity 2 in action on my channel as well:
I also would not want to program in Rust for 100% of the time. It's a great tool to have for certain mission-critical types/parts of software where the cost of a mistake is high, but it also can be very frustrating to work with, at least until you become proficient with the idiomatic ways to structure programs and code in Rust. And even then I would not pick it for R&D type of work for instance, where you have to experiment and refactor a lot. Borrow checker is something you have to keep in mind at all times, and as I said already it can be extremely frustrating when you simultaneously have to think about design, execution logic and performance. Doubly so when the parts you're working on are not going to be concurrent in any foreseeable future.
OTOH, I can see how coding something well-defined and to the spec can be rewarding and less expensive in the long run with Rust.
Basically, I would say the easiest way would be to choose something you've already conquered in a language/system you already know. That way, you're only tackling one new thing.
BTW, it wasn't always biorhythms for me - I originally wrote my Mandelbrot program in Pascal, and taught myself C in order to convert it to C so it would run faster.
- Simplest game ever is a number guessing game. Obviously solvable by binary search on the player side. It's like an exciting counterpart for Fibonacci for learning PL flow-control structures. Additional features: limit number of guesses, make players guess floats instead of just ints. Latter will obviously teach you about FP handling in your language of choice.
- Next up, make that two dimensional, so the player is now guessing coordinates instead of numbers. Needs more math, you will definitely implement the distance formula. You can add a backstory if you like (are you bombing enemies in stealth perhaps?) and add mechanics based on that backstory.
- For something more complex---and I think this is your level now---people might suggest a constrained DF/Rogue-like. But me, that always grows more complex than a pedagogical device when I do it. So I stick to boring text games, sometimes inspired by game shows. Quizmaster-types (ala Who Wants to be a Millionaire), hangman-types (ala Wheel of Fortune), would force you to create structures for abstraction, all staying within complexity budget.
Happy hacking!
There are a lot of MaL examples written in Lisp even, which initially sounds redundant, but gets new Lisp programmers to learn Lisp's internals by writing them in the same language.
This is similar to the "old days" when people used to write a BASIC interpreter or C compiler to learn a new language (writing a compiler teaches you ASM programming, so it's a good comparison with the dual nature of MaL)
I always turn to Cryptopals when kicking the tyres on a new language.
The project is a hurricane modelling and visualization program, which is pretty specific to my experiences, but having that to riff on has been my way of learning scala, python, c#, and (soon, in theory) Go.
Ex: I wanted to learn C, but my reasoning was only that it seemed like "real" programmers knew it. But that's not a good reason. Instead what I really wanted was to get closer to hardware and build software that did low-level operations. So I learned objective C and build audio-processing software for iOS that I actually wanted to work on. So I was able to learn a bit of the language and a bunch of other cool things that I still use today.
It allows me to test a few things I care about: filesystem operations, templating engine, reflection (or lack of), string parsing, testing, build systems. It also gives me a feel on the ecosystem (e.g. how many good quality Markdown parsers? Do I have to write my own).
Also, because I have a few of them I can make something of a comparison between languages for this particular use case (how long did it took me? how fast does it process the sources?)
- a monitoring system for my home automation devices, the checks go from generic (is the site up?) to specific (are the water leak sensors up?)
- a program to keep track of the chores my children are supposed to do (a backend with an API, a mobile application and a hook into the home dashboard)
- my note taking program, because the world absolutely needs one more
I use a bus for communication (MQTT) but also APIs, so the rewrite quickly brings me into the technicalities of the language as I do not have th reinvent how the programs work. On the other hand, these rewrites led to plenty of improvements.
I don't generally bother with features like macros etc, I just get enough going to define and evaluate functions in a repl. When you keep the scope small like this it doesn't take very long, and it can be broken up into a few fairly well defined evenings - e.g. lex, parse and eval.
One caveat is that if you haven't written a toy interpreter before then it will take you a bit longer. Once you know a little about the common techniques and patterns it's easy though.
edit: grammar
Ideas include building a Git, shell, search engine, and of course compiler/programming language.
https://golang.org/pkg/net/http/ https://golang.org/pkg/encoding/json/
[0] https://aosabook.org/en/index.html https://github.com/aosabook/500lines
Go and Rust are fairly similar in terms of parallelization and performance. Both are general purpose languages and are great at solving system problems. Choosing a toy project that requires these perks will yield the most satisfying results and enables you to get a good grasp of why those languages exist, and where their differences are.
Both languages empower you to build inter-system applications, both languages are highly performant and both let you build safe and tested programs. A distributed ray tracing engine comes to my mind - it would allow you to let both languages collaborate, compare solutions to problems between the languages and get into the nitty gritty details of memory management, allocations, garbage collection etc.
This would probably be my pick, because you can build and improve it for years if you really want to put the effort in it.
Here's a great primer on that topic - it's still actively developed and made me look at modern ray tracing technology in awe.
https://www.reddit.com/r/learnprogramming/comments/g98sn4/sp...
It gives you an idea of what the language can do and how to handle network connections with it.
