Coming from Prolog I'm loving Haskell, but I'm seeing a special kind of "worse is better" at work here: that projects using innovative and sophisticated languages have a high risk of running into obsessive "getting it right" and "holier than you" mentality resulting into them often getting never finished, and even if finished, having a high barrier of attracting contributors. It's unfair and embarassing, but shitty languages like JavaScript and PHP often allow you to be more utilitarian and churn out good enough code because you're not emotionally attached to them, and aren't under peer group pressure to express eg. algebraic properties in their purest form or some such.
Why I never finish my Haskell programs
171–180 of 228 posts
Re: Why I never finish my Haskell programs
#172Earlier quoted context omitted.
> People only go down rabbit holes when they don't have a manager breathing down their neck all day. It takes real discipline to create really good hobby projects on your own, regardless of language. I agree, but perhaps discipline is not necessarily complete restraint... I think some rabbit holes are worth exploring, they can separate outstanding projects from mediocrity. Perhaps it's about choosing the right rabbit…
It takes experience to get a sense of where to spend that time. There are parts in any project that are write only fluff that will not be changed or extended much once written. Then there are the others where you know that things will need to grow and change a lot. There, it is incredibly important to find a good starting point fron which the code can grow with as little pain as possible. A day or two to find the rig…
how to build the foundations of an everchanging building in an everchanging environment.
not specifically directed to the parent comment, but it lead me to write this: I think the discussion here is too focused on business/productivity. I feel like different people have different approaches to coding. Some of us really need to write beautiful code, and we are ok with "wasting" a lot of time thinking about fluff until we recognise that it really is fluff, or come up with interesting ideas simply because we spent time thinking about something. Maybe you care about the end result, maybe you care about the code, maybe you care about both. And even when you care about one or another, you do it in different ways. We start optimizing algorithms, then we build frameworks and "optimize" workflows, and then we want to optimize the approach to coding. But I don't think that's universally doable as with algorithms. We end with great insights and confused discussions.
Re: Why I never finish my Haskell programs
#173Earlier quoted context omitted.
I agree with your sentiment, but I find the analogy to La Sagrada Familia funny, in that is has still not been finished, it's a black hole for money, and you can see, clearly, it's a hodge-podge of styles... All characteristics that might not be good for your software project.
which large software project has ever been ‚completed‘?
Strike the "large" in that sentence. I somewhat think that writing software is like painting. At some point you decide to stop, but you're never truly done. Also cf. Leonardo da Vinci: "Art is never finished, only abandoned."
Re: Why I never finish my Haskell programs
#174Earlier quoted context omitted.
I know Elm isn't the same as Haskell, but these points are also used as a selling point for Elm. And more often than not, as with Haskell, the type system makes it possible to refactor a large program with the confidence that all the parts you replace will slot perfectly back into the original structure OR the compiler will yell at you until it does :).
The drawback with Elm is that it has a trigger-happy BDFL who doesn't care about breaking everything all the time. Haskell has a long history and has broken very few things over the years (n+k patterns come to mind).
It’s an unstable pre-1.0 language that hasn’t even finished its core API.
Re: Why I never finish my Haskell programs
#175> “I ought to be able to generalize this,” I say.
lol, it's no wonder he never finishes a program. But this isn't a problem limited to Haskell - one can start generalizing unnecessarily in any language.
To be fair though, the Haskell ecosystem as described in this article (and from my experience) is quite frustrating, and it makes me appreciate my current language Rust that much more.
Re: Why I never finish my Haskell programs
#176Earlier quoted context omitted.
It takes experience to get a sense of where to spend that time. There are parts in any project that are write only fluff that will not be changed or extended much once written. Then there are the others where you know that things will need to grow and change a lot. There, it is incredibly important to find a good starting point fron which the code can grow with as little pain as possible. A day or two to find the rig…
how to build the foundations of an everchanging building in an everchanging environment. not specifically directed to the parent comment, but it lead me to write this: I think the discussion here is too focused on business/productivity. I feel like different people have different approaches to coding. Some of us really need to write beautiful code, and we are ok with "wasting" a lot of time thinking about fluff until…
That clicked a lot, the first sentennce, if code architecture is like a building with many extra dimensions then programming has this quantic challenge of getting beyond the fourth dimension of time to an intuition of how to build the foundations and subsequent DSL design levels of the code building's own future state, as if the future state exists in the present along with all other possible building states (that fit project[ed] constraints), since time is not a restraining cognitive concept in those higher dimensions of architectural mathematic representation.
Re: Why I never finish my Haskell programs
#177It's about Scala, not Haskell, but the gist is the same:
at my company we're giving new candidates a live coding interview where they get one hour to write a very simple application using either Java or Scala. Candidates are free to choose between those languages.
The funny thing is, that candidates who choose Scala are never able to fully finish the assignment. Even though the application is really simple, many don't finish half of it and some even get completely stuck in complex for-comprehensions and what not. Candidates who choose Java however mostly are able to finish the assignment. The code might not always be the most elegant, but it does what it is supposed to do.
Even though I like Scala a lot, I feel it has the downside that it gives you too many options to do the same thing. This can get in the way when you are simply trying to implement some basic business feature.
Re: Why I never finish my Haskell programs
#178I think many beginning Haskellers have this problem. To overcome it, my advice is to write Haskell code with the knowledge that you can re-write it more readily than you can re-write code in many other languages. Write the code that fits the immediate application, and rely on the type-checker to make it straightforward to refactor when the need arises. I think that’s what many experienced Haskellers would say is the…
In my case, I think it's because large programs always end up containing subproblems that can be better expressed in other paradigms than functional. And it becomes frustrating when I can't shoehorn them to the Haskell way of doing things. My favorite languages are, for this reason, multi-paradigm: Common Lisp, Mozart/Oz, Scala and C++. It's a bit like building La Sagrada Familia (and that's why it's depicted in the…
Mozart/Oz??? I never heard of it. Now there is another rabbit cave to spelunk in my search for the perfect programming language.
Re: Why I never finish my Haskell programs
#179It's about Scala, not Haskell, but the gist is the same: at my company we're giving new candidates a live coding interview where they get one hour to write a very simple application using either Java or Scala. Candidates are free to choose between those languages. The funny thing is, that candidates who choose Scala are never able to fully finish the assignment. Even though the application is really simple, many don'…
So Scala is harder to write, but the question is: is it easier to read?
(Since in general a particular piece of code is read far more often than it is written).
Re: Why I never finish my Haskell programs
#180Earlier quoted context omitted.
Haskell 2010 is pretty small. Comparable to say Clojure, but more complex than Scheme. GHC Haskell with the kitchen sink of extensions turned on is big. Very big. Sticking to Haskell 2010 with a few extensions that make known behavior more consistent (GADTs, NoMonomorphismRestriction, and a few others in that vein) is the best bang for buck in my experience.
The complexity of a language has nothing to do with its size. Brainfuck or Whitespace are two minuscule languages that produce the most impenetrable sources.
> I'm from Microsoft and when you see Microsoft documentation it often says, you know, x y or z is a rich something, right. In this case Haskell - or ghc's version of haskell is a rich language. What does this mean? Sounds good, doesn't it? But it always means this, right. That it's a large, complex, poorly understood, ill documented thing that nobody understands completely.
From a great talk by Simon Peyton Jones https://youtu.be/re96UgMk6GQ