While you do have a fair point, I was referring to the case where one is basically implementing a map operation as a for loop.

Technically this is also possible with for loops, like with OpenMP

Compiler optimizations like function inlining are your friend.

Especially in functional languages, there are a lot of tricks a compiler can use to output more efficient code due to not needing to worry about possible side effects.

Also, in a lot of cases the performance difference does not matter.

Depends on how deep down the rabbit hole you want to go :p

• creating a new variable that contains the updated value
• recursion (e.g. it’s not possible to make a loop that increments i by 1, but it is possible to turn that loop into a function which calls itself with i+1 as argument)
• avoiding typical types of operations that would update variable values. For example instead of a for loop that updates every element of a list, a functional programmer will use the map function, which takes a list and a function to apply to each element of that list to create an updated list. There’s several more of these very typical functions that are very powerful once you get used to using them.
• monads (I’m not even gonna try to explain them as I hardly grasp them myself)

Dogmatic statements like this lead to bad, messy code. I’m a firm believer that you should use whatever style fits the problem most.

Although I agree most code would be better if people followed this dogma, sometimes mutability is just more clean/idiomatic/efficient/…

In functional programming, everything is seen as a mathematical function, which means for a given input there is a given output and there can be no side effects. Changing a variable’s value is considered a side effect and is thus not possible in pure functional programming. To work around this, you typically see a lot of recursive and higher order functions.

Declaring all values as const values is something you would do if you’re a diehard functional programmer, as you won’t mutate any values anyway.

Tar Xtract Ze Vucking File

Edit: apparently someone else already mentioned this, oops

Reed hucks = redux Heather net = ethernet

Oh no, strangers on the internet know I had sex and there were dog-like noises! That’s the exact same as people who know me IRL such as family or coworkers! I shall now sink through the ground in shame!

Is that just like the shared memory model of parallel computing or are there any added complications? Have you done this before? Please do share your experiences if so cause now I’m interested :p

FreeRTOS tasks are basically processes, IIRC other rtoses have similar mechanics too

if(condition) statement; Is valid in typical C-style syntax.

if condition { … }

Is invalid in typical C-style syntax

1. several languages that are still in use have eager evaluation.

2. I’m a dumb programmer. The more I need to keep implicit behaviour in mind, the higher the probability I’m writing bugs. Short circuit evaluation is an optimization technique IMO and shouldn’t be relied upon for control flow.

3. The aggressive tone you’re using is completely unnecessary and immature, so I’ll refrain from responding any further. Have a nice day.

https://en.m.wikipedia.org/wiki/Short-circuit_evaluation

Yes I am serious.

1. That’s behaviour that’s just part of language design. If you rely on it you should probably check how the language you’re using handles it.

2. relying on that behaviour sounds a lot like “clever” (read unnecessarily unreadable) code

Flipping burgers is enough to pay for chemotherapy. Src: am european

How did a bug with something like that never pop up in unit tests?

Always practice safe stacks

The typical arguments for a dynamic typed language are that it takes less time to write something in it.

The benefits of static typed languages are that your development environment can be a lot smarter (ironically enough leading to faster development speed) and several classes of bugs being unable to happen. In a statically typed language, the IDE can detect if you’re trying to call a function that takes a number but you’re actually providing a string. In this case the IDE will let you know and you can immediately fix silly mistakes like that.

I am dumb. The more things I need to think about when reading code that is not the logic of the code, the worse it is. Any time I have to spend thinking about the peculiarities of the way the language handles something is time wasted.

I’ll give a very simple example, think like you’re trying to find a bug. Assume we’re in a dynamic language that allows implicit conversion like this. We can write our code very “cleanly” as follows:

if(!someVar) doSomething();

-> ok, now we gotta check where someVar’s value is last set to know what type of data this is. Then I need to remember or look up how those specific types are coerced into a bool.

When trying the same code in a statically typed language that doesn’t do implicit coercion that code will fail to run/compile so probably you’ll have something like this:

if(someVar.length() == 0) doSomething();

-> this time I can just look at the type of someVar to see it’s a string and it’s clear what the condition actually means.

The second option is both easier to read and less bug prone even without the type system. It takes maybe 3 seconds longer to type, but if your productivity in coding is that limited by typing speed then I envy you