Me, trying a new programming language: Wow, this is great! I wish all software was written in it so that it has a healthy ecosystem!

Me, one or two years later: Ugh, that language has major downsides, is a pain to use and now I'm stuck with software written in it. Why was I ever enthusiastic about it?

Somehow I always end up going back to Perl and C, old and ugly languages that don't let me down.


@wolf480pl @ayo I wonder: does Haskell count as boring?

It's several decades old, but is only recently having it's influence on more popular languages like Python. Probably via Rust.

@alcinnz @ayo
Also I wouldn't consider Erlang and Elixir boring either.

@alcinnz @wolf480pl @ayo Rust is more influenced by the ML family. It was originally implemented in OCaml.
Which is another good candidate for a boring language that doesn't suck as much as C. (which sucks a lot without a bunch of tooling)

@grainloom @alcinnz @ayo
OCaml is definitely the most boring of functional languages. So if a functional language can be boring at all, OCaml is one of them.

@wolf480pl @grainloom @alcinnz If I had to come up with a criteria for "boring" in this context, it would come down to: Ubuiqitous, well-understood and very stable in both the language and the ecosystem.

I'd say the most boring functional language would be one of the Lisp dialects.

(Of course, a language can also be "boring" in the sense of not taking on any novel ideas, but that's probably a different topic)

@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

#Rust is such a language for me.

@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

@ayo @wolf480pl @grainloom @alcinnz
Another way to define "boring" is "Tends not to surprise you". By that definition, JavaScript is probably the least boring language, and C isn't great because of all the undefined behavior and historical oddities.

@mathew @ayo @grainloom @alcinnz
that's really subjective though, and tbh I'm more often surprised by eg. Python than by C

@wolf480pl @mathew @ayo @alcinnz For what it's worth, Python type conversions never confused me, unlike C. You have to make many conscious choices to make C unsurprising.

@grainloom @mathew @ayo @alcinnz
with Python it's not the language itself that surprises you (although unicode handling can be wierd) but the ecosystem.

@wolf480pl @ayo @grainloom @alcinnz
Python's ecosystem is horrible, yes. If something involves using a Python-based builder or installer, I just go looking for a different solution.

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).