Why does every programming language have to have so many different ways of doing the same thing? I mean, come on, do we really need both for and foreach loops? And why do we have to choose between switch and if-else? Can't we all just get along and use the same damn structure? #FirstWorldProblems

i do believe you don't understand the implications and differences of any of those structures, if you think, they're the same.

.

For loop: the order may matter, early exit is possible. Foreach loop: the order doesn't matter, can even be parallelised, no early exit.

If conditions: check boolean values of arbitrary logical expressions. In particular, the following else if may take a totally different expression. Switch case: check different numeric values of one single integer expression.

Tags: the devrant tag is not for "developer rant". There are no HR, finance or sales folks here - every rant is a "developer rant". The "devrant" tag is for stuff about the devRant platform itself.

@Fast-Nop I am starting to think "devrant" tag is somewhat ambiguous to cause conflicts. See how we do in this petri dish. Big Fox is watching... ;-)

for and foreach do _slightly different things_.

also: yeah, why do we need kitchen knifes when we have penknifes?

Match in functional-style languages is much more powerful than switch or if/else.

I guess what is used is dependent on language and required performance. Some are just conveniences added from other languages but do the same as other syntax under the hood.

So you want a more lean language?

Your wish has been granted: Lisp and Fortran exist!

@Fast-Nop In my foreach loops order sometimes matter and i sometimes do break out of them.

@Oktokolo What? How do you specify the order in the first place?

@Fast-Nop Foreach over a list.

@Oktokolo Well yeah, but semantically, the point of foreach is, well, for each. Otherwise, you'd go via the index in either direction.

@Demolishun taste the rainbow

@iiii yeah, I used online coding thingy. It does compile.

@Fast-Nop Like iterators, it is defined to honor element order in at least the languages, i used it in so far.

I would consider unordered iteration of an ordered collection an unneccessary violation of the least surprise principle.

As said, different things for different use cases.

Note that there are very funny things that can be hidden in those "seemingly" basic constructs.

E.g. for each usually refers to an Iterable - which can be really anything.

When you wanna drive an intern mad, ask him what Iterable means... The madness lies in that Iterable just means that - anything that can be "iterated", as in each element of the Iterable have been processed.

Anything beyond - be it ordering, be it the direction the Iterable processes the elements etc. - is hidden in the implementation "behind" the Iterable Interface (or whatever thing a ma bob the programming language calls it).

Switch is another interesting thing.

In most languages, switch differs from If in a fundamental way: One can intentionally fall through or add an default case. Both nifty things which are - like go-to - a perfect way to introduce bugs.

Even funnier when you use switch with return *and* fall through.

switch
1) muey code....
2) muey code...
3) return 1-2-3 or return 2-3 or return 3

Just to clarify a bit... :)

For is another funny thing. Mostly because it's seen as an counter / iterator over an enumeration.

But you can - in most languages - use it as an while true loop.

for (initialization; termination; increment)
Is the classic example.

In the fine print of many languages, it's explicitly mentioned that each of the 3 is optional.

You can omit initialization, termination, increment - each one or all of them.

for ( ; ; ) {
}
Is the classic infinite loop.

I could go on, e.g. if / else / else if have some interesting things to offer, too....

But I fear that some people might wanna wish me dead already, so I better stop poking the hornets nest.

TLDR: the fine print of basic constructs is ... Always worth reading it. You might learn a lot of things you didn't want to know - but it's worthwhile.

@Oktokolo I agree, unless it has the ability to thread. But that is usually explicit.

@IntrusionCM Death by infinite loop! lol

@IntrusionCM Iterator guarantees the selection axiom; you can get an element.

But Iterator has more properties than that. It has an order and it has a "no next element" response. Whether this is used is up to the implementor, but the overwhelming majority of structures that support both an internal ordering and Iterable guarantee the order, and every finite datastructure guarantees that you will get a "no next" after all correct answers have been returned once. Because technically, Iterable doesn't even guarantee that the next element is in any way different from previous elements. It's not a complicated concept, the reason newbies struggle with it is that Iterator is perfectly useless. You can treat it like a series, a set, or both. If it's neither, it's not really possible for a computer program to make useful statements about it.

Bro got hella ratio'd.

I feel your frustration man, all these complex options that modern languages offer can be overwhelming and even induce a negative reaction in the programmer.

But as you get used to them and learn their importance, you learn to love them. Soon, you would learn to hate languages that don't offer a for-each loop with lambdas as you meticulously type out an imperative processing loop that could be a one-liner functional (or declatative-esque) statement in a more well-endowed language.

@lorentz Iterator != Iterable though.

Hope I didn't mix it up somewhere in my comment, but I was talking specifically and only about Iterable.

@IntrusionCM Yeah I mixed it up. My point still stands though, Iterable in and of itself is pretty useless, you need a better contract that guarantees some attributes beyond the ability to create iterators in order to achieve anything.

I always understood it as Iterable being the interface/contract, as in, how to next(), and how to tell end.

Iterator is an implementation of Iterable. And it's the iterator who therefore gives guarantees. You could easily write an iterator that iterates in value order and not "memory" order, for example.

@lorentz @CoreFusionX

Yes. Iterable is *intended* to be dumb and simple, as it is the base for everything else.

In most languages Iterable is an Interface that just contains a single function - the Iterator creator.

E.g. in Python __iter__.
PHP has Traversable, which has zero functions: https://php.net/manual/en/...
It is just a common base for either IteratorAggregator with the Method getIterator or Iterator with the Methods next, current, key, rewind, valid.

Javas Iterable has getIterator e.g.
https://docs.oracle.com/javase/8/... - additionally an forEach for consumer plus spliterator.

It's really a pretty simple and basic concept - pretty much anything that goes into the direction of Collection / Generator / ... implements Iterable in some way.

@Demolishun Many devices around you will in fact run an infinite loop - in embedded, there is nowhere you'd want to return to from main(), so the application will involve an infinite loop.

@Fast-Nop doesn't every daemon ever does that? Unless they are doing some fancy "sleep until an interrupt" magic which is not applicable in most use cases anyway

@iiii Might be, I've never written one of these.

@iiii not necessarily.

There are... Interesting ways to realize this.

https://github.com/haproxy/haproxy/...

E.g. - as I think HAProxys code is very well commented - event loops are pretty common (or similar ideas).

I'm not sure if you meant that by your comment, but if you understand C, might be an interesting read for fun.

@IntrusionCM there's a poll loop just before the end of the function. It's literally a regular endless loop with a breakout condition under the hood

Did we already have the sickest combo of for loop and switch case, that being Duff's Device?

https://en.wikipedia.org/wiki/...

@Fast-Nop hehehehe

I was afraid of posting this, cause that is really funky stuff.