@ayo @wolf480pl @grainloom Fair enough. In which case, functional programming is not that boring because it's not ubiquitous. Though yes Lisps could qualify.

I was kind of thinking in terms of novelty, and wondering at which point does the novelty wear off?


@alcinnz @ayo @wolf480pl @grainloom
I think a boring programming language is a language that:
- has very clear and distinct concepts (and not too many of them)
- a well maintained set of libraries and an easy way to install them in different versions
- does not hit you in the face with NullPointerExceptions and segfaults
- when it compiles it runs

is such a language for me.

· · Web · 2 · 3 · 2

@janriemer @alcinnz @ayo @grainloom
Maybe Rust doesn't have too many distinct concepts, but if it wasn't adding more with every release, why would the language version number (not to be confused with compiler version) go up so quickly?

@janriemer @alcinnz @ayo @grainloom
Also, I'd take a comfy and stable standard library over any amount of well-maintained micro-libraries which change API so frequently that you need to care about version at all

@wolf480pl @alcinnz @ayo @grainloom
Well, I think we have to differentiate here. Version numbers go up, because:
- existing features/concepts get refined(!) -> there are not many entirely new concepts and if there are, they make sense design-wise, because they play nicely with existing ones
- the standard library evolves

@janriemer @alcinnz @ayo @grainloom

This creates technical debt for everyone who targetted an older version of language/library.

@wolf480pl @alcinnz @ayo @grainloom

As long as nothing gets *removed* and you are able to use an older version I don't see a problem in that. That is why there is something like SemVer.

Also, what is the alternative? Stagnation?

Regarding technical debt: I highly recommend this very good read 🤓 "Forget Technical Debt — Here's How to Build Technical Wealth":

"Technical debt always reflects an operations problem."

@janriemer @alcinnz @ayo @grainloom

The alternative is making things good enough that they don't need to be improved, and continuing to fix bugs while others build cool stuff on top.


@wolf480pl @alcinnz @ayo @grainloom
Thank you for sharing the article. There are a lot of good points in it and I highly resonate with them.❤️

BUT, there is no such thing as time-travel!
These libraries and other languages had years or, in case of languages, *decades* to mature, before they are considered stable.

Rust had it's 1.0 in 2015 and look what they have achieved in this "blink of an eye" (I'm taking Rust as an example, but there are certainly other projects, which have achieved the same)!


If you like "very clear and distinct concepts (and not too many of them)", Haskell has even fewer without feeling limiting! And it hits your other points quite well too.

Whilst having had decades to stabalize. The only problem is mainstream programming shuns functional programming...

And when the poorly documented GHC language extensions get brought up, which I find largely irrelevant.

@ayo @wolf480pl @grainloom

@alcinnz @janriemer @ayo @grainloom
-XFlexibleInstances -XMultiParamTypeClasses -XFunctionalDependencies -XTypeFamilies -XFlexibleContexts -XTemplateHaskell -XQuasiQuotes -XTypeApplications -XScopedTypeVariables -XViewPatterns -XLambdaCase

Haskell is fun.
Overengineering stuff in Haskell is even more fun.
Definitely not boring.

@alcinnz well ok, -XViewPatterns, -XLambdaCase, -XQuasiQuotes and -XTemplateHaskell are kinda bloat.

But the other ones are usefull all the time...

Thank you for the tip! I find functional programming very intriguing, but haven't learned a purely functional language yet.

I'd probably go with Haskell, Elm and/or F# (don't sue me for the last one 😄)

@ayo @wolf480pl @grainloom

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!