Solving the first 100 Project Euler problems using 100 languages
github.com
github.com
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."
"Solving the first 100 Project Euler problems in as many languages" does the trick and is only one character longer.
It was a year or two ago.
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-...
> 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?
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
It was really nice to read about the author's impression of each language.
Well done
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.
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
It’s alien code now.
Some other collection could be used for demonstration of skills and languages.
For what it's worth, when I was doing Project Euler myself, I never had a problem _not_ looking up solutions.
> the rule about sharing solutions outside of Project Euler does not apply to the first one-hundred problems
If you can provide a link, I would be really grateful!
> 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.
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.
Besides other things, there is a place to publish interesting solution: it is Project Euler forum to discuss solved problems.
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.
Yes, it would make winning a math olympiad meaningless if the exact problems could be copied by someone and submitted as their own. Of course this is not how written exams work, which makes your comparison meaningless.
The same arguments can be applied not just the first 100 problems, but to all of them. To me, seeing someone that has solved more than 300 problems is incredibly impressive. It would not be so if every Dick and Harry could copy them and submit them as their own.
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.
That's the crux of it. If one posts solutions online, then it defeats any competitive aspect of Project Euler.
Dynamic type language is what you want but static type language is what you need [TM].
Concluding there are no statically typed languages is only possible if you can't recognize them.
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.
Ada: #78 (which I listed in my initial response to you, and like the actual list, you apparently did not read).
Verilog: #17
TypeScript: #54
Futhark: #94
You just keep making it clear that you didn't even look at the list. You're making things up now.
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.
Perhaps this is why?
It's a language guys. It won't give you a BJ
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.
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 gets old.