The sleep trick is something I do with my hobby projects all the time, without really deliberately coming up with it as a strategy.
By the time I get the kids in bed at night, I'm often out of steam. Sometimes I try to make some progress on a project, but I usually don't have the willpower to push through a stumbling block. After many many nights of staying up late and losing sleep trying to power through but not actually getting anything working, I finally realized it's better to just go to bed.
But I also feel sad if I go to bed early without making progress on something I'm excited about. So I started tricking myself by telling myself, "Well, you can just think about the project as you fall asleep." That's usually enough to get me in bed early.
And, lo and behold, quite often, I figure something out as I'm drifting off. Then when I wake up the next morning, I can get it implemented while I have my morning coffee. It's a really pleasant routine.
Hah! I have the same experience. When my children manage to sleep I'm too tired to do anything, so I program and think in computer problems as I fall asleep. I have to get up very early to work, so I don't have the chance to put them into practice the next morning (unless I thought of something related to work), but at least it helps a bit to cope with frustration and sadness ;)
Notebook by the bed helps. If I have an idea while drifting off, there's sometimes a concern that it'll disappear by the morning and that stops me falling asleep. So I write it down.
We did a similar assignment at University many years ago. I think it was the same assignment, one per day for two weeks. Each time in a different language.
The goal was to see how similar code is, and how little it matters which language you pick.
Obviously it's a constrained problem set (we didn't have to learn all the ins and outs of each language) but it really opened our eyes to the "commonness" of programming, and free'd us from the tyranny of "I program in x".
"The goal was to see how similar code is, and how little it matters which language you pick."
I think this thinking is a mistake. If you learn languages superficially, you will end up writing the same code just with slightly different syntax. It can take a long time to really understand a language and ecosystem and use its capabilities.
Curious which languages you used. If they were C, C++, Java, and Python then I could see how they could blur together if you squint. Different syntax, similar semantics.
But if those languages are C, APL, Erlang, ML and Lisp then I would expect the lesson would be the design space of languages is much larger than the popular imperative languages would have you believe.
Sure, but in university that can be a useful exercise, whatever the language. There are many commonalities in just about every language. Learning your first language is hard, you’re second is freeing. At least personally I’ve found that the more languages I study, the easier it gets to pick up a new one, specifically because of the commonalities. Sure, Haskell and Ruby are really different, but when you try to pick up Elixir you’ve got a lot of common ground.
Languages like APL, Forth and Prolog are different enough that this wouldn't apply until you learn another array, stack, or logic-based language. And with languages like Smalltalk or Lisp, learning how to use the environment will be just as challenging.
APL might be an outlier here. For the rest, I think the difference lies more in the standard libraries of those languages than the languages themselves. Yes, differences in core language design start to matter when you are considering performance, or structuring larger applications, but for simpler scripts, you're mostly dealing with the standard library.
On the other hand, differences will start to show them selves after you spend a while noodling with your script, refactoring it a couple of times and deliberately seeking out opportunities to use language-specific features in the process. This expands the exercise to something more like "a language a week" instead of "a language of day", which is obviously a bit more of a time commitment. But if you want to get value out of a "polyglot" programming exercise like this, I think that's what you really need to do. Otherwise I think you learn lessons that are only correct at surface level.
Erlang doesn't have loops. You've got filter, map, reduce, and recursion. It's safe to say for most programs that your Erlang solution is going to look rather different than your ALGOL family one.
And Java didn't, until relatively recently (oh god Java 8 was almost 10 years ago), have anonymous functions, which means that you'd be more inclined to express solutions in terms of vulgar loops rather than a map, filter, reduce type operation.
Which is to say, they'd definitely look different.
Right, and you can implement a recursive function in Haskell, OCaml, or Scheme that looks more or less identical in all 3 languages, and is only a recursion-transformation away from the for-loop version seen in Python, Ruby, Java, etc. So all the functional recursion-based implementations will look similar, and all the imperative loop-based implementations will look similar, and the two classes of implementations will also have a lot of overarching similarity.
The basic pattern of "obtain system state, do thing, set up next system state, proceed to next thing" is the same. The differences between languages (read: sets of tools that you are given for expressing algorithms) tend not to become apparent until you've spent a little while working with them.
I can't speak specifically to Erlang because I haven't used it, but from what I've seen the story should be the same.
The semantics of a language shape its use in practice, though.
For example: If you're in a language that primarily uses recursion as the primary iteration mechanism, if you have to iterate through every element of a tree you will just about never do a breadth-first search unless it is absolutely necessary. It's just a pain to express recursively compared to a depth-first traversal. In contrast, in an iterative language, a breadth first traversal is the same (somewhat obnoxious) complexity as any other traversal. But that's assuming both languages would be traversing a tree at all: trees are vastly more likely to be used at all in languages where recursion is the norm.
Like, sure, any iterative function of the form:
f(x) = {
state = h(x)
cond = true
while(cond) do
state = j(x,state)
cond = k(x,state)
end
post_work = l(state,x)
return post_work
}
Can be re-written as
f(x) = l(m(x,h(x)))
m(x,state) = state if k(x,state) else m(x,j(x,state))
But if your language only supports one or the other, you're going to approach the problem in fundamentally different ways. Whereas the iterative solution is likely to jump directly into the loop with a trivial h(), the functional language is far more likely to do more work in h() to offload work out of j() prior to what would likely end up being a fold operation.
Put another way: for(i=0;i<x;i++) loops are common in iterative codebases I've worked on, but it's exceedingly rare to see f(x,i) = blah return f(g(x),i++) in a functional codebase.
Even for a one day task it seems language choice could make it much easier or harder depending on the nature of the task. Text formatting and parsing, vector/tensor math, parallelism, network io, all those things vary drastically in difficulty depending on the language chosen. Then, if there are any performance constraints on the problem that is another clear discriminator.
> The goal was to see how similar code is, and how little it matters which language you pick.
I think that’s a pretty bad result of the exercise. The point of software isn’t just to do a thing. Good software should properly encode a domain or idea and communicate that to others.
If one took the analogy of driving a nail into wood, there are many tools that can do the job, but only a couple that properly handle the job. Because the goal isn’t to just drive the nail, it’s to do it efficiently and ergonomically and in a way easily communicable.
You can write good software in almost* any language though. Encoding of domain and/or clear coding style is mostly orthogonal to language syntax. The OPs exercise is exactly to show that language choice is not all that important, since you can write good software in bad languages and you can write bad software even in the best languages.
* Excluding some deliberately opaque languages like brainfuck and malbolge.
I would describe programming languages less as encoding problem domain, and more of encoding/enabling solution domains. For example, if you're in Java the language steers towards defining objects that have methods that express your solution, where as in Haskell you'd be more inclined to your solution in terms of a composition of functions. At a lower level, your Java program is more likely to use loops and iteration whereas your Haskell program is more likely to use a recursive solution.
Anyone who's tried hammering a Java-shaped solution into an Haskell-shaped language will eventually see the folly.
I think you read a comment that they didn’t write. But to take your argument there is still value there. Learning that the goal is to get the nail into the wood and give you a tour of some ways to do that provides different value to practising your memorised best practise of 3/8” 95% iron alloy hammer swings at 20 degree arcs 1.2 times per inch of nail bed. Maybe that’s valuable too but you need to know both.
I interview a lot of programmers and I often get told that one of my questions is just impossible because it’s slightly awkward to express in Java. (It’s only Java folk incidentally, even though it’s roughly equally awkward to express in most of the long list of languages we let candidates use.) By analogy these are folk that would have to sit around waiting for their hammer delivery rather than just make do with a mallet for a few minutes.
Even with the latest java? With records and switch pattern matching on records, you can model some stuff better. It's not as good as pattern matching in other languages but getting better.
I agree with your point though. I remember being asked a question and I blanked with how to model it in Java. Then I switched mid interview to python and it clicked for me.
Most languages have completely different idioms though. Sure you can write functions, loops, if statements the same in dozens of different language syntaxes, but that doesn't prove anything. I've seen loads of codebases written completely backwardly, eg when a C++ programmer writes their first Python app or a Java developer writes Javascript - they're just writing the same style in a different language, not writing idiomatical correct code as a Python or JS developer would.
I missed blogging too, so I set a New Year’s resolution in January to write at least two blog posts this year. It had been over seven years since my last!
I still hadn’t written one by November, but now I’ve got three for the year.
I've asked my team at Amazon [usual disclaimers] to read this, and highlighted my favorite takeaways: "Well-timed sleep was probably the most important thing I did", and "Using sleep to do the heavy lifting on algorithm design". I love this concept, and need to incorporate more of it myself.
I have been reading Matt' blog for quite long too. I read his post on his son condition but never really noticed if he really switch his academic careers for his son. I am pasting the really motivating video sharing the story [1] and a NY times article here [2].
Can you explain why? What relevance does his wife's stay at home work have to someone else trying to get tenure? Do you think he doesn't appreciate his wife and that rubs you the wrong way?
Learning a programming language in 1 day to solve a particular problem isn’t the same as learning it over years to write actual production code. I doubt the author was writing “idiomatic” code and he probably transplanted paradigms from more familiar languages in the newer ones.
But it’s still very useful and I’m sure he learned a lot and absorbed of some of the new languages’ programming styles. You don’t master idiomatic functional programming from one week of writing Haskell, but it does introduce you to basic concepts like functors, lambdas and embedding computation (IO) in data.
For what it's worth, the author is well-known in the field of programming languages and was a professor in that area at the University of Utah for a number of years before changing life focus and relocating to the University of Alabama's Precision Medicine Institute.
Which isn't to say that you're wrong, but rather that the author is likely well aware of these particular shortcomings of the exercise. But then the exercise wasn't "write perfectly idiomatic code in a different language every day", but just "learn some languages I didn't know before".
Definitely true (not that should stop anyone, little projects like these are a great way to get exposed to other languages).
From my personal experience of doing AoC in Julia this year, my Julia code started out smelling a lot like Python, but managed to adopt a bit more of the Julian way of doing things as I went along (not done yet though...)
That's really cool. It's basically a good way to practice multiple languages to see what you might like; and without an Advent of Code, I've used over 20 languages myself. I'm sad Nim wasn't on his list: I've started using that lately, and find it to be useful.
I have to say I still haven’t really figured out how TeX works, despite using latex for years. I can’t even do a for loop or simple arithmetic or find the size of an array, let alone implement complete algorithms. Is there anyway I can learn this?
Great way to get experience with a bunch of languages quickly! It's not like you'd put these languages on your resume but you can gain a sense for what each one is like/how easily you'd be able to work in it for a project.
I likely wouldn't do this personally out of pure laziness but good on you!
In 2018 I did the same thing, but I asked my friends for the list of languages (they didn’t know what it was for) so I ended up with far more esoteric languages: https://github.com/judofyr/aoc2018
In the end I lost the motivation once I only had the “regular” languages left. I was also solving them as quickly as possible (in Ruby) to get on the leaderboard so it was kinda boring to also solve them again later on.
Nice!! I needed to understand some go scripts with work so I used Advent of Code as an opportunity to learn it as a new language and solve the next problem using it. Unfortunately that day's problem was more difficult than the rest so it took me more than a day to solve it, but it was a pretty nice way to ramp up on a new language!
I think I'd have felt the same way up until I learned Rust in 2021, and now I just think "I'd rather solve this in Rust" almost always. Rust might have spoiled me for other languages. But yes, in general AoC is definitely a good way to learn a programming language. Since we probably don't need vast numbers of Rust programmers it makes sense to acquire say, Python, or Typescript or something if you're working in some discipline where programming might be useful but is not your core skill.
The initial headline of your front page intrigued me because I had noticed in surveying my own institution (the one where I studied, both as an undergraduate and as a postgraduate, and where I now happen to work) that while most of the undergrad courses of study we offer that require mathematics include at least an opportunity to program, Medicine does not. I reasoned at the time that the Medics have to cram such a large amount of other material into their brief time that maybe there's just no room to teach them to write code if they are to sleep (in my country they certainly won't have time to sleep once they're junior doctors)
This is what I try to do. I solve them all (or nearly, I did one in Python only this year) in Common Lisp (my hobby language of choice), and the last few years I try to tackle them in a second language (Ada, Rust, Python, C++) up to the point that my time is too limited to do both versions (or where I find the second version is adding nothing to my understanding of the language I'm exploring).
This year I used Python as my second language (still plan to finish) but with a strong emphasis on TDD and property-based testing since I'm already familiar, but not fluent, with Python.
I did the same challenge this year, though I didn't use as “esoteric” languages (TeX… I love it :D), but I've made it more difficult than necessary by using the languages I'm familiar with first, before realizing this might be a mistake… I've written on my learnings on the AoC subreddit[0] and if you'd like to see my code, it's of course on GitHub[1].
I got my 50 stars in Python, but I also did the first two days in Forth because I've been wanting to learn it. Regarding another thread there talking about whether the language affects the implementation, it did for me.
For day 1, I ended up using a pretty different method than the Python code, mostly so I could use what I already knew or could quickly figure out, processing it character by character.
I wasn't planning to do more, but I realize the input for day 2 could be executed as Forth code simply by defining the words for what those input command should do, and then executing the input AS Forth, so it was actually a quick and easy one in Forth.
I can see skipping APL. Also, Rust could be frustrating if you only had a day. It like saying you are going to learn a new sport every day and skipping snowboarding because while you can always kick or throw a ball badly, just standing up and falling down continuously for a day does not actually teach you anything about snowboarding.
Forth would be a good one though. Both simple and different.
It's likely that the professor knows some Rust already.
In which case Rust is a powerful tool to bring to AoC late on because you can afford to take a not-so-algorithmically clever approach and Rust's optimiser will save you.
Take day 16. The professor did it in Python, with which they have some experience. My Part II solution is pretty bad, it's a combinatorial explosion resulting from a search of the solution space with both the elephant and myself trying every option. But, I wrote it in Rust, so this bad solution finishes in five minutes. If I'd written this terrible solution in Python it may have taken hours to finish...
Both Clojure and Rust are not very fast to learn to the problem-solving level. Other languages like Java or C++ can substitute for them. APL probably too hard to learn in 1-day
I'm convinced a moderately intelligent person with good grasp of high school mathematics can learn the entire core of APL in 24 hours of study (which of course is more than 1 day) with appropriate tutoring. Lack of programming experience is a plus.
Yes, I'm willing to tutor a student to test my claim.
AoC is somewhat more difficult, but is it worth a blog post? Especially for a professor?
The stats https://adventofcode.com/2022/stats show that there are ~9000 people who solved all of the problems. Even if a fraction of those wrote a "I solved 25 problems" blog post, there'd be HN front-page material for months.
P.S. I'm somewhat surprised by this community's adoration of AoC and at the same time aversion to Leetcode and/or competitive programming in general. Arguably, many leetcode problems are more interesting (from an algorithmic point of view), are much shorter (although I guess for some, part of the fun of AoC is the elaborate story), and most importantly, have extensive test cases, that require generalized solutions.
> AoC is somewhat more difficult, but is it worth a blog post?
The AoC isn't the blog post; the choice of using a different language every day is the blog post. Does that not seem even remotely interesting to you?
> I'm somewhat surprised by this community's adoration of AoC and at the same time aversion to Leetcode and/or competitive programming in general.
AoC is deliberately a game. It's spirited and fun. Leetcode is a by-product of an interviewing system that worked kind-of well at one company once upon a time, and then everybody decided they needed to do the same thing because that company had a Big Name, and now we have a broken interview process that is — in most practical respects — completely useless.
That's not to say some Leetcode problems aren't good or fun problems to work on, but the website itself was purpose-built to help people game a broken interview process (which has, incidentally, only made the process worse).
> > > Next on HN: "Hello World in 100 languages, in just 2 hour"
> > Hello world is different from solving actual problems in AoC.
> ...
> The AoC isn't the blog post; the choice of using a different language every day is the blog post
This thread started when someone suggested a similar learning project. Would "hello world in 100 languages" be worthy of a blog post?
> Does that not seem even remotely interesting to you?
It is mildly interesting, but in my opinion, not worth a blog post from anyone more experienced than a college student. I think the whole endeavor is silly. I think that learning the syntax of a language well enough to solve one day of AoC is a dubious achievement. You don't learn the language well enough (in my opinion that takes at least several weeks with the language), you don't even get a head start if you were to later start a project in that language, since you saved a few hours at best. The only thing you get, is to brag about it in a blog post. But who are you trying to impress?
> ... Leetcode ..., but the website itself was purpose-built to help people game a broken interview process
I used Leetcode as a generic name, but I don't mean just them. There's lots of platforms that were build around competitive programming, (starting with Topcoder, Codeforces and many others). Everyone is excited about AoC, but very few people spend time on those other platforms for fun.
> AoC is deliberately a game. It's spirited and fun.
Competitive programming problems are just as fun if not more so. Yet not many people here solve these type of problems for fun. Nobody would write the "25 algorithmic problems in 25 days" blog post. In my opinion, most people are excited about AoC because those problems are not too difficult, and anyone can solve a few problems at the start.
> Would "hello world in 100 languages" be worthy of a blog post?
Yeah. Because a blog post is just an outlet for somebody to write. There's no minimum benchmark that needs to be met to be "worthy" of writing a blog post. What a stupid way to look at the world.
> It is mildly interesting, but in my opinion, not worth a blog post from anyone more experienced than a college student.
Again with the worthiness. I have a suggestion: if posts like this are uninteresting to you... don't engage with them?
> I think that learning the syntax of a language well enough to solve one day of AoC is a dubious achievement. You don't learn the language well enough (in my opinion that takes at least several weeks with the language), you don't even get a head start if you were to later start a project in that language, since you saved a few hours at best. The only thing you get, is to brag about it in a blog post. But who are you trying to impress?
So what I'm learning here is that you not only have a terrible outlook on the concept of blog posts in general, but you didn't even actually read the blog post at hand.
The post isn't about the syntax of languages, nor is it about the author's efforts to learn the languages whatsoever. It's about his high-level approaches for planning to solve a known set of problems using a variety of languages. The specifics of the individual languages are unimportant for this sort of post.
I also think it's weird that you think this sort of thing requires a target audience to be "impressed". Again, I think you have a wholly terrible outlook on what blogs are for. People read Matt's blog for his perspective on things. He doesn't need to "impress" anybody, nor is he trying to.
> There's lots of platforms that were build around competitive programming, (starting with Topcoder, Codeforces and many others). Everyone is excited about AoC, but very few people spend time on those other platforms for fun.
Again, an advent calendar is a regular event that many people participate in for fun. The scope of the challenge is well-known in advance, it's a long-but-not-too-long commitment (25 days), and it's a cultural thing to take part in with other people. It also doesn't focus on optimization; it's just whether you solve the problem. Advent of Code also has their leaderboard feature such that individual communities can run their own AoC competitions, which maybe encourages some people to participate (but also does not alienate those who don't wish to compete against other people, since they can just choose to do AoC on their own).
Competitive programming tends to focus on optimization, requires a lot more study and effort, does not occur as part of a regular cultural phenomenon, and so on. They're wholly different endeavors. I don't think there's any mystery to it at all.
> Competitive programming problems are just as fun if not more so.
To you. Some people like that AoC is simple. It gives them something to do. It's like having a one-a-day sudoku calendar on your desk.
> Nobody would write the "25 algorithmic problems in 25 days" blog post.
I don't see why they wouldn't. I think that would be an interesting post. If you're so into competitive programming, why not be the person to write such a post? Or do you only complain about other people's creative endeavors without contributing your own?
> In my opinion, most people are excited about AoC because those problems are not too difficult, and anyone can solve a few problems at the start.
What's interesting to me about the way you've phrased this is that you're talking about enjoying not-too-difficult problems like it's an inherently bad thing. I think this says a lot about you.
By the time I get the kids in bed at night, I'm often out of steam. Sometimes I try to make some progress on a project, but I usually don't have the willpower to push through a stumbling block. After many many nights of staying up late and losing sleep trying to power through but not actually getting anything working, I finally realized it's better to just go to bed.
But I also feel sad if I go to bed early without making progress on something I'm excited about. So I started tricking myself by telling myself, "Well, you can just think about the project as you fall asleep." That's usually enough to get me in bed early.
And, lo and behold, quite often, I figure something out as I'm drifting off. Then when I wake up the next morning, I can get it implemented while I have my morning coffee. It's a really pleasant routine.