Basically it means that in the beginning we punch like we can.. then a martial arts student learns the proper and different ways to punch.. so a punch is no longer just a punch... Is a lot of instructions.. Then to sheer practice and repetition the right way to punch becomes second nature.. so the right way to punch is the only way so it's only a punch again.
So coding it's just ifs and loops... Then is OOP and Functional and Logic... But then once you transcend all those paradigms you understand that is all ifs and loops.
Translation from http://www.livinglifefully.com/zensayings2.htm
:)
Seems like we lose a lot of good technology and progress for random reasons, like the “ram” of society is finite.
assembly instruction + machine state => new machine state
Our idea of "jumping around code" and "control flow", as in for loops or if statements, are themselves abstractions of control state (an instruction pointer) and data state (perhaps a CPU register).
So coding is really "the execution of a notional interpreter (aka semantics), then $foo." That gets to the absolute bottom of what "code" even is: instructions for an interpreting device (be it physical or mathematical).
list.stream().filter(Objects::nonNull).map(User::getUsername).filter(Objects::nonNull).filter(name -> name.contains(searchString)).map(name -> “We have found your user: “ + name).orElse(“We haven’t found”);
Basically unreadable.
for (User user : list) if (user != null && user.getName() != null && user.getName().contains(searchString)) return “Found it!”;
return “Not found”;
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))
EDIT: I should have used filter(list fn) here, I was trying to write something plausible in JS instead of a purer functional language and misses that translation.
In a list
John
Jonhatan
Joy
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 more familiar with the second style, but pipelines are better in many other ways, clarity of intentions being one of them.
https://esolangs.org/wiki/Pancake_Stack Pancake stack doesn't need this hipster crap like functional programming or ifs or fors.
But the stream interface is just horrible. I had to read a lot before I understood how to just filter a list and collect the results. And even after that, it still somehow didn't scream out what it was doing to me. I guess you get used to it.
users.find(_.name.contains(str))These are all from the Zen philosphy, it says:
When getting start with Zen, I see hill as hill, water as water When get experienced with Zen, I see hill as more than hill, water as more than water. When finally got mature with Zen, I once again see hill as hill, and water as water.
https://twitter.com/nice_byte/status/1466940940229046273
The more I do this, the more I gravitate towards the simple things.
Intermediate developers, bitten by their past mistakes, decide to future proof their work. But they don’t just look one or two steps ahead, rather they try to look five steps ahead and identity problems that do not and may never exist. Consequently, they over-engineer, over-abstract, and over-complicate everything. Carmack’s recent “But here we are” speech resonated with me.
Advanced developers identify the right balance for each task between simple and complex, concrete and abstract, and pragmatic and idealistic. In my experience, they favor simple and pragmatic solutions, use abstraction effectively, and can satisfy near-term goals quickly without painting themselves into a corner. “As simple as possible, but not simpler.”
I try to avoid working for tech leads stuck in the second phase, which is not uncommon. If you suggest taking the “ifs and for loops” approach of solving a simple problem with a simple solution, they’ll assume you’re on the wrong side of the bell curve.
Debated for a long time whether that methodology was stuck in the second phase or if it was actually the third. Still don't have an answer, but these days I think having a plan is better than just letting engineers run roughshod, as long as the conventions are easy to follow.
A: The novice thinks twice before doing something stupid.
https://motherfuckingwebsite.com/
Where does this fall?
Everything is as simple as it can be, no simpler and no more complex. Sometimes a bunch of flat JSON files in an S3 bucket is enough of a database, you don't need a 42 machine Aurora cluster.
All fancy "Machine learning" stuff really is just a bunch of ifs and for loops internally :D
Watching this right now and all I can think about is Microsoft Bob.
I have no beef with if+for, but a large part of the reason they're "goto tools", if you will, is because industry is slow to assimilate many state-of-the-art ideas, sometimes by as much as 40 years.
Simpler building blocks does not necessarily mean simpler solution. If only!
This comment sure indicates to me where you most likely are on the curve.
In all seriousness, I think this is considerably off the mark. After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, bugs, tech debt, even the downfall of organizations and products.
Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar.
I try to keep a healthy and balanced diet, myself.
> industry is slow to assimilate most state-of-the-art ideas, sometimes by as much as 40 years.
Most of those ideas are terrible. The industry is so incredibly young and has experienced so much change over those 40 years that I have a hard time accepting the notion that the industry is slow to adopt. The reason the old building blocks are still popular is because they are a thin abstraction over how computers work, and ultimately that is at the root of everything we do.
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 consultants who do the same work for multiple companies and realise the repeating patterns and extract an abstraction.
For assimilation to happen, the state-of-the-art solution also has to result in a net gain over the existing solution, and the higher the differential in complexity between the two, the bigger that gain has to be.
I see what you did there.
Isn't this just a complicated case of ifs and fors?
For example, how do you handle authorization, logging, and how do you make the code maintainable? That's a really tough problem that requires a lot of thought about the overall system design.
And of course it's always a lie to say that performance and resource usage aren't a concern -- they're not a concern until they are.
How convenient that the software industry is about 40 years old. So these ideas should "break through" this invisible arbitrary corporate waiting area into the limelight any day now, right?
- you don't need to write classes for everything
- it's okay to write something in a more verbose way to make it clear for other people
- your tools don't need to be perfect to get things done
I need more of these, maybe some that aren't as reductionist as Carmacks's original post.
https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...
In rare cases I pull out a real debugger, but most of the time the right prints in the right places are just as good. I can also iterate much faster because I'm not jumping between the code the the debugger, or pulling the debugger out of the loop it's stuck in.
“Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick.”
not my favorite source since it doesn't go into the 'scaling the mountain' bit, but every source that talks abt that part seems to be...eh: https://buddhism.stackexchange.com/questions/15921/what-is-t...
We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.
T. S. Eliot - Little Gidding
Like them, I left a settled life, I threw it all away
To seek a Northwest Passage at the call of many men
To find there but the road back home again
Stan Rogers, "Northwest Passage"
Anyone who has ever written any software has felt like the unenlighted half-person in the middle of that distribution at least once -- for example, when learning how to code with a different approach in a new language.
I have felt like that more than once. Everyone here has, I suspect.
--
[a] https://twitter.com/nice_byte/status/1466940940229046273/pho...
but you hear those $fancy_principles / fp / hard oop / "clean code" evangelists, and then you go to any repo of real world software - linux, compilers, kubernetes, git, blablabla and everywhere you see for loops, goto, ladders of if statements
Also, let’s be honest, C does all these “virtual method” magic on a per-project basis which will not be understood by any tool ever (all those function pointers to whole new implementations passed from God knows who, with barely any typing). At least FP and OOP knowledge somewhat transfers and is queryable by tools.
"...there's way too much information to decode the Matrix. You get used to it, though. Your brain does the translating. I don't even see the code."
I describe this path of discovery as:
beginner: function over form
intermediate: form over function
transcendence: form is function
However, I will disagree that coding is just about ifs and for loops. To me, coding, programming, software development, or whatever you want to call it is about three things: how to use a computer to do something, communication between people (including your future self), and how to think about a domain. “ifs and for loops” does not capture this.
Like everything Hotz says it's spiced up of course, but there's a kernel of truth to it.
The choice quote in contrast to Hotz is "executing recipes is unbelievably efficient -- if it's what you want to do"
As a senior software engineer i had to spend a lot of time at night fixing code written by junior devs and interns.
the code that company and devs (just ifs and loops gang) proud of was a pain in the ass for me so i quit the job entirly and do freelancing these days.
I tried to explain how something was wrong and why but no one would listen all believe they were 10x developers, Life lesson learned, never ever try to correct an idiot.
Here are some of the practices they followed * No indexes on tables, not even unique * No DRY, NO KISS * Switching to new shiny framework/library every week * no tests * Keeping entire codebase in a single file (4k LOC) * no versioning * Exposing DB credentials to the entire internet and not acting when being warned
Writing code that works is simple. Writing code that doesn't break is not simple.
[1] either a policy like strict code review or perhaps a cultural change about quality or responsibility or mentorship.
Companies thought they were saving money and devs thought they were born coders so no to read a book on software architecture/engineering and hence i had to deal with the big pile of ....
Can it do something multiple times? (LOOP)
Can it change a piece of data?
Congrats, it's Turing complete.
Sequence, selection, iteration (or recursion if available).
Note that the child overlooked the assumption that it's sequential.
I started in GW-BASIC when I was a kid, and all I needed was IF and GOTO. You could do anything with that. No loops, no functions, no nothing. IF's and GOTO's!!!
Sure, that's oversimplifying it, but that's the smallest unit of information being changed during computation.
But yes, once you learn the basics that are shared between most programming languages and don't get distracted by the nuances, it doesn't take that long to pick up a different language. Being proficient is of course another question, but achieving a basic understanding shouldn't take all that long when you just focus on how to if-else, how to setup loops, and how to assign variables.
I see coding as playing with hardware without having to use soldering iron.
Simple != easy
Coding is just copy and pasting boilerplate code and googling how to make it work.
10 PRINT "POOP"
20 GOTO 10
But, you've got me curious. I recall using BASICA, GWBASIC and QBASIC -- reading over their respective histories, I'd have gotten my start on BASICA on a hand-me-down 286. I'm not finding good docs on the language, but a familiar program [1] uses FOR loops -- so they were supported. But I distinctly recall hand-rolling a for-equivalent loop with GOTO and IF, counting down to zero.
[1] https://web.archive.org/web/20130918210121/http://www.coding...
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.
0 - http://www.willamette.edu/~fruehr/haskell/evolution.html?
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.
They look like concise programming for mathematicians, which in my opinion, is tending towards set theory notation. https://xkcd.com/2545/
Personally I prefer more names, more XML tags, more comments, more parables, more hyperlinks, more different ways of expressing the same thing, to make it less ambiguous and easier to communicate and agree what we're all talking about.
That's why it's pedantic idiot savants who tend to be the best coders
You can often express the problem quite well using a combination of if, for, comments, variable names, function names, list/set and map data structures.
Sometimes (<10%) you encounter a problem that's interesting enough to define a custom type, and sometimes you make tree data structure out of it (<1%). On very rare occasions (<0.1%), you need a more complex data structure.
Code that uses thousands of classes is very hard for a reader to approach, but so is a single file with a never-ending ifs and for loops. Always write code for another person. If nothing else that other person might be you in a few months (or much sooner).
Coding is basically just writing for humans in a language a computer can execute.
Learning from Artificial Intelligence’s Previous Awakenings: The History of Expert Systems
(with a smile on his face and shrugging his shoulders)
I often find myself writing simple things with a compact-but-high-level-conceptualization, that when edited by someone else, clearly only saw the rain.
At first, I thought it wasn't as readable, but now that I'm used to the syntax, I think it's much easier to parse what happening. I know what transformation is happening, and I know there shouldn't be any side-effects.
Almost no one nowadays possess these skills. I we have is node_modules crap and J2EE-like design bullshit.
This like saying that poetry is just words and commas.
But he is just a kid, I know. ;)
Calculating the square root of a number is ifs and loops but wouldn’t be much fun without the math.
Many of them are much smarter than me, but I think my insight which I remember getting around 6 months in is that it's just code, in many places hard to read/follow, but it will ultimately just do a logical set of instructions.
It’s basically that, plus resource management.
Both involve filling up your mental stack.
Also, you can easily see that something is fishy because all such code must terminate (where's the halting problem here?)
https://en.m.wikipedia.org/wiki/Primitive_recursive_function
Otherwise I completely agree with the aphorism.
Maybe, he knows only that much, yet