“Coding is basically just ifs and for loops.” • Hacker News Board

Re: “Coding is basically just ifs and for loops.”

#241

Post by kaba0 » Sat, Dec 04, 2021, 10:55 PM UTC

kbenson wrote: post #144

CuriousCosmic wrote: post #105

Earlier quoted context omitted.

Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In languages and libraries that allow FSM and pure functional kernel based designs you can get just as clear logic that is expressible not just to the…

In a very real way, it's all conditional jumps in assembly, and every thing you've learned to make programming easier by allowing more directly letting you express your high level intent is just sugar. It might even help some or most of the time. But what you're actually doing is creating a bunch of branches and loops, and as much as the high level stuff might help, you really shouldn't forget this is the medium you…

Programming is primarily about managing complexity. Other than perhaps mathematics, there is no other field that must, should and can apply the amount of abstraction on top of abstraction as software engineers do.

It is a must, because decades of business requirement built on top each other without understanding the whole is complex. Writing a JIT-compiler that can routinely change between interpreting code and executing it natively, a database optimizing queries, a mathematical library using some fancy algorithm are all complex, in a way that is not reducible.

Complexity easily outgrowth even the whole of our mathematics, we can’t prove any non-trivial property of a program, halting problem, etc.

So all in all, no, we can only respect our “base materials” by finding the proper abstraction for the problem, as our base material is complexity itself. It might be for loops and ifs, but it very well be a DSL built on top of who knows how many layers, because at that abstraction level can we even start to map the problem domain to human consumable ideas.

Re: “Coding is basically just ifs and for loops.”

#242

Post by rzzzt » Sat, Dec 04, 2021, 10:56 PM UTC

reikonomusha wrote: post #220

rzzzt wrote: post #215

Earlier quoted context omitted.

Oh, but CPU instructions can be built up from a series of μops which are then executed out of order or in an overlapping fashion, making both "instruction" and "state" boundaries in your equation more fuzzy than it looks. So at the absolute-absolute bottom of "code", it is instructions for an abstract model of an interpretative device.

(I'm not sure if your "but" is a retort, or an addendum. Assuming retort...) We can consider one more level of implementation machinery, but I fail to understand how uops aren't another form of instruction, and CPU internal gobbledygook like register files, caches, etc. aren't another form of state. It doesn't seem so fuzzy.

The difference is that you don't get to access the uops machine, subsets/sequences of that instruction set are offered as (macro-)instructions instead. Programming happens on the idea of a CPU.

Re: “Coding is basically just ifs and for loops.”

#243

Post by kaba0 » Sat, Dec 04, 2021, 11:00 PM UTC

marginalia_nu wrote: post #112

CuriousCosmic wrote: post #105

Earlier quoted context omitted.

Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In languages and libraries that allow FSM and pure functional kernel based designs you can get just as clear logic that is expressible not just to the…

> Personally I disagree. We should be using state machines and pure functions. If+for loops are just what's easiest to express in the major languages of today. they are no more or less computationally expensive but due to lack of tooling they are often cheaper to write. In my experience programming programming with primitives and basic flow control operations frequently tends to be at least be order of magnitude fast…

Will your manually written imperative code beat an SQL database for the same task? Because it uses a very very high level description on what it has to do and chooses an appropriate algorithm for that for you.

You can optimize one specific query (quite painstakingly, I believe) to beat a general db, but it is very far from clear that “for loops will beat higher level abstractions”, imo.

Re: “Coding is basically just ifs and for loops.”

#244

Post by rackjack » Sat, Dec 04, 2021, 11:00 PM UTC

KineticLensman wrote: post #185

freyir wrote: post #139

Earlier quoted context omitted.

New developers write simple but shortsighted code. It gets the job done, but it will be painful to work with in the future. 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-co…

Q: What's the difference between a novice and an expert? A: The novice thinks twice before doing something stupid.

I don't understand this saying.

Re: “Coding is basically just ifs and for loops.”

#245

Post by egypturnash » Sat, Dec 04, 2021, 11:03 PM UTC

klyrs wrote: post #117

UGH. Back in my day the only language was BASIC and we only had IF and GOTO. Dijkstra has made these children SOFT and I'd piss on his grave if I could be arsed to get out of my rocking chair.

What version of Basic were you using that lacked FOR? Even the shitty one crammed into my Sinclair ZX80 had FOR.

Re: “Coding is basically just ifs and for loops.”

#246

Post by Connor_Creegan » Sat, Dec 04, 2021, 11:03 PM UTC

Ah, keen observation, young grasshopper! But nota bene: just as man cannot live on bread alone, one's understanding does not arrive merely from the consideration of a collection of atoms.

Re: “Coding is basically just ifs and for loops.”

#247

Post by rackjack » Sat, Dec 04, 2021, 11:04 PM UTC

HerrMonnezza wrote: post #151

Well, quite: if you add that code must run sequentially it's the Boehm-Jacopini theorem: https://en.wikipedia.org/wiki/Structured_program_theorem

Pure functional programming languages take this a step further and say everything is just composition. (From my understanding)

Re: “Coding is basically just ifs and for loops.”

#248

Post by ChrisArchitect » Sat, Dec 04, 2021, 11:04 PM UTC

While Carmack is law, don't think this was worth a share here, as it was just a cute thing a young kid said? Only slight jokey whatever

Re: “Coding is basically just ifs and for loops.”

#249

Post by mslot » Sat, Dec 04, 2021, 11:05 PM UTC

Good code explains the problem to the reader and implements the solution as a side effect.

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 (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.

Re: “Coding is basically just ifs and for loops.”

#250

Post by kaba0 » Sat, Dec 04, 2021, 11:06 PM UTC

mbot5324 wrote: post #100

reikonomusha wrote: post #95

Earlier quoted context omitted.

Really, there are no if+for, just compare and jump. Why don't we use what the metal uses, instead of these "expressive abstractions"? If+for have no deeper foundational significance in the construction of programs or computations, literally, than say a lambda function. But because the latter is unfamiliar, it's spoken about in the same manner you present: as if it is some highly abstract, complicating, high-level fea…

> as if it is some highly abstract, complicating, high-level feature But symbol calculus is a highly abstract, complicating, high-level system assembled out more reality-based systems beneath it. If it seems simple to you, you're just under the curse of knowledge.

Which without side effects can be very heavily optimized (probably even better) than imperative code? Hell, the pipelining inside GPUs, and CPUs are perhaps closer to lambda calculus than Turing machines.

It’s not like the machine code will look much closer to your C code either. That’s also a spell of “compiler writers and hardware vendors trying to uphold the view that C programmers are so close to hardware and that memory access is flat”.