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.
“Coding is basically just ifs and for loops.”
291–300 of 418 posts
Re: “Coding is basically just ifs and for loops.”
#292Earlier quoted context omitted.
I started off writing a lot of 68000 machine code. I was always amazed what you could accomplish with a lot of loops and branches. I never lost that sense that at whatever higher level I was at later on, it was all loops and branches.
Reminds me of biological metabolic systems. All loops and branches…
Re: “Coding is basically just ifs and for loops.”
#293Earlier quoted context omitted.
I started off writing a lot of 68000 machine code. I was always amazed what you could accomplish with a lot of loops and branches. I never lost that sense that at whatever higher level I was at later on, it was all loops and branches.
Have you seen this? https://news.ycombinator.com/item?id=25788317 Seems like we lose a lot of good technology and progress for random reasons, like the “ram” of society is finite.
Re: “Coding is basically just ifs and for loops.”
#294Earlier quoted context omitted.
You're confusing computer science with writing software to run on hardware. Coding requires the latter, but not the former.
Oof, and to think one could helpfully inform the other! :) To be clear, I am a programmer, not a computer scientist, so my opinions are based off writing code and managing teams to write code that works, and less so about abstract machinations of computer scientific thinking.
I think the reason that stateful, imperative code is the default is because that is how we tend to "think". Example, if I wanted to get a list of items for the grocery store, I get a piece of paper (instantiate an array), go through the list of things I might need (loop through a source array) and write down the ones I definitely need (append onto the destination array). If I run out of space, I get a new piece of paper and continue the process.
With that algorithm, I can stop and test each individual statement; I don't need to "think about it" because I can write and execute a tiny part of it (even if I'm only executing it in my mind).
In a functional style, I have to think more declaratively. Given all my items, filter out the ones that need replacing and give me that list. It's much easier to reason about abstractly, but I have no details about w how that's actually happening.
I think this kind of thinking is superior most of the time: I would rather read map.filter.reduce more than a for loop with branch statements any day of the week, but I am trusting the implementations of the mapping and filtering and reducing functions. Of course, for any non-trivial algorithm one is still passing a function into the map/filter/reduce anyway so I can still reason about those smaller stateful sections without worrying about the map/filter/reduce piping.
Perhaps I've never worked in a truly pure functional style so I may not be dealing with the mountains of abstractions others seem to complain about
Re: “Coding is basically just ifs and for loops.”
#295I also like "all web development is basically fancy string concatenation", and as a web dev I feel seen.
George Hotz said something once that most modern developer jobs are depressing because you're not doing any actual programming. I.e. you're not given a problem to solve with code, you're just taping together frameworks and pieces of code that someone else wrote to order. It's a bit like studying to be a chef for five years and then having to put together one of five types of burgers. Like everything Hotz says it's sp…
Re: “Coding is basically just ifs and for loops.”
#296Re: “Coding is basically just ifs and for loops.”
#297Earlier quoted context omitted.
Had a boss once who insisted that all if statements should be pushed out to factory classes, and all control logic should be done by constructing a different instance of an interface. It was a pretty rigid system, but at least it did force me to write small focused classes that were easy to test. Debated for a long time whether that methodology was stuck in the second phase or if it was actually the third. Still don'…
Programming alone vs programming in a team are very, very different occupations. A lot of what applies to one doesn’t apply to the other. I’m still painfully learning this, after all these years.
Re: “Coding is basically just ifs and for loops.”
#298Earlier quoted context omitted.
That’s what disappoints me in modern Java. There is practically no ifs. It makes it inaccessible to beginners on the project, and the streams are about twice as slow… just because devs think they are more clever if they pile 7 “.map()” to transform a list. list.stream().filter(Objects::nonNull).map(User::getUsername).filter(Objects::nonNull).filter(name -> name.contains(searchString)).map(name -> “We have found your…
That’s a failure of Java’s language design, not a failure of the functional/declarative paradigm. Your for loop can do all kinds of damage to the list, and you have to read it all to find out what it does. Saner languages make the functional version more expressive.p: return first(users.filter(u => contains(u.name, searchString)) I’m not saying JS is a sane language; it has an anemic standard library without a robust…
Re: “Coding is basically just ifs and for loops.”
#299In my twenties, I wanted to use all the cool PL techniques: meta-programming, reflection, monads, macros, type-level programming, etc. I'm getting older and now I want my programs to be 90–95% functions, arrays, structs, enums, and loops and only parsimoniously throw in more advanced language features.
Super basic imperative typed language with maybe some kind of nice way of handling nulls and that doesn't use pointers ... is most of what we need.
Everything is very expensive optimization.