Haskell very much has an if then else equivalent.

  if' :: Bool -> a -> a -> a
  if' True  x _ = x
  if' False _ y = y

https://wiki.haskell.org/If-then-else

Also, Java was designed to handle performance critical code like that. That’s why people call it a fast language, you can write non performance critical code however you want, but optimize for speed and it’s going to look like C.

Maybe I'm nitpicking, but I see that construction as the equivalent of the ternary operator. Its not the if-else construct you find in imperative languages. The claim was "Every language can do some form of if then else" - which I read to imply that every language is semantically familiar to someone who knows python / C / java. Haskell's approach is certainly not familiar if you've only ever written javascript or something.

> Also, Java was designed to handle performance critical code like that. That’s why people call it a fast language

Sure; but my point is that idiomatic java looks quite different from idiomatic C. If your first language is C, its easy to write java that looks like C. If your first language is java, you can torture C into looking like a bad version of java. But both approaches are newbie mistakes. Learning a language involves a lot more than just being able to make programs that work at all. Its also learning a culture, and learning to make code that fits well with the existing ecosystem. You won't get very far in the java programming community if you don't know how to write java in the popular style.

Thats why they say learning your second language is difficult. You need to unlearn some of how you approach programming so you can come at your second language with fresh eyes.

Doing better is irrelevant when we are talking about what constitutes the basics of programming. You can always improve your personal skills, but the basics are in effect the smallest set of skills that works.

“The smallest set that works” in the real world requires that you can write code that others can read, write code that could pass a PR. And that you can read the code that others write.

If you only know enough Java to be able to translate awkwardly from C, you aren’t fluent in Java. I know bits and pieces of Haskell - probably enough to make working programs. But I’m not fluent in Haskell. I can’t read the code others write. I can’t think in Haskell. And that’s not enough.

This is talking about students. Writing code that works and others can read is roughly the benchmark for operating at the professional level. It’s not enough to get a job at FAANG, but many company’s have lower standards.

“Professional” is not what most people mean when they talk about the basics as say a welder, cook, etc.

Just a nitpick, but this is false

> Haskell is missing the idea of something happening after something else

A Monad is implicitly a monoid, which certainly does specify an ordering. And as for expressions, the order of evaluation of arguments is not specified either by C for example.

The bigger problem is that "something happening after something else" is not related to the idea of an if-then-else.

In Common Lisp the if-then-else construct is IF. The "something happening after something else" construct is PROGN. The whole point of if-then-else is that only one thing happens; "something happening after something else" requires a minimum of two things.

I don't really get your point. If/else expressions are in principle free to evaluate both branches, but that would be needless. But when we provide an IO Monad for example, if/else expressions will not suffice in the naive way -- you have to use the monad "bind" operation to actually provide an order -- what it boils down to basically: the A; B; C; in imperative languages become C(B(A())) in pure FP ones -- with implicit ordering.

> If/else expressions are in principle free to evaluate both branches, but that would be needless.

This is true only in a pure functional language; if you admit the existence of side effects, then it is a crucial part of an if statement that the code associated with the other branch is never executed.

My point is just that it makes no sense to say "some languages have no form of if statement; for example, Haskell doesn't have the concept of one thing happening after something else". That example is untrue. But if it were true, it still would not interfere with Haskell's ability to have an if statement. Thus, defending Haskell's ability to run one statement after another statement is unnecessary to refute the claim; the claim never worked in the first place.