bedman12345

Could you explain what practical research there is to be done? The heavy theory I know does not seem to be very useful in practice. Optimal join algorithms, Yannakakis adjacent algorithms, tree decomposition of queries all seem to be worse than well implemented naive algorithms. But maybe the implementations of the new algorithms just are not good? I really don’t know.

Which database companies have research labs? AFAIK amazon, snowflake, databricks, google and SAP don’t have a research lab dedicated to databases. They have some people that are paid to do research but there does not seem to be an IBM Almaden anywhere in the world.

> And yet terms like "elegant" have no objective definition.

Why does that matter? You seem to really think one needs objective definitions? It should be clear that whether a definition is objective or not is subjective itself. The question is whether there is some shared experience. And most people agree on what’s simple and what isn’t. You can now argue that’s all cultural, but that’s also a rather ridiculous position. We all experience advanced math as more complicated than 2 word sentences and so on. And I’m arguing, using my experience and examples, that functional programming is unnecessarily complicated. Requiring objective measures either misses the point. It’s really not a reasonable ask.

> You claim things as being inherently hard to read and understand.

I don’t.

> But this is a matter of one's personal context and experience. There are things that I'd find hard to read that you would not, and vice versa.

Obviously.

> Just because you don't like something doesn't make it universally bad.

Not my point.

My claim is that most people who want to be good software engineers can spent their time better than doing functional programming. I’m trying to disprove the opposite claim. That claim being that you’d learn something important from doing it or that functional programming offers something important to the programmer. I’m simply sharing the result of my journey through it so that others don’t have to make the same mistake. If it’s fun to somebody they should of course do it. What upsets me is that I was caught up in this delusion that functional programming is worth spending significant time on.

True. My statements are meaningful because of that. The objective measures we could agree on are obvious, so they need not to be stated. The heart of the debate is about the things that are hard to measure. As most things in software engineering. I ignored your question because it is a bad one.

> The Haskell looks much better, and I don't even know Haskell

Plain crazy take. The c example uses basic coding to implement some clever maths with special fast instructions. Thehaskell example is just some dumb algo implemented with complicated programming. There is obviously nothing good about that.

You can also look at a c example without simd https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It’s shorter and simpler and faster than the Haskell version. It’s not even close???

It’s slow. Example: quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter (< p) xs greater = filter (>= p) xs

It’s really complicated. Everybody includes lenses https://hackage.haskell.org/package/lens I don’t want to read all that stuff just for imperative syntax.

It’d both slow and hard to read. Compare these two: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The c examples complexity lies in using SIMD. If you know simd it’s easy. You should know simd, it’s useful. The Haskell example is drivel. Long complicated and in the end hopelessly slow compared to the c example. You could als use simd in Haskell, but then it would just be C with extra steps.

Man I hate functional programming so much. Please, to anyone reading this. Don’t waste your time on this stuff. They always try to claim functional code makes things safer and more elegant, but I have never seen that in reality. These ideas seem to produce terrible code first and foremost.

> Could you imagine people saying the issue with Java is its extremism towards objects and method calls?

I think exactly that all the time. It’s ridiculous.

> That's a problem no haskell user has, honestly.

I had this problem all the time when trying to write games in Haskell. Not every subject matter decomposes into semirings. Just like not everything decomposes nicely into objects. People tried to fix this with FRP or lenses. Both are worse than imperative programming for games imo.

I’ve been working with pure functional languages and custom lisp dialects professionally my whole tenure. You get a whole bag of problems for a very subjective upside. Teams fragment into those that know how to work with these fringe tools and those who don’t. The projects using them that I worked on all had trouble with getting/retaining people. They also all had performance issues and had bugs like all other software. You’re not missing out on anything.

An example of how to use the io monad for simulations https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It’s one of the nicer to read ones I’ve seen. Still is terrible imo.

Most database companies run only a small amount of tests before committing. After committing, you run tests for thousands of hours. It sucks. You probably do this all day every day. You just run the tests on whatever you have currently committed. you kind of have to be careful about not adding more tests that make it take much much longer. See https://news.ycombinator.com/item?id=18442941

You simply use "intuitive mathematics", in other words: no formalization. That's at least what I got when I read books on set theory.

Löwenheim-Skolem implies the existence of a countable model of ZFC. https://en.m.wikipedia.org/wiki/L%C3%B6wenheim%E2%80%93Skole...

"What I meant to say is that multiple models are not the only reason for something to be true but unprovable, the incompleteness theorem also holds in more general conditions." I can't give a clean rebuttal for this, but I believe this to be profoundly mistaken. It might be technically correct though, depending on how you'd formalize this statement. To formalize math you need a logic that has some properties: it should be decidable whether a proof is correct, you should be able to write it down, it should not be contradictory. If you take these together the only way a statement is unprovable, is if it is independent from the axioms, i.e. there exist multiple models.

Yeah but second order logic itself is incomplete. ZFC doesn't have a single model, too, btw. In the end unprovable sentences exist because there are multiple models satisfying your axioms.

True, but if you add too many axioms, the resulting set of axioms will not be computable anymore. If you allow your set of axioms to not be computable you can of course just use the set of statements that are true for whatever model of the natural numbers you have in mind. The whole point is that it's not possible to write down any sensible definition of what natural numbers are supposed to be.

This is a mischaracterisation of gödels incompleteness theorem. The set of axioms the theorem is about isn't even mentioned in the article. This is very important. If you pick the empty set as your axioms, most statements will be independent of them. The important insight is different. One can simulate a computer in the peano axioms. If you could prove or disprove (starting from a computable set of axioms) every statement about simulated computers you could also solve the halting problem. Kleenes (the kleene star guy) proof goes that way.