Pokemon games!! All of the algebra is solved, and you can dig as deeply as you like in any direction you like.
Graphics? Check. And simple, top down, tilesheet or character maps work just fine.
Battles? Check. You can leverage anything from purely functional, object oriented, websocket, long polling, SQL, you name it. Whether you use 3 elemental types or flesh out everything from multiturn, semivulnerable, exp/leveling, it's all up to you.
Wanna just build an REST/GraphQL/gRPC API? Or a UI? PokeAPI is an opensource database of nearly all game data from moves, items, and species.
Pokemon is an endless, any-scope, extremely documented, opensource-rich field of exploration.
That's actually a great idea, hey. The only problem is getting C&D'd if you find yourself mesmerized by how much you like a new system into developing something that people would actually want to play.
At which point, going the "Freedom Planet" route and re-skinning is probably the epic gamer move I'd want to take.
As for nitty gritty graphics, I highly recommend https://pikuma.com. They have free and paid courses, and go into a lot of the in-depth aspects you wouldn't get from using a web framework like I typically do.
As for game mechanics, Wikipedia is a surprisingly solid resource. I mean, it's expected that these things are covered, but the depth is amazing. Check out this page for example!
To study the ROM, and how the 1st Gen games work, I recommend this article, which covers the mechanics of the bit level organization of the first games
Yeah! I've done it a few ways, mostly in React. I'm currently trying my hand at it in Solid.js, as I want to learn it, and Web Components.
As for graphics, I've been following along in this book, and absolutely love it. They have an online version. You use the author's bespoke engine, so it does abstract much of it, but it covers things from map generation to event buses!
Only as complex as you want to make it! My very first Pokemon game was a case statement where you picked your first Pokemon and it emulated the dialogue.
My second attempt was before I knew about OOP or FP, and just had a C++ array that held Pokemon data in set indexes. That was during my first programming class haha
I do recall writing a text "battle" game in the Pokemon style with Harry Potter characters but that was a single battle sequence. It was also before I knew OOP and for my first programming class :) Your comment brought back some memories.
The thing that my job is requiring me to do. Trial by fire. But also after the 4th or 5th language and Nth framework, it gets much quicker to pick up new ones.
This, but also I like to at least have a Hello World console app (or API server or web page or database reader or whatever the bare minimum is) that I can play around with and know that I can create something from scratch and not be entirely at the mercy of whatever the work infrastructure is.
But I also agree with the last sentence. When you are just starting out in your career, it's nice to have something more complex (I used to write sudoku solvers) to really get the feel of things. I'd never do that anymore though, as most things are similar enough to something I'm already pretty comfortable with.
The default used to be a blog engine. It's a complex enough web app that you can learn how web servers and database access work in the language/framework. But it's also easy enough that you don't need to spend a lot of time on a data model.
The benefit is that the design of a blog web app is going to be very similar in a variety of languages that you can compare different frameworks/languages pretty easily. The downside is that if your language is better at non-webapp things, it's not going to be an easy exercise.
Basically the same for me, but for a different reason than sibling comments: Nothing sticks in my head with toy projects, I need to be solving an actual problem.
On rare occasion I do end up learning something outside of the job, like I learned basic perl writing an IRC bot, but for the most part it does end up being on-the-job.
Agreed, though this goes beyond jobs to e.g. side projects also. Rather than "make X so that you can learn language Y," I would "learn language Y so that you can make X," where X is some project uniquely suited to language Y.
I'm an embedded/real-time/systems software developer. The realms I work in tend to be either the very small or the very large. When I wanted to learn Rust and Go, I coded the same application in both of them, one that I had previously coded in Java, C++, and C: I implemented the Generic Cell Rate Algorithm using a virtual scheduler. The GCRA is a traffic shaping algorithm that takes as parameters a desired peak rate, sustained rate, and maximum burst size, to meter or police traffic. I coded it as a library function, and provided a unit test to convince myself that it worked. I can only learn by doing, and that's what I did. One of the reasons I like this approach is it requires a lot of stuff: threads, synchronization, modularization, etc. https://coverclock.blogspot.com/2018/11/vamoose-rustler.html
same embedded developer here, my problem is that daily job only needs c/c++ so my skill about python or js or golang is always weak -- after a while I forgot many of their details due to lack of serious need...
my problem is: how to keep 3~4 language 'warm' at all times? write some code daily on each?
I found Python to be a great sidekick for embedded work. Parsing the captured logs, decoding memory sections, crafting specific hex sequences, building mock devices making desktop supporting tools... The syntax is different enough from C/C++ that I don't mix them up. Currently switching between 3 languages and I do notice a stray keyword from wrong language occasionally slips in.
Find out what the most common domain is for that language. If that domain is unfamiliar to me, I try to find a good tutorial on building something in it. The self-correcting part is if the language is good for the domain 99/100 a times an excellent tutorial can be found on it.
I'm not gonna write a compiler in Rust, and I'm not gonna write a web server in Haskell (reading between the lines the opposite is true).
So just for example
Kotlin => a quick web app or a mobile app
Python => rewrite some bash script I've been meaning to improve, or write some statistical analysis with numpy
In the process I get to learn a new domain at the same time, and get to see what that looks like when an ecosystem actively tries to make it easier.
Of course sometimes it's good to try to use a language for something it's not commonly used for, and find out how much programming can suck when no-one has worked on smoothing out the edges.
I just can't help it, I have to break out this old Kent Pitman saw. I'm not posting this to evangelize; I just think it's funny in context:
"But please don’t assume this is an exhaustive list, and please don’t assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and Ecommerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list. Common Lisp really is a general language capable of a lot more than these few incidental application areas, even if this web page doesn’t totally bring that out."
I use https://exercism.org/ with new languages to get a grasp on syntax and see examples that other people have submitted.
It's far from a true comprehension of the language, but it is really helpful to tackle problems that I've already done a few times in languages I am more familiar with to help relate concepts and highlight the differences.
I use it to get familiar with various concepts and idioms in languages I don’t know at all, and also for ones I feel comfortable with, where there are parts I’d like to understand and perhaps use in future. It’s incredible!
I've remade missile command in every language I've learned except COBOL (and node if you count it as distinct from Javascript). Not actually a programmer, electrical engineering (larger electrical gear for Datacenters).
It's also a nice touchpoint to look at general personal improvement at programming, since it's right at the point where it makes reasonable sense to use organizational schemes like design patterns and needs adapting for whatever language you're in. The first time I made it in high school was an utter nightmare that somehow printed to over 20 pages (I know better now), ended up multithreaded (early 2000s Java multithreaded), lacked many features like pause/titled screens, and had a memorable race condition where explosions could only start in pairs if they were both visible (so reserved top left of screen for that second explosion).
I’m a backend dev. To learn a new language, I’ll make some CRUD app with REST endpoints with some form of authentication.
I’ll pick the popular web framework, database library, json library, etc. and try to build it. I might even look at logging. This will help me expose all their popular libraries and features that’s relevant for my day job.
Plus Auth and publish and you will probably get followers. Annoying how many new things disregard Auth then CRUD is where 90% of monetization has existed on web to date.
Can you explain what you mean by publish? I'm assuming you mean publishing content (as in releasing learning material like a blog post or video tutorial) but some people as refer to publish as publishing (creating) events with an API.
I have a f1 news aggregator that I rewrite every time I learn a new language/framework. Over the years it has had a web frontend and also a mobile app.
Has a backend that consumes RSS feeds and builds a database of articles, a REST API that exposes articles, a web frontend that shows them, an iOS frontend that shows them, and an android frontend that shows them.
I've rebuilt every part of it multiple times in many languages - it's a project with reasonably constrained scope so you can usually implement any part of it inside a day or two, but it solves a real problem - I use it day to day to keep up with F1!
edit: I think the scraper is currently a .NET core 6 console app, the REST API is I think python, the frontend is pure JS, the iOS app is swift+swiftui, etc. Lots of variation.
A rougelike dungeon crawler. It allows me to kick the tires on most new languages that I want to try out. In order to get going with it I need to figure out:
- What can I use to display? Is it a native app interface, TUI, web based display?
- What do the collections look like in the standard lib and what operations can I do on them?
- How good is the multithreading/multiprocessing?
- What paradigm is the language in? (OOP, FP, procedureal, etc)
- What developer tooling exists for the language? Is there an LSP available if I want to use emacs/vim/vscode? Is there a plugin for IntelliJ? What's the debugger situation look like, or am I going to have to use print debugging?
- How does project/package management work with the language?
- What is the echo system like for the language
All of that is in service to building out the first bits of the game.
I was surprised this isn't the most popular answer. IMO programming a complicated game such as a roguelike can get you a very well-rounded knowledge of a language.
But what makes RLs absolutely ideal for learning a language is that you will get your first version running with an extremely minimal amount of code (and no other resources), and you build up from there. It's very strongly motivating.
I build an Abstract Syntax Tree (AST) and usually something with a fluent interface that builds a query. I find this helps me understand the nuances of interfaces and inheritance in a given language and I’m generally interested in the problem so I tend to get far enough to really learn something.
It also helps to practice breaking a problem into steps as an AST is structured in such a way as to encapsulate distinct behavior within a node. Often this will result in using something akin to the Visitor pattern and this helps you further separate behavior from form.
I am a full stack senior dev, work often in Go or Node/JS when building services and React/JS when building front ends.
To learn Blazor and CQRS I coded two interactive planning poker and retrospective applications in Blazor - right at the beginning of the pandemic so that came right on time when working from home. I installed them at my work and we're still using them:
For languages, I usually write something that generates data, saves it, retrieves it, puts it in sqlite, processes it, reports on it. Boring, but it makes you implement some basic data structures, loops, logic, organize code into functions/classes/actors/whatever, deal with i/o and output. It's boring, and takes a day or two, but when I'm done, I usually can code reasonably well in the new language pretty quickly - but mastery of that language can take years.
Over the years, trying to learn different languages/frameworks, failing most of the times and succeeding occasionally, I have found two things that help me:
1. Find an interesting project that suits the language/framework and keep the scope very minimal so I can complete it in 2 days (weekend). I can always learn more doing a second or third project. But I find that I can maintain my motivation when I see results and complete a project.
2. Restrict the number of new technologies for the project to maximum two (best if it is one). When there are many new things, I find that it can be exhausting and I give up after just a couple of hours. So for ex: When I initially learned React, I didn't know GraphQL, so even if I see a case where GraphQL might be the best fit, I will use REST API. This way I'm not stuck on all fronts.
To answer the first question, there is no single project I build to learn every language because that becomes boring for me. I try to build different projects every time.
For ex: When learning React, I built a HN reader, Foreign exchange meme reaction, and an app where I can see the time of all my teammates spread across the globe (all completed and live). When learning ReactNative, I built a small Twitter clone (haven't published it).
I make a little web server that upscales pixel art. This project allows me to test out how well file i/o and image processing libraries are implemented. Go and java are very pleasant in this regard.
My "hello world" project is almost always Conway's Game of Life, and I try pretty hard to follow the idioms of the language when I do it.
I like Conway's Game of Life because it's easy enough to not be too frustrating, but challenging enough to where you actually have to think about the problem a bit, at least if you're planning on following language idioms. Usually I just "render" to the command line, though occasionally I will get ambitious and figure out SDL or OpenGL bindings.
Admittedly most of my projects involve servers in some way, so after I've done the Game of Life, I usually start playing with the networking libraries like ZeroMQ and the libraries to call command-line programs, and I make a distributed video processor using ffmpeg.
automating the game I'm playing right now with plain old input simulation + image recognition.
This is how I started my career in the first place as a software engineer and this is how I continue learning new languages w/o the feeling to artificially build something useless
I usually start like that:
- add a mouse/keyboard emulator library, on the way you usually find out how good native system integrations are and how to integrate dependencies into your project
- write a brutally easy script of some mouse clicks/movements or similar to have something in place you can build on
- generalize the script
- make use of basic code features like functions, code logic, abstractions
- maybe add some math for screen resolution independent mouse movements ore more natural movements or typing events
- have some basic idea of concurrency by waiting a random time before input events
- how about adding openCV or a similar screen capture tool? now you can capture a single color indicating a specific event to make things more interactive
- get more creative in what you want to detect
- figure out what are the limitations of the language of your choice, how many fps can you archive and what are the bottlenecks?
- when you are at this point you opened the door to an endless journey of adding more and more features and optimizing your code
the first steps are often just c&p from stackoverflow + some basic lookup from the documentation. with this approach you have a working prototype rather quickly and you are in full control on how fast and in what direction you want to go
by the time everything feels repetitive in what you are doing you probably already have a basic idea of the language and can decide on how or if to continue.
needles to say, don't spoil yours and others fun by applying this approach to PVP oriented games. also you will probably have a hard time since there are way more efficient ways + anti cheat tool will detect you
1. An implementation of Fisher's exact test for 2x2 tables. This adapts the algorithm from R's fisher.test() function, which was implemented with function closures for optimisation, which does not always map well to other languages.
2. A foreign function interface to the Rmath library. I have now done this for Standard ML (MLton, Poly/ML, Moscow ML, MLkit, SML/NJ, SML# and Manticore), OCaml, Ur/Web, Mercury and MonetDB. Code generation sometimes uses cpp, m4 or the language's tree and string facilities.
3. Discrete event simulation using message passing with an application to cost-effectiveness analysis. Someday, I'll get this published.
I'm a full-stack Rails dev and I have two glacially slow learning projects going on: an early-facebook clone to learn Elixir + Phoenix and a macOS timesheet app to learn Swift + SwiftUI.
Both stacks are totally great and enjoyable btw, would recommend.
When I first meet a language I usually crack open the docs and then write a single micro project, like a BFS maze solver or a knapsack problem solver or something Advent of Code-esque, just to get to know all the primitives quickly -- different kinds of variables, arrays, dicts, control flow, closures, error handling.
For me, I screw around building something, but then “settle in” when I write hardcore unit tests that shore up my knowledge and reinforce my understanding of the language or framework.
Until I do that, and I mean truly do that, I am prone to all sorts of surprises when running my code and have little confidence.
Most recently I’ve done this with fp-ts (a functional programming library for typescript) and a wrapper around hledger (a plain text accounting app). Because the later is Haskell, I figured I might open myself up to a rewrite at some point in the future.
I usually code standard library functions in it. So implementing functional stuff like map/reduce, implementing data structures like lists, implementing string utility functions etc.
The goal is to learn how to create abstractions and how control flow works, once you got that down you can think freely and just code whatever you need.
When learning a new API just implement some basic program in it, taking input in some way and creating output in some way. Like click button to display a text, or take command line argument and write a file saying hello world etc.
For me it's usually rebuilding a solution to a problem that I understand well that I've already solved with a familiar language.
Take for example Git. If you understand its internals well enough to build it yourself, then rebuild git in the new language. In the future, when you want to pick up yet another language, rebuild it again.
One of the reasons that I think it's extremely useful for a programmer to have at least one complex system that is well understood and implemented under their belt.
I usually wait until I have an actual project need then dive in, googling syntax questions along the way. If I do a made-up project then never apply the learnings, then the knowledge will just slip away and I'll probably have been wasting my time. I've committed production code in languages I don't know more than once. They're all kinda the same.
I'm a backend developer and one project I've written a simple HTTP server a few times in different languages. I like it because it's not too complicated but at the minimum you're exposed to the string processing and synchronous IO features of the language, and if you want you can do things like write an async server or multi-threaded server.
Something that I, or someone else, can and will use. Toy projects bore me, I like having something that actually solves real problems be the result of the time and effort I put into learning a thing.
Every once in a while, I'll think "it would be nice if I could do X" and that's perfect project material that will keep me motivated.
I try to develop primitives for data structures and/or algorithms - starting with e.g a doubly linked list node / binary tree node… moving on to e.g. breadth first search implementation, etc.
Being older, for me this has the benefit of refreshing some compsci fundamentals while exploring the new language.
Backend web dev for the most part these days. Trying to simultaneously learn a language or system and produce something deployable has been a huge headache for me. I prefer to learn something new by starting at the beginning, with small exercises and study until I'm fluent enough to work on a real project without making bad mistakes from ignorance. The other approach, which everyone seems to expect, seems like madness to me.
If you're a good pianist and you have to learn the violin, I think it's best to start with scales and arpeggios just like any other beginner, except you go faster because your existing knowledge transfers to the new instrument. Trying to make your way through Beethoven's violin concerto starting on your first day with the violin seems to me like a ridiculous approach.
I see. Maybe some Euler problems? There used to be a good site called rubyquiz.com that had nice exercises that were less math-like, and that (mostly) worked well in multiple languages. Rosetta Code might be another such place. Or just think up your own.
There are two issues as I see it. One is to be able to code something that seems to solve your problem. The other is being able to code with reasonable surety that you haven't committed some subtle error that will bite you if you actually deploy the code. You need deeper fluency for the latter than for the former.
Fastest way I learned was to rewrite an app I was intimately familiar with in the new tech.
e.g. I wanted to move from Flutter and Firebase to Fullstack JS. So I rewrote a 20k lines app in NextJS ( typescript and everything I wanted to try out ).
Not the best way to go if all you want to learn is 1 piece of technology though.
I'm almost finished my first backend implementation of https://github.com/gothinkster/realworld and now that I've implemented it once I'm very familiar with it and could very quickly implement it again.
It's simple enough to be a short project, but with enough complexity to get you familiar with a wide variety of things you might care to know. One thing I like about it is you can kind of under or over engineer it as much as you want as a way to turn the dial either up or down on exactly how many different aspects of development in a certain language/framework it exposes you to.
3. Write a static site builder. This means I need to learn how to bring in libraries / packages, do some Markdown processing, do some templating.
4. Use a web app framework for the language to build a simple site with minimal interactivity, just to see how the language helps support the framework. I avoid client side (JavaScript) where possible as I don’t like working in that area.
5. Try building a couple of simple non-web GUIs. Buttons and lists, callbacks etc. Learning Swift meant doing quite a bit of this. Learning Python - just some messing around with PyQt to see if it’s fun and easy.
Not a dev, but used to be. These days I play with dev tools for fun, to spike stuff that might be good at work (mostly AWS based) and the occasional personal project.
A long time back, for me it was Wolfenstein-style 2.5D rendering. I first wrote it in Perl 4 - MacPerl using quicktime (quickdraw?) on a pre-OSX Mac (System 9 probably). Just a "move around in a space" type demo rather than a game. The "2.5D" referred to the tricks that let you go up and down stairs/ramps, but you could never go above or below another navigable space.
Rewrote it in at least Java (applet and standalone), Z80 assembler, Pascal, PHP, Python, JavaScript, C - and from memory gave up and failed to get it working in 486 assembler and 68k assembler.
It's been at least 10 or 15 years since I tried. Maybe I need to see if I still have the chops to get it working on Arduino or RP2040 or something...
I tend to try to work on a project that I have a personal need for. Currently I'm working on a budgeting application. My background is primarily in Desktop application development (C++ Qt, C# WPF, OpenGL, etc) in the games industry. For my budget application I chose to use Python as it's easy to do the annoying bits (string manipulation, filtering lists, serialize/deserialize json, xml, csv). I recently hit a point where I wanted to send some transactions to my wife for review and decided it would be useful if it was web based. Good time to learn some Django, which I did.
Having a young kid helps to keep me focused while I'm coding as I know my free time is very limited :)
First thing I do is looking for ways to execute machine code.
When that fails, because there's no non-exploity solution ... I drop it.
Otherwise, next, I look for easy multithreading.
Then I look for ways of plotting pixels on an easily available canvas.
Then I code an effect.
The last new language I've learned was python. For that one it was different. With no experience in python specifically, I've asked the friend, who recommended it to me, to give me a problem and I'll code him a solution.
I'm an autodidact and generally don't like using tutorials, papers and whatnot. Google is all I need. He wanted a webscraper ... and two hours later, after lots of fiddling around figuring out how the language works, I was done.
I really like building Conway's Game of Life. It's big enough that each time I still have to think about the solution and how to build it, but small enough that it allows me to recognize patterns and differences from a language to another.
Came here to give this answer.. it’s not an entire way to learn anything but it’s a good start and flexible enough it can actually apply to pretty much any new tool or tech component you want to learn… can do database or vitalization or most things it can think of can adapt some aspect of it to work with life as a simple toy problem. I think I discovered my favorite functional version of life adapting game of life to Apache Spark to find a way to describe the next state from current in a unified way without conditional logic or something, though memory is fuzzy as I never did spark again and it’s been 7 years now…
Also second someone else’s suggestion of Exercism.
Apart from the languages that were taught in college, I've never learnt a language or framework in the 'abstract'.
I learn a new language/framework while trying to solve a specific problem. The latest I picked was Nodejs/Vuejs/Electron while building https://nocommandline.com. A year ago, I basically had zero to little knowledge about them but now I know a whole lot more.
Also, I'm not a professional developer. I'm a Product person who basically writes code to solve specific problems I encounter (at work and outside of work).
For learning a new language, I've enjoyed code golf problems. You are unlikely to use any of the same syntax/approaches in "real-world" applications, but it gets you to use the compiler/interpreter a lot and you learn about all different parts of the language.
For a project though, I think anything that you know the domain of really well and are interested in so that you are happy to complete it/go back to it makes sense. I find I often like to build some sort of crawler (APIs or page data) that can then be consolidated and distilled into concise information.
I’m a web developer, but I mostly work on foundational/common middlewares and libraries, and research distributed system patterns for API developers to use.
I have a CLI app that I make that calculates microtonal pitch lattices. In a lot of languages, it ends up being a few hundred lines. I’ve done it in Rust, Clojure, CL, Scheme, Python, C#…
As far as frameworks go, I’ll reach for one if I feel like I need one. With web frameworks, I’ll do a GET and POST route to get a feel for the mechanics.
After several years of going in deep on the JS hamster wheel, I’m kinda done with it. I’ll jump into a SPA framework if I need one.
I'm a frontend dev, but I don't learn anything new unless I already have an idea for it. Currently learning swift because I want to figure out how to many menubar apps and integrate with third-party apis.
I enjoying writing Netcat clones when learning a new language (or even a new paradigm in one I already know). Netcat hits a lot of interesting areas like sockets, error handling, and threading/concurrency.
I like using codewars.com for learning new languages. Just pick a language and start running through problems. I think the best part about it is that you can review other solutions after you solve the problem. Usually there are some really clever solutions that show off the features of the language, as well as clearer solutions that are a bit more idiomatic to the language and more in line with what you'd want to commit to production. For learning frameworks I usually just refer to the framework documentation and source code.
Dice games, generators of random structures, REST servers, small compilers.
I mostly learn domain-specific languages where the use-case is more given.
With Ansible I created scripts for bootstrapping VPS'es and laptops with dot-files and some suite of default programs, scripts for hardening OpenSSH. For jq I went to IRC and StackOverflow and tried to solve other people's jq problems. Many years ago when learning regex, I'd solve a regex quiz.
For front-end web-frameworks I usually create a tamagotchi or a questionnaire.
(I mostly do back-end, compilers and DevOps, but I'm full-stack.)
Depends on the language. Since this year I am getting up to speed with JavaScript and TypeScript, and there are a lot of different notions around to learn. It really clicked for me just recently when I implemented my own little unit testing tool (https://www.npmjs.com/package/instatest). This touched many aspects of the ecosystem I needed to know about, and was yet pretty simple to do.
Usually I find whatever web framework the language supports. This usually tells you a lot about the language, like if it can hide some of the ugly details behind powerful features or if you get to see it all (nothing wrong with the Go approach of 0 magic), basically everyone can open a browser and see immediate feedback. I also like to see how responsive it is and all that.
It also lets you evaluate any database drivers, which are one of the top 10 things I want out of any language I use.
Crypto trading bot. Websockets, http, async stuff, some light crypto for authentication, database or redis access, some math. I feel it hits on so many points.
I write 2...3 things over time: a photo copy tool that organizes photos off a camera card, a simple TCP server that spits out "Perhaps bonghits will fix my make file" or something similar, and then some kind of library, usually something that involves another library.
When exploring a library or domain, I generally go for something I can glean from examples, usually gluing two of them together.
A text adventure. Touches data structures, parsing, data representation. And then you get to have fun picking up the lamp and dropping it somewhere else. :)
That strikes me as an excellent idea: it’s a pretty small tool, but it is useful and has just enough complexity to test the language and its standard library. Note, however, that I have not done so myself!
For practicing low level code and sometimes exploring APIs like drawing graphics, I like doing https://adventofcode.com/; I mean I say I like doing them but I haven't touched them in a while lmao.
But yeah, 'hacker' exercises are a great way to get acquainted with low level code.
I pick interesting or semi-relevant problems from https://codegolf.stackexchange.com. And if you look at other answers you'll learn a lot about the syntax and (unique?) features of the language. Not that you'd ever submit such programs in a professional setting.
I always write the same app in any new language I learn.
For me, it's a web scraper that parses a forum and saves posts/comments/attachments into a db, but the exact project is unimportant.
After the first few languages, I don't have much to discover about the app itself, so I can focus on how the language allows me to express my app.
I usually try Advent of Code (https://adventofcode.com) every year with a new language I'm interested in. So far it's allowed me to get respectable knowledge of:
- Go
- Rust
- Clojure
Hoping to try out Elixir for this year.
I also sometimes build Conways Game of Life in a new language for fun.
I have a parser (FIT binary data format) that I've written a handful of times, probably 9 or 10 at this point. I find that file parsers usually provide a decent tour of the language, it's standard library, and sometimes it's ecosystem. Takes a day or three. For comparisons sake, my first go at it was in C and it took a month.
I've ported this Boulderdash clone 4 times. It's arguably not a good way of exercising a language as it's pretty trivial, doesn't use any data structures or other interesting language features
I'm a fullstack web developer. I know "some" devOps. I also develop for mobile but mostly via port frameworks like Capacitor.
I usually build something that'll be easy and can be built in a weekend. Like with Phoenix, I'm thinking of building a multiplayer app since that's the best usage for this specific framework.
If it's a new language, I create a small CLI poker game. It allows me to feel out most of the important parts of a language, as well as how ergonomic it is.
New framework, usually a small wiki with a custom markdown parser. It lets me get dirty with routing, the database, rendering, user state, and injecting custom code.
I used to start with https://www.reddit.com/r/dailyprogrammer/
I would find one that had solutions in my target language but not peak at them until I finished my attempt then compare.
I previously built side projects with a real idea for an app like a social media app for example. In the future I might focus more on just leetcode type questions in the language for hands on familiarity. The right thing for each person just depends where they are in their technology journey.
I guess that depends on what I am learning it for, I am set to learn Elixir next, and that is because I want to use Phoenix, which means I will be building a website project in it.
I'm pretty old so I've been lots of different kinds of devs, last 7 years generally full-stack - heavy frontend focus.
It depends on the reason to learn a new language. Once you know a few languages, you generally only learn a new one if you are trying to solve a specific problem that it can do better.
What I try is to solve a small piece of the problem I am trying to solve to get more familiar with it before committing.
I've got pretty good experience with both, so knowing the algorithms is helpful. Where it gets harder isn't the language itself, but usually the idioms for expressing certain concepts.
For example, Rust doesn't have default parameters, so the builder pattern is pretty common.
I do a variety of dev, web, native, backend, embedded. I don't code a project, I mostly just play with the features and try the variations to make sure I understand them. Once I think it's a good option and does what I need, I just code the actual project
Backend dev. I enjoy implementing UNIX shells or simple lisps. Sometimes I'll pick an RFC I also want to learn about and implement that protocol as a client / server / both.
The daytime protocol. Sockets, concurrency, date formatting. Gives me a good idea for standard library friction. If this is hard, other more complex programs will be harder.
Whatever is in the tutorial. Or whatever my day job needs it for - because that’s the only reason I would learn a new programming language or anything related to programming.
my classic is an mbox filter. Read a mailbox, determine who sent it and when, and rewrite an output mailbox with different filter conditions applied (e.g., only mails from nigerian princes, only mails younger than a month).
determines for me how file I/O, error handling, indices / data structures pointing to messages work, sorting, etc.
When I tried to do that with typescript, I realized that I was just writing garbage JavaScript. No incentive to really learn any language features for leetcode.
Looking back at the past twenty five years, I've definitely learned a few new languages and some of them well. I've also failed with a few languages in the sense that I gave up, lost interest, or did not follow through with them.
First learning languages is both hard and easy. Mastering the syntax is typically easy, with the exception of languages that are just really complicated (Rust, C++, Scala) and "weird" in the sense that they just are very different from what you might know. But what is hard is absorbing the idioms and familiarizing yourself with enough of the frameworks and libraries that you need to get stuff done. That requires investing a lot of time.
Rust is the one that got away for me. I'm interested in it and appreciate what they are trying to do with it. I definitely sacrificed some time trying to shoot through tutorials, and tinker with it. But it just never happened. It took too long to get productive with it and I had no real business reason to pursue it.
All the languages I did master, there was a business reason and opportunity combined with an attitude of "how hard can it be?". That's my default attitude and you get surprisingly far with it. It's a naive form of deliberate arrogance. If you allow yourself to get intimidated by other people's code, it becomes an obstacle. I'll typically get dragged into some project with existing code and I'll just start making small changes and google my way through solving basic issues and try to figure out what the existing code does. The more you do this, the easier it gets. Just figuring out how the code works, how it is structured and why it is the way it is means you absorb things quickly. Ironically, bad code bases are easier to deal with as you don't get stuck assuming things are correct or even done properly. Just tinkering and fixing code like that is usually not that hard. Make a small thing a little better, repeat.
Some examples:
I learned Kotlin by simply using the Java to kotlin converter in intellij for a backend project. I had read about the language and had liked it enough that I just sat down and started doing it on a Friday afternoon. I started with my main Java project and converted a few tests. Two hours in I was sold on this. It was just too easy and I liked the code that came out a lot better than the original Java code (less verbose) and my tests still passed. A week in I just decided to go all in and convert any Java code I dealt with to Kotlin. Being able to go file by file and class by class really helped me here. It barely slowed me down. 3 months in I had tens of thousands of lines of code converted and I started getting good at it. That's now five years ago and I no longer deal with Java and maintain several kotlin OSS libraries. It's my main language.
Example 2: I inherited some frontend project written in Javascript. It was a messy code base and it was now my problem to sort out. After mastering enough Javascript to work with the code base to make simple UI changes (it's basically just Java minus a lot of features), it dawned on me that I needed to up my game to be productive enough to do some major feature work on that project. When you have a nice code base, doing more of the same is a good way to do this but this code base was so messy that that was just not a viable path. It needed to be fixed, and I just needed to figure it out properly and I could not start from scratch and had to keep the UI alive at the same time.
So, I started upgrading it to typescript to fix it properly and introduce some level of sanity. This was a really messy JS project (as a lot of these projects are) and I needed to get past the constant "WTF does was this even supposed to do" stupid hacks that I was constantly fixing and dealing with. This was an iterative process of figuring out what the original javascript did and why and then doing it properly in typescript. So, I was effectively learning two languages at the same time.
Typescript is very easy to master. Like Kotlin, this is by design and as mentioned, I like things that have a compiler. So same process: just start converting existing code by changing the file extension to .ts. The typescript compiler helped me fix numerous obvious issues by simply chasing down warnings and annotating things with types and introducing some structure. Over the course of six months most of that js code base got converted and fixed, rewritten, or discarded and I got quite productive with it and was able to add major new features. It was still messy but at least it was my mess and I could work with it. Typescript and kotlin are very similar of course. Would use it again but I actually prefer kotlin-js lately.
I've dabbled with Php, Go, Scala, Python, and Ruby projects as well with different customers and while not my main languages I can work with code-bases for any of those languages and have done some productive things with all of those.
And in the distant past I came across C, Gopher (a haskell predecessor), Self, Smalltalk, AspectJ, prolog, lisp, and a few other languages. Basically, the hardest part is not the syntax but wrapping your head around different paradigms like logical programming, functional programming, imperial, and OO. It's not about things being better but about things being different and appreciating different ways of doing the same things.
The whole idea of implementing something useless to learn a tool is deeply flawed and it is sad that most of our schools and universities still follow this practice
Some of us just really like digging through raw Martian Elevation data and turning it into models or textures or whatever. And learning a new language while we’re at it is a nice (intended) side effect.
If we could just “learn the language” cold we would. By all means, if you have something “useful” you need to do, prefer that. But we don’t always have that on hand, and fun toys are a good substitute.
Graphics? Check. And simple, top down, tilesheet or character maps work just fine.
Battles? Check. You can leverage anything from purely functional, object oriented, websocket, long polling, SQL, you name it. Whether you use 3 elemental types or flesh out everything from multiturn, semivulnerable, exp/leveling, it's all up to you.
Wanna just build an REST/GraphQL/gRPC API? Or a UI? PokeAPI is an opensource database of nearly all game data from moves, items, and species.
Pokemon is an endless, any-scope, extremely documented, opensource-rich field of exploration.