|
I've been trying to teach myself Racket by making a few list-eaters and solving some of the beginning Project Euler challenges in it. For the most part, I think the functional way of doing things is really neat, but there are occasional challenges that I don't see any clean approach to solving without falling back on the old standard of iterating over a mutable array. The big example is implementing a prime number sieve. In python, I'd just make a bitstring or something and play whack-a-mole. It's true that you can always set! the elements of mutable vectors in Racket, but the process is so wordy that you are practically discouraged from doing it. What would you do in a language like Haskell where apparently you can't mutate anything? Are functional programming languages just less ideal for the sorts of projects where you find yourself doing a lot of little updates?
|
#
¿
Jul 20, 2015 10:53
|
|
|
|
| # ¿ May 1, 2024 16:02 |
|
|
Jabor posted:a rather interesting paper around exactly this question Wow, that so directly addressed my question, it's kind of eerie. Thanks for sharing the link. MononcQc posted:Almost every time you want to use an algorithm you know, you end up having to find a clever way to transform it to work a bit differently (or to invent your own variation of it) so that it meshes well with the stuff supported by your language and its constraints. The above paper gives a good illustration of this--of finding a clever way to transform the algorithm to fit the idiom of the language. What is frustrating for a beginner is that we can only be counted on to come up with a handful of somewhat clever designs every week or so. It is easy to forget that the sieve of eratosthenes is already a superbly clever idea. If a beginner had the amazing flash of insight to come up with the sieve solution on his own, he would immediately be discouraged by the fact that it can't be implemented directly but it would take at least three more subtle and ingenious ideas to adapt it to a functional style. Maybe this is just my attitude because I am still inexperienced, but I feel like with imperative programming you can implement a clever idea in an obvious way, but functional designs require you to be clever at every stage of the process. Sometimes it's actually nice just to be able to write the lengthy boilerplate code that solves the problem without having to be clever all the drat time. I guess it's good to have both styles on tap for those times when you do have the elegant solution though. Maybe I should look into F#.
|
|
#
¿
Jul 21, 2015 05:34
|
|