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.
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.
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.
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.
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 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.
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.)
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 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.
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’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.
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'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.
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 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.
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!
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.
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.
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.
170 comments
[ 3.1 ms ] story [ 194 ms ] threadIf 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.
Also: If I do not immediately have enough paid work, I brainstorm a side project which could feasibly use it.
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 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.
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.
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 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.)
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.
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 example, I had some ideas for adding interactions/animations to some charts and used it as a chance to try out Svelte
It’s quick but it covers string handling including some weird stuff, sockets, and networking pretty well.
I even do this with GUI programming as it involves callbacks.
https://github.com/druid628/hpHack/blob/master/hphack.c
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.
Then I move on to more complex parsing of text in the file.
I try to get this building cleanly and working on Windows, Mac and Linux.
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.
my problem is: how to keep 3~4 language 'warm' at all times? write some code daily on each?
Then you can swap out all the python/njs/js frameworks to your heart's content.
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.
"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."
Also second someone else’s suggestion of Exercism.
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.
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.
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.
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.
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.
Then I made an effect. It was slow. D'uh. :-)