![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
Technically this is also possible with for loops, like with OpenMP
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.
Also surely a lot of people would know tar -Create Ze Vucking File and/or tar -Xtract Ze Vucking File
The skerton was (is?) A good entry level grinder that will give you very decent results especially for immersion-type brews. It’s what I started on and what I still use for on the go use cases. I haven’t looked at entry level hand grinders in a while so I guess some developments have happened since I got mine. (Based on a comparison video from james hoffman at the time)
God yes, I tried a friend’s 1zpresso and the difference in both grind speed and effort is noticable.
You mean that instead of having a binary blob you have a generator for the data?
Depends on how deep down the rabbit hole you want to go :p
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.
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
several languages that are still in use have eager evaluation.
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.
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.
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.
relying on that behaviour sounds a lot like “clever” (read unnecessarily unreadable) code
I see, so I’m assuming the same goes for regular actors? And musicians? And basically any performer ofcourse? Oh and also anyone who does manual labour because you are literally renting out your body for that. Well, and technically anyone with an office job too because they are still renting out their time.
To answer that question it might be useful to ask a different question: “If people depend on money to survive and if that money is made through manual labour. Does this imply that manual labour is slavery through coercion?”
Dot in dutch is punt
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.