Then what the fuck is a monad?!? Seriously I still don’t know what a monad is and apparently it’s just a bunch ifs and for loops, so I guess I’m pretty stupid.
It's what you add to a search to get more interesting answers on Google.
“Coding is basically just ifs and for loops.”
371–380 of 418 posts
Re: “Coding is basically just ifs and for loops.”
#372And types.
Re: “Coding is basically just ifs and for loops.”
#373Then what the fuck is a monad?!? Seriously I still don’t know what a monad is and apparently it’s just a bunch ifs and for loops, so I guess I’m pretty stupid.
It's like if you wrapped every statement ending in ; in a C program with the same macro.
Re: “Coding is basically just ifs and for loops.”
#374Coding is basically just ifs and for loops.. But software engineering (or development) is much more than just coding.
Isn't software engineering pretty much ifs and loops too? Massively complicated ifs, and looping pretty much samething over and over again.
The part that does stuff is just ifs and + signs. But making a computer do stuff isn't hard; that's what they're for. The problem in software engineering is stopping it from doing the wrong things.
(Hot take: the way we do this is wrong; we should be adding superpowerful not-doing-stuff features to languages, vs doing-stuff features.)
Re: “Coding is basically just ifs and for loops.”
#375joke aside. we know a language is Turing-incomplete if it has only ifs and bounded for loops. And if 90% programmers' tasks can be done using a Turing-incomplete language, is there any benifits we can get from this?
for loops aren't bounded though; that's for...in loops. for loops you write your own stopping condition, which was probably a mistake.
Re: “Coding is basically just ifs and for loops.”
#376His mind will be blown to lean it all runs on protons, neutron, and electrons.
There's 57 elementary particles in the Standard Model.
Re: “Coding is basically just ifs and for loops.”
#377Earlier quoted context omitted.
It’s just so sad that the lowest common denominator has become the standard now. When I first learnt Clojure it entirely changed the way I think and solve problems. The code really was elegant. Obviously, it can only be read by someone who can also understand programming beyond ifs and fors. That’s a non-starter in most environments - enterprise or otherwise. Funny enough, I see most innovations coming from consultan…
Ifs and fors are the easiest concepts to explain to non-developers, so it makes sense to start there. I wouldn't say that they are the standard now, but using and mastering all features in a language is hard. Add to that design patterns, classes and code layout it becomes a full-time job to keep up. I have been in contact with code most of my professional life, but still isn't comfortable writing large amounts of cod…
C# was good enough for me at version 4.0. I use many of the newer features but they seem to be well into the law of diminishing returns now.
Re: “Coding is basically just ifs and for loops.”
#378Coding is basically just zeros and ones.
Re: “Coding is basically just ifs and for loops.”
#379Earlier quoted context omitted.
the two snippets you posted do different things In a list John Jonhatan Joy searching for "Jo" returns all three of them in the first example, it stops when the first has been found in the second. Start including the tedious bits about adding found items to the list and the waste of intermediate variables and your "clear" code is wrapped around a lot of repetitions, that only add noise. It just happens that you are m…
The code he posted isn't actually valid because you can't "orElse" a list. That being said, I would presume it was meant to include a "findFirst". Something like list.stream().filter(Objects::nonNull) .map(User::getUsername).filter(Objects::nonNull) .findFirst(name -> name.contains(searchString)) .map(name -> “We have found your user: “ + name) .orElse(“We haven’t found”);
exactly, that was the catch.
the point I wanted to make is that the snippets presented seem carefully crafted to make pipelines look bad, but usually that's not the case.
Re: “Coding is basically just ifs and for loops.”
#380Earlier quoted context omitted.
>and you have to read it all to find out what it does. Which isn't a problem, because as long as its all loops'n branches, the code is easy to understand.
Hard disagree. For loops do not have guarantees about in-place mutation; that’s why they require a full read. Anything that starts with a map/filter is guaranteed to only apply to the thing that it is assigned to. That’s more than worth its weight in grey hairs. EDIT: “full read” includes “everywhere else this array is used, which can have far-reaching consequences if it was passed into the containing function by ref…
>For loops do not have guarantees about in-place mutation;
Every modern language has a `for elem in range` construct, giving exactly that guarantee, as long as the element isn't a pointer.
Besides, I neither want nor need such a guarantee. There are many scenarios where in-place mutation is exactly what I want to do in a loop, and I don't want to fight the language, aka. my craftsmans tool, to do it, just because it imposes an arbitrary restriction on what I can or cannot do.
Is this a potential source of bugs? Of course it is. That's why I have tests, code reviews and debuggers.
And besides, nothing prevents me from doing the functional approach in languages like Golang, Python or Julia *if I want to*. I simply refuse to use languages that that force a paradigm on my code. This is true not only for "pure functional" languages, but also Java, which wants me to use OOP everywhere.
To me, paradigms are tools. They need to be there when I need them, and get not get in my way when I don't.