Worth emphasising: Project Euler is a mathematical computation challenge, not a programming challenge like Advent of Code. The principal skill is algorithm design and as the problems progress you need to do more and more maths before you start coding.
I wonder which ones the author liked the most and which they disliked the most. I didn't see any comments on that. If they're on HN, it'd be cool to find out.
The author wrote a short comment about each language in the following blogposts:
It's hard to form a good opinion of a language if the knowledge of it is shallow, which I'm inclined to believe based on using 100 languages. More interesting is why the author decide to use a particular language for each problem.
Why did I expect 10,000 files?
I'm totally with you, bro. Maybe the headline should have been "Solving 100 project Euler problems using a different programming language for each one" but that's probably way too verbose.
I expected 100x100 programs too without thinking how unreasonable that is. But sometimes it's hard to gauge what's unreasonable on HN.
"Solving the first 100 Project Euler problems in as many languages" does the trick and is only one character longer.
>how unreasonable that is
It was a year or two ago.
From one of blog posts [0]:
Nim
Nim is the language that impressed me the most in this batch. Everything I thought would be a problem (significant whitespace, choose-your-own-function syntax, intermediate C compliation step) didn't bother me at all. The small sample of the standard library I played with was a little quirky, but Nim seems like excellent bang for your buck.
Notes:
- Release binary was only 120 KB (linked against libc)!
- Thought I'd dislike the syntax, but it was fine
- Really easy to get started, many things "just worked" (e.g. grabbing a slice of an array)
- Didn't have to specify too many types, but still ran fast
- Fast compilation
- Didn't like the "hints" it spews out during compilation, even for nim r (build and run)
- Why did all take an anonymous function, but foldl took just an expression (with a and b seemingly picked out of thin air) -- is foldl a macro?
- Nim might be a good language for hobby projects because it's easy, fast, and produces small binaries
- I wonder what the debugging experience is like -- if it's decent, I might be writing a lot more Nim in the future!
0-https://log.schemescape.com/posts/programming-languages/100-...
Nim is a gem and I wish it was more mainstream than it is. Its older than both Rust and Go.
I am interested in seeing Verilog used as one of the 100 languages.I have been wondering how it would be to use some sort of hardware description language to solve some of (all?)the problems. I worked thru the first half of "Nand to Tetris" [1] and thought I might try working some of the problems with that.
From one of the blog posts:
> 8080 assembly (Altair 8800) > > First time I've heard of binary-coded decimals
I’m really surprised with that, that someone with such broad interests never heard of BCD. I mean, there’s is always something new to learn all the time, don’t get me wrong, nothing to criticize, just plain surprised. Wonder if that is just something older people came across?
Old PL/I programmer here. I’m still trying to forget BCD’s from the 80’s!
I learned about BCD when I was learning x86 assembly and have never came across them later. They are gone in x64.
I did learn binary-coded decimals in college 5 years ago.
Pretty sure the first one should be done with a closed form formula:
lcm(3, 5) = 15. So there is a repeating cell of values every 15 which we can take advantage of:
0, 3, 5, 6, 9, 10, 12,
+ 15 -> 15, 18, 20, 21, 24, 25, 27,
+ 15 -> 30, 33, 35, 36, 39, 40, 42
Wowow! this is fantastic, so many exciting and weird languages in there, even Mouse-83 is in the list!
It was really nice to read about the author's impression of each language.
Well done
Let's say an experienced engineer is starting Euler for the first time. What's the best way to approach it given that many of the problems require some prerequisite algorithmic knowledge to solve? Is there a good method for approaching Euler and LeetCode problems with new eyes aside from reading the solutions first, studying them and then solving it many times until committed to memory?
IMHO, Project Euler is a lot harder than LeetCode and requires a lot more math.
I'm not sure why you would want to solve it many times and committing those solutions to memory? I think you would be better off using some of the time to just read some text books?
For some of Project Euler https://www2.math.upenn.edu/~wilf/gfology2.pdf is a good math book to consult. The techniques in there will allow you to solve some of the problems with just pen and paper (and perhaps a pocket calculator, if you are too lazy to do the arithmetic by hand, but no need for a full blown programmable computer), especially the first few problems if memory serves right. Eg where they ask you to add up the first few billion even terms of the Fibonacci numbers and similar; you can just derive a simple closed formula and evaluate that by hand.
What is a closed formula?
Thanks.
Project Euler is collection of puzzles based on math. The coding and designs skills are completely secondary to the math. The algorithms (except for computational number theory, computation geometry) are completely secondary. So it is knowledge of math that is barrier.
I keep learning math (and, sometimes, relatively new development in math) by solving problems. To start, I would recommend reading G.H. Hardy & E.M. Wright "An Introduction to the Theory of Numbers".
With LeetCode -- this is more traditional exercise in coding. I did not pay much attention to it. So, sorry, cannot provide any advice
Really it's fine to just start. At some point you may get stuck and want to learn more math, but when I did the first ~45 I certainly had not read generatingfunctionology or Hardy and Wright.
I like how the author used four different variants of BASIC.
I'm curious if they are really, like, different. All Basic that I've seen in my life was a minuscule bit of VB and some really ancient programming book I've picked up when I was like 7 y.o. and didn't really have access to a computer.
I remember QBasic was notably different from Applesoft Basic in that QBasic did not require line numbers, and one of the demo programs (remline.bas) removed line numbers for you. Of the variants used by this author, the Commodore Basic variant is distinct in being the only one with line numbers. The others all look very similar.
Back in the day, over a decade or so, I wrote a few megabytes of VAX Basic. The language, and the code I wrote, at the end of that period looke nothing like it did at the beginning. So yes, it’s quite likely that the Basics are substantially different.
AmigaBasic is quite different from Commodore Basic v2.0, and that’s within the same company.
That's cute but if you can't solve those problems in INTERCAL then can you even call yourself a programmer? (But seriously this is pretty cool.)
I solved the first 100 problems a long time ago before learning the best practices we learn as professional engineers.
It’s alien code now.
Impressive, but after reading the title I have to admit to being a little disappointed at not finding 10,000 solutions.
Yeah when I read that they "started this journey in March of 2024 and...completed it in January of 2025" I was like :o
Happy to see Mouse83 get some air time :)
the julia solution was bad
I find it rather annoying and irrespectful for Project Euler. They specifically ask not to publish solutions.
Some other collection could be used for demonstration of skills and languages.
From Project Euler homepage:
> the rule about sharing solutions outside of Project Euler does not apply to the first one-hundred problems
Apparently I do not keep up with times. I read the rules some 15 years ago last time. :-(
If you can provide a link, I would be really grateful!
As pointed out in a sibling comment, it appears that quote only shows up if you're logged in (apologies--I wasn't aware when I originally replied), but assuming you have an account and are logged in, it's on the homepage (https://projecteuler.net/), second paragraph under the following heading:
> I learned so much solving problem XXX, so is it okay to publish my solution elsewhere?
> It appears that you have answered your own question. There is nothing quite like that "Aha!" moment when you finally beat a problem which you have been working on for some time. It is often through the best of intentions in wishing to share our insights so that others can enjoy that moment too. Sadly, that will rarely be the case for your readers. Real learning is an active process and seeing how it is done is a long way from experiencing that epiphany of discovery. Please do not deny others what you have so richly valued yourself.
> However, the rule about sharing solutions outside of Project Euler does not apply to the first one-hundred problems, as long as any discussion clearly aims to instruct methods, not just provide answers, and does not directly threaten to undermine the enjoyment of solving later problems. Problems 1 to 100 provide a wealth of helpful introductory teaching material and if you are able to respect our requirements, then we give permission for those problems and their solutions to be discussed elsewhere.
You could say that providing code in an obscure language isn't really to "instruct methods", but I think it's within the spirit of the rules.
thank you very much! pointer to the home page would suffice. your willingness to walk an extra mile (and copy relevant text) is much appreciated.
as i mentioned, i read home page years ago. in that time, third paragraph did not exist and 1-100 were considered a challenge. the language of request changes since that times.
fwiw this only shows up if you're logged in (at least for me), which confused me for a bit
Oops, you are right!
The first 100 problems are fair game to publish, I can't find it on their website anymore, but it's generally accepted that this is the case. You can check out the project euler discord for more authoritative information on this
I know they ask, but it's really easy to find solutions online.
For what it's worth, when I was doing Project Euler myself, I never had a problem _not_ looking up solutions.
Just because a bus stop already has a broken window does not make it ok to smash in another.
Yes, but it's also a bit like closing the barn door after the cows have escaped.
I find it annoyingly unrealistic to demand that nobody publish solutions, especially interesting ones like this. Some people will always do it anyway, and once they do, any further resistance to such publications is pointless. If you want something secret, your ultimate mistake is publishing the problems in the first place. For a problem set as old as Project Euler, it's not reasonable to expect solutions to not be out there, and it is ultimately on the honor system whether a problem solver cheats or not.
It is called the honor system. But you're right: some people... And no, Project Euler does not demand. You can be sure, nobody is going to be sued. It asks politely to show respect to those who created the project, and to those who did not solve the problem.
Besides other things, there is a place to publish interesting solution: it is Project Euler forum to discuss solved problems.
Demand is a strong word. I do think it's entirely reasonable to ask, especially around the time the problems were first published. Things have changed on the internet
Well, HN specifically asks for people to not comment shallow dismissals of others work, but here we are…
at this point it is an old problem set, the solutions are everywhere and easy to find, at the very least for the first 100 problems. for those problems (at the very least) it is the responsibility of the participant to not look at solutions.
It's ChatGPT answers anyway.
[dead]
Horrible, just horrible. Why would one release this publicly?
Why not? It seems like it’s worth sharing.
There are a lot of people that have spent copious amounts of time solving these problems. Fewer than 1.4% of the registered Eulerians have solved more than 100 problems. Releasing the solutions for these trivializes their work, as now anyone can copy them (unless the assumption here is that solutions to all those 100 problems have been previously released on the net).
It doesn’t trivialize their work at all - they should still be proud of their accomplishments.
Does releasing the Putnam answers make winning a mathematics olympiad less meaningful, after all I can copy those answers easily.
Does learning how to implement distributed locking besmirch Lamport’s legacy?
Even still, the project itself approves of releasing solutions to the top 100 problems.
Maybe the comparison is even more meaningless because Project Euler is not a competition.
Solving 300 problems is impressive, even if the solutions are posted online, not in the least part because copying solutions you found isn’t solving the problems.
All this means is that seeing a number on someone’s profile isn’t a reliable signal that they solved those problems, which I guess is a fine thing to take issue with.
No entry for proper static type languages namely C++, D, Go, Rust?
Dynamic type language is what you want but static type language is what you need [TM].
Ada, SML, F#, and more. Seems like you may not have looked at the list.
It's more probable they skimmed and couldn't recognize those. There's Idris, Hare, Odin, V, Roc, Haskell, Nim, Haxe, PureScript, Vala, Lobster, and arguably Common Lisp and Dylan. That's from a single read of the list.
Concluding there are no statically typed languages is only possible if you can't recognize them.
OK I stand corrected, but less than half of them that you've mentioned are not proper static type meaning that you cannot enforce and guarantee static and strongly type only Idris, Hare, Odin, V, Roc & Haskell.
Only about 10% of the listed programming languages are proper static typed languages and most of the popular static typed languages are conveniently left out.
They're missing the usual suspects of D, Rust, Ada, C++, Elm, Swift, Kotlin, Scala, TypeScript, Eiffel, Crystal, Modula-3, Futhark, Sather, VHDL, Verilog/SystemVerilog, etc.
Sure you're correct that I'm missed some of them but, the list are still missing many static languages that's my overall points:
D, Rust, C++, Elm, Swift, Kotlin, Scala, Eiffel, Crystal, Modula-3, Sather, VHDL, etc.
Also my main point of contention is that only small percentage of proper static languages (about 15%) are on the list if we include Ada, Futhark, Typescript and Verilog.
Just don't lose the forest for the trees.
100 languages and yet not a single use of Rust. The omission feels like a statement.
It's hard to make me hate something I've never engaged with and yet the Rust community has managed to do it with their overzealous love.
It's a language guys. It won't give you a BJ
I went on LinkedIn this morning and I saw four posts from people talking about how good Rust was compared to other languages and then a bunch of comments from people with crab emojis in their names. Four. Its community is insanely cult like, I have never come across it before (maybe some Lisp-evangelicals, but they are individuals and not entire groups).
> I went on LinkedIn this morning and I saw four posts from people talking about how good Rust was compared to other languages and then a bunch of comments from people with crab emojis in their names. Four.
What a shame! Enthusiasm of all things. How dare they! Right in your LinkedIn feed! Not to worry though -- a little Java should snuff it right out though.
It's not enthusiasm over something they love. It's enthusiasm about how their thing is so much better than your thing.
It gets old.
> I don't mind enthusiasm, but it's the way it's written so condescendingly of other languages.
I don't know what was said, but I will say, a programming language is a tool in the toolbox. If a professional says "My Milwaukee power saw is better than anything Dewalt or Ryobi make", that's simply an opinion about a tool. No reason to take it personally if you like Dewalt.
Rust does have some downsides, and I think it is better to focus on those than any language culture war, if you choose to vetch. As in -- I think saying things like "Rust makes certain large refactors more difficult" is much better than low grade whining about the Rust Evangelism Strike Force.
> And you know it's just thinly veiled marketing to sell something (either a course, their services, etc).
Welcome to LinkedIn!
It's the "my language is better" that irks, i.e, a judgemental enthusiasm.
To be more inclusive, consider using “it won’t go down on you” rather than “won’t give you a BJ”
I have always heard both terms used interchangeably ignoring gender. Maybe you need to broaden your own limited horizons instead of claiming others need to be more inclusive.
It won't give anyone a BJ. Independent of if they could hypothetically receive one or not.
Which sort of proves the point that there aren’t really any tolerable or normal people using Rust.
Poe's Law gold right here!
Yeah their comment struck me as a joke more than a real critique lmao. But I wasn't sure so I made my reply a joke.
not every comment needs to be inclusive
[flagged]
> using a different--and, ideally, new to me--language for each problem
Perhaps this is why?
Ah I missed that part, thank you. The omission comment was tongue-in-cheek on my part.
The author wanted to use languages that were new to them, if the author has enough familiarity with rust to have a vendetta then it probably isn't new to them.
No C++. No C#. No Java. No JS. No Lua. No Brainfuck.
No Go. What makes this project impressive is how he avoided nearly all of the most popular mainstream languages in favour of eg COBOL and XSLT(!).
No German too. But, still, very impressive. That's a talent.
no php!
No Brainfuck is actually surprising. I missed that.
Math is to computer science as physics is to mechanical engineering, so I feel like there isn’t a massive distinction.
They didn't say computer science, that said programming.
Let's just say you need a vastly different level of maths to succeed at project euler compared to aoc.
Personal experience: I stopped at a point where brute-forcing started to feel "unwelcomed", I think it was this one: https://martin-ueding.de/posts/project-euler-solution-66-dio...
I would argue that the later Advent of Code challenges (especially from the last 3 or 4 years) are very similar to (early to mid-tier) Project Euler challenges in that you cannot start before giving it a good hour or so of thinking
Do you ever need to start coding? I thought it was a requirement of the project that problems be solvable with pencil and paper.
While some problems are actually solvable with just pencil and paper, this is not a requirement and the intention of the project is that problems will be solved with a combination of insight and coding.
From the Project Euler website:
"Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems."
Well you probably _could_ whiteboard it but some of them are about extending a pattern to the millionth term. If you're really smart you might be able to find a closed form to get there quick, but you can also just program the basic rule and iterate
Afaik most of them require you to find the trillionth term, rendering naïve approaches futile.
For the harder Euler problems you usually need a combination of mathematical insight and good coding technique. Each problem typically provides sample values for smaller instances of the problem, which you can confirm with a straightforward solution approach. Then the actual problem will be to calculate f(10^500) or some absurd value that requires insight to make tractable. They are extremely good challenges overall.
Advent of code is not a programming challage, it is a reading the spec challage.
Not the last 3-5 days.
Got a link? I tried it a long time ago and decided that I got enough misleading specs at work.
Huh, that's surprisingly not actively misleading.