/tech/ - Technology

Not necessary, programming books are literally perfect, teaching has been solved, there's literally LITERALLY nothing you can do to improve it, read a book retard, you've never read a book before? Read some books idiot, read books. Programming books are perfect. If you go to dictionary to look for definition of "perfect", you find a picture of books because they do everything perfectly every time.

>>575
This.
>>574 (OP) 
The problem of teaching programming is the lack of fundamentals and motivation. 9 out of 10 CS graduates don't really know what a computer is. Yet they are going to write and maintain whatever crap users take. This is how SELECT * FROM x gets put into production. Kids are given and taught Microjew and Apple retard junks; instead of the infinite transparent possibilities of GNU/Linux or BSDs. A concept of blackbox rather than logical computational mechanics is implanted in their developing mind.
Instead of
<ERROR: Exception asdfasdfasdf
>Shit not working
>Feel the white hot rage against the nature and reality
>Fuck, search error message, dig into source
>Get it fixed
>Submit (share) fix to mailing list
It is
<ERROR: Something Happened
>Oh no! Something happened!
>Mum something happened!
>Dad something happened!
>Help me big brother Bill!
>Goto /tech/ and bitch
<STFW, gets b&
>Accept it doesn't work and never will
>Go back to (((social life))) and never know what happened
That is also where the motivation comes in. Under this knowledge-hostile environment, only those worthy of knowledge can break through this barrier and reach redpills and truths. Nature was stopping our advancement. Men cracked enough of its code to bring forth technologies and computers. It is (((them))) who extinguished that unstoppable flame against everything which stand in men's way. It is now up to individuals to ignite his own hatred, autism if you prefer, against what is taking our creativity and curiosity away. Read books and think more.

>>574 (OP) 
>Lack of structure
No, they just have old assumptions. If you got into higher education before the whole degree mill effect, you were assumed to have a lot of prerequisite knowledge already. Not so much now when you need a Bachelor's just to get a shot at entry level jobs.
>math's emphasis feels like it's either for magus-tier programming, or is so basic that it immediately fades into the background
Both are important and drilling those things into the brain is one's own responsibility - as that will make you a better worker than your peers. You may not need anything beyond Big O notation and entry calculus (derivatives and integrals, for example) for simple jobs, but to implement a new concept off a scientific paper into a program requires you to know quite a bit about the subject matter and things like numerical methods. After all, math is abstract and infinite, but computing resources aren't.
>I feel like I've learned all I can at this stage
>I've heard "just do it" or "practice dude"
That's quite literally the way. Have you seen a successful engineer whose only accomplishments were theoretical up to some big, perfect project?
>practice doesn't make perfect, it makes permanent
What about learning from your own mistakes? Nobody's gonna do it for you and code doesn't write itself. Most languages have tools for profiling it, so you can see where your program design fucks up. If the problem pool of your code is too small, boost all the parameters etc. I'm not going to give a parallel to art, since I can't draw to save my life, but imagine a residential structure. The reason it stands isn't because it was expertly crafted, but rather because the workers were good enough and the planning had lots of redundancies and overkill weight/tension/distortion limits placed. In programming terms, it's the design of a server that needs to serve 100 client simultaneously as if you were doing it with 1000 clients in mind.
>In conclusion, what is good programming structure?
/tech/ likes to shit on them at least 8/tech/ did, but you might be interested in books on design patterns. They have a bad reputation because of Pajeets who blindly apply them to unrelated problems, but they sound similar to what you are looking for. Another thing is to "read" other people's code. This is genuinely useful but also a fucking meme that I hate. It's not a book, "reading" it is more like solving a puzzle. So you'd need to look for repositories with well-documented and commented code, as opposed to reading some autistic retard's "expertly crafted so comments are not needed" C code.
>How can use it to be a better programmer and actually feel more than a just like a permanewb?
You'll always be that, in some fields of work. It's a side effect of how large the profession is. That's why you don't stop coding and trying to figure out why your programs run so slow compared to others or why your fastest solutions aren't applicable to generalized cases.

>I hear from programmers about how important math is- and I agree, but my problem with that, is that math's emphasis feels like it's either for magus-tier programming, or is so basic that it immediately fades into the background.
The immense value of a mathematical education lies more in the systematic approach to problems than any specific theorems or formulae. Not that I blame you for this misunderstanding, most "Math for CS" type books/courses teach nothing but theorems to memorize and routine calculations to perform, with absolutely no insight to be gained.

The comparison between art and programming seems pretty artificial; does it go beyond "both suck right now"? Programming is pretty young and large, so answering your question categorically will be difficult, but the closest to a fundamental structure of good programs I can think of is "simple orthogonal parts that are easy to reason about, combining to do what you want".

Orthogonality is well-known and frequently applied. Simplicity is probably the biggest one to keep in mind, simply because of the devastating effect large codebases have and because of how tempting it is to sacrifice it. Treat your code as a resource to be spent. The ease of reasoning is a bit harder to formalize, but imagine having to prove the correctness of your program. What would seriously hinder such a thing? Try to make invalid states completely impossible. Avoid case distinctions when necessary - the only way to deal with case distinctions is to distinguish cases yourself, and this adds up. This is where mathematical maturity becomes very helpful.

>I've heard "just do it" or "practice dude" but here's the thing: practice doesn't make perfect, it makes permanent. Trying to undo the damage of bad habits is effort on top of learning things the right way, the only saving grace is that is gets easier as you do it more. 
You won't get around it. At some point you have to start and gather experience, especially in a field that still has so many unknowns.

>>580
The (GoF) patterns get rightfully shat on because most are just workarounds for design flaws of C++ or Java. Strategies implement first-order functions, visitors work around the dumb linking of methods to one class, some other thing is an implementation of multimethods… It goes on and on. Without these flaws, most patterns simplify massively or just straight up vanish.

>So you'd need to look for repositories with well-documented and commented code
He'll be hard pressed to find any, sadly. Most open-source code is hot garbage, the only exception I can think of on the spot is musl. I feel like this is the real problem plaguing programming - it has no solid history it can stand on. Contrast this to mathematics.

>>585
>Most open-source code is hot garbage, the only exception I can think of on the spot is musl. I feel like this is the real problem plaguing programming - it has no solid history it can stand on.
I remember hearing a Lispfag claim that garbage collection gets its bad rap from shitty open source implementations and that all the good GCs are commercial. Conveniently, he did not cite a single example so nobody he was trying to convince could try any of these out for themselves.

>>592
I find that believable. Open-source devs usually only do the "fun" parts of development, and writing a GC certainly isn't fun. Meanwhile, companies with a serious stock in Java would be very interested in GC improvements. At the end of the day you'd have to ask him what he meant though.

/tech/niggers are low level insects that cannot do programming right in the first place. what makes you think you are separate from the academic-industrial-nigger-computer-complex?

Speaking of structure, what does anon think about design and modeling languages? Things like TLA+, UML, DRAKON, the list goes on. I read some things about TLA+, for example, but it seems to be geared towards people who work on mathematically proving pieces of code and are already very experienced with programming. What about the dumpy average coder who wants to document his project? It's always nice to have more than code to rely on for an top-down look. Are pseudocode and some flowcharts all that is available?

Doubt.png
[Hide] (37.4KB, 300x162)

>>619
It's called Taking Notes,as you unintentionally managed to realize the extra cruft of formal documentation methods are useful only to academics or middle management attempting to sound good through usage of buzzwords.
Just comment your code and keep a separate file/notebook with larger design ideas.

I think that bad design is really just a symptom of common management strategies for software projects. From what I've seen in industry, non-technical people will tend to just throw pajeet-tier codemonkeys at problems and get a senior dev to bandage everything together until it works. When I look at OOP/webdev/enterprise best-practice advice, it just looks more like tard wrangling than engineering. You make sure that your monkeys have lots of busy work to prevent them from competing too aggressively and destabilizing the team. It's retarded as an engineering practice, but it's stable at an organizational level. Unfortunately, the people who created the kool-aid started drinking it, and now many solo and open source devs do too.

Good design really comes from having a small team of half-decent developers. It really isn't that hard so long as the scale of the project can be kept in one person's head. Once you are working on a team with dozens of people, every piece of code will begin to depend on every other piece of code and you will no longer be able to fix these redundancies, or even recognize they exist. This is why we have ugly, bloated pieces of shit like Chrome/Firefox, Windows/Linux/Mac, OpenGL/DirectX and so on.

Early software in the amiga days could achieve the vast majority of what we do today, with the main limitations being the throughput of the hardware itself, not the software. There were some suboptimal design choices of course, but nothing that could not be ironed out with time. Think of C transforming into C++. C was imperfect, but it became very popular because it had just enough features to be useful. Most of these features were guaranteed by the standard, and simple enough that anyone could work with a standards compliant subset of the language. Then people began to move to C++, which quickly began to grow the standard library, adding more and more features. Now there are multiple incompatible ways to allocate memory, crazy overloading and name mangling behaviors, obscure minutiae and so on. In a sane world, the C standard would have just been amended with something like namespaces/modules and then frozen. A new language standard could have been forked from the original, focusing on fixing design improvements that might break backwards compatibility. Instead we now have dozens of shitty, popular, poorly standardized languages. If you want to write a piece of software and compile/run it a decade from now, your only choices are basically C99 or C++98.

The endless churn of shitware built from other shitware is perpetuated by an industry where developers have an incentive to create future work for themselves. If they actually did good design, the entire silicon valley tech bubble would collapse. That's the real reasons why OS's and languages need to constantly grow and update.

Related talk by Casey Muratori, gives some pretty decent examples backed with quantitative data:
https://www.youtube.com/watch?v=kZRE7HIO3vk

>>624
This is a very good post that gets a lot right, especially the fits in one head part. My only complaint is that
>Most of these features were guaranteed by the standard, and simple enough that anyone could work with a standards compliant subset of the language.
is revisionist fiction that mistakes the/a source of the problem for its solution. Absolutely nothing written in C back in the day was standards-compliant, despite the fact that the standard was basically just "whatever the compilers did is now officially sanctioned". Even nowadays you will have a hard time trying to find anything non-trivial in standard C. The language as it is on paper sucks massive dong, and that's one of the big reasons you have the current tower of Babel: Its creators tried to fix the dozen deficiencies of C that bothered them the most, and each of them worked on a different subset.

>If you want to write a piece of software and compile/run it a decade from now, your only choices are basically C99 or C++98.
Or any other of the less popular languages that have a standard and lack retard implementors breaking shit for no reason. I recently used a Common Lisp library written in '99, it worked without modification now as it worked then.

>>639
Inexperienced I may be, what are the deficiencies of C?
Compare to most other languages, C is simple, small and performant. Of course there are many ways to improve, eg multi-threading. How would you design the best language?

>What I'd like to know, is how this can be paralleled to it's programming equivalent. 
It can't be, really. Apples and oranges (though that's far too close, since they are both fruits).

Art fundamentals are based on the commonly-understood notions of time and space, light and dark. We both have to live in this world from birth, but for thousands of years these things have been discussed and written about from a a priori 'oh everyone takes this or that for granted, ofc.

Coding is much more like solving word problems in math. Not everyone is cut out for the mental challenges of puzzle-solving well, but everyone can walk outside and appreciate the grandeur of a mountain vista. Trying to conflate the two is fundamentally misguided IMO. 

But if you're just asking for good software coding guidance, then keeping things orthogonal and paying attention to BigO will take you 90% of the way there. A) things must be composable to create large systems that don't become insane hairballs of spaghetti code (orthogonality), and B) no one wants to use code that runs like a sluggard (BigO).

fb1aa8afebf60fdc237b10da1340b711504a9887f3b791c5162420b96bd22b71.png
[Hide] (129KB, 1028x825)

>>640
>How would you design the best language?
By enabling the smartest bunch to break away from the stick-in-the-mud crowd and devise their own rebel cause. And then give that cause some teeth. Best example of this process that I know of:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
  -click 'Turn ON syntax'

>>640
It's the poster child of the New Jersey style. Everything is optimized for being easy to implement, correctness and ease of use be damned. Its standard is written so that the naive implementation will be legal, which gives beginners the false impression that C is this naive implementation, but compiler vendors do all kinds of things that the standard allows but fly in the face of this internal model - some sensible, some batshit insane. The users eat it up because they're used to the abuse.

Almost all problems with C stem from this. Even though every integer type in C is fixed-size and therefore suffers overflow issues, C provides absolutely no facilities to handle them. It's no joke easier in Assembler than in C. Error handling is a lot of work so it's left as an exercise for the user, with ridiculous costs because C implementations don't fail safely. They basically can't fail safely because the language abuses pointers for everything, conflating several different concepts: References, return values, arrays, optional values, probably even more that I don't remember offhand. The array one is especially insidious because it hinders automatic bounds checking.

Years ago, when I thought that C was a great language for expert programmers and the people complaining were just shitters, I tried to write an RPN calculator in pure standard C, without compiler extensions or undefined behavior, that correctly handles all errors. I expected this to be a fun little exercise. It was complete fucking torture and I can only recommend it: It will cure you of C enthusiasm forever.

Later, I tried to interface automatically with C to get away from it, only to realize that because it leaks implementation details all over the place, doing so is completely impossible. This language is a scourge on humanity.

>How would you design the best language?
Nevermind best, I'd be happy already if they stopped repeating the same mistakes for 50 years. Ada and Common Lisp got a lot of things right and were promptly ignored.

>>643
C provides a computing environment that do things in a certain way. A good understanding of this environment enables one to be a good C programmer. Integers and pointers are not inherently designed to accommodate programmers, they are there as a part of the "C model". Analogous to an animals trainer working with dangerous beasts, there is no safety provided by the beast because they are how they are.

>References, return values, arrays, optional values
Being the commander of silicon machines, it should be the programmer's job to write programmes according to machines, instead of the programmer's thoughts or the weekly language on Reddit. C tries to model how processors generally were at the time. It failed because there are no "undefined behaviors" in real computers. But the model, albeit inaccurate, proves to be useful enough for compiler writers and programmers.
C didn't conflate those concepts because they exist not in C, but on the CS ivory tower. Programmers that think otherwise is speaking Japspeak with English grammar and complain about Japs being weird.

Of course, computers are man made for serving men. That means the environment can be modified relatively easily, or is it not? Processors have stopped following Moore's law years ago, multi-core design exposes the inevitable speed of light limit, node shrink getting rarer. There is little room for hardware vendors to side with programmers (instead of the nature) more than they do now. Even C is not immune to this development. Further and further, processors drift away from C's initial model. Multi-core processors are common, out-of-order executions, and other hardware magics BTFO the C model all together. 

A new language needs to be developed. General enough for different architectures, but still recognize and exposes arch-dependent functions. High-level enough for programmers, but low-level enough for bare metal optimizations. A language should be programmer-friendly, but not at the expense of over-abstraction and information hiding.

>>640
>How would you design the best language
The answer will be completely and absolutely different depending on who you ask.

The best language in my opinion should be extremely opaque about what you're doing, all the data and structures should be visible to you and not change arbitrarily, the language should do as little as possible by itself, and it should be as easy as possible to write code this way. For example when you create a string, the language shouldn't activate some esoteric string system by itself that you can't even see into. C's way of doing strings/arrays is almost correct, except I'd want to think of some way to include the length along with the data. If you wanted something more fancy like an auto-expanding array, you'd just create it like a normal library, and the language author could provide a simple one as a separate download.

C++, when used as C with a couple conveniences is maybe the closest to the best language. But you can't just say "C++ is the best language" because it's so full of shit that you don't want. The best current language when considering all it's features is probably unironically C despite having all kinds of problems. Of new/upcoming languages, Jai (to be released in 2077) might be closest to having the right idea.

There's a separate concern that I don't see any language addressing well, which is portability to different architectures. You're meant to just expect it to work somehow, but how exactly it works and how it should interface with the syntax and language usage is never well defined or thought of in any way. It seems to be a complete mystery to the programmer how the program differs when you compile to one target vs to another target.

>>646
>C provides a computing environment that do things in a certain way. A good understanding of this environment enables one to be a good C programmer.
This is meaningless rhethoric you could write about absolutely anything. And when you agree that it doesn't even reflect the hardware, what's the point?

>it should be the programmer's job to write programmes according to machines, instead of the programmer's thoughts or the weekly language on Reddit.
You say that, but despite the massive increase in capacity and despite the fact that software isn't doing all that much more, performance issues are not plaguing us today any more than they plagued us in the 70s: You have your few bloated pieces of shit and the rest runs kinda fast enough. Said bloated pieces of shit also inevitably suffer from bad design and overcomplexity, so the problem seems to lie very squarely in managing the complexity of software, not getting it to run fast. Yet you consider dealing with that Reddit tier. Why?

It's not true that C modeled the usual processors of the time either, though this is another really popular piece of false history (probably because it justifies the idiocies of C, see the comment about gaslighting). Don't take my word for it, let the man himself talk. The world outside of minis looked very different, look at the Burroughs mainframes for instance.

>C didn't conflate those concepts because they exist not in C, but on the CS ivory tower.
When I wrote >>643, I thought about adding "I've met people who can no longer distinguish pointers and arrays as concepts", but removed it at the last minute thinking that it would be disbelieved or brushed aside as an unrepresentative example. This is really the most horrifying thing; not only are you missing out, you don't even realize you are. C's approach to arrays is neither natural nor was it conventional at the time.

>There is little room for hardware vendors to side with programmers (instead of the nature) more than they do now.
Most of your computing power gets wasted nowadays, so I'm going to doubt that. With the current technology, you could easily realize better incarnations of the high-level architectures that got wiped out during the microprocessor revolution. But unfortunately chip fabrication is so obscenely expensive that experimentation with hardware is uneconomical.

>>647
>C++, when used as C with a couple conveniences is maybe the closest to the best language.
As a developer with a few year's experience in both languages, I'll claim that this is definitely a misguided approach that literally is the worst of both worlds. Either take the C-only view of things (reference semantics) or take the Modern C++ view (value semantics). But definitely don't try to mix the two.

A) This will only hamstring the best developers on your team through having to support multiple, confused designs on the same project. And B) quite frankly, this approach is only seriously advocated through academia by tenured professors who literally never wrote a single piece of professional software in their lives. No self-respecting developer from either world would advocate doing a mash-up between them.

>>653
>the comment about gaslighting
That I just realized was in a draft that didn't make it. I meant the phenomenon that victims of C and Unix are usually gaslit into thinking that the failings of their tool are their own failings - the whole "Unix is genius, you just don't understand it" meme.

>>656
Well certain people with decades of experience seem to have the same opinion as me. Basically C with operator/function overloading and similar.
>No self-respecting developer from either world would advocate doing a mash-up between them
Also some of the aforementioned people have extremely high standards towards programming.

>having to support multiple, confused designs on the same project
Sounds like a problem with whoever's in charge of your projects.

>vague appeal to """certain ppl"""
k. write a large system using your clusterfuck approach and get back with us in a few years anon.

>>674
I'll choose believing the collective opinion multiple people who have worked on big videogames for decades over some imageboard rando.

>>675
Videogame developers are notoriously awful programmers.

7f144946551d1fbf6cbc608486063e446fe3cd6971bf98cd79f1c004e1886832.png
[Hide] (137.4KB, 500x500)

>>676
C++ programmers are notoriously awful and video game developers are a subset of them with tighter performance requirements than the fags who wank about muh C++2020 and muh templates. It shouldn't surprise you that a subset of the fags notorious for producing bloated, overdesigned messes also produce crap.

ClipboardImage.png
[Hide] (237KB, 500x385)

>>679
>who wank about muh C++2020 and muh templates
I understand the retardation of "Modern C++" but what/where is the problem with Templates?

>>703
Have you ever tried to use them or tried to read something using templates heavily? They're borderline unusable, undebuggable, and blow up compilation times.

1415067213101.jpg
[Hide] (278.4KB, 1280x720)

>>710
The 'heavily' is the key there though.
That is more user retardation than a problem with the actual feature.You could argue that the standard encourages bad usage but at their core they are pretty much a preprocessor for the type system,unless you attempt to force them into weird metaprogramming bullshit they are very easy to comprehend/reason about in my opinion.
Compilation time is really the only concern there that is an actual problem.

>>679
>>703
C++20 is good. They finally introduced a solution to include guards and multiple inclusions of the same header. Like 40 years late but better than never.
Not that writing include guards was that complex (you can just write #pragma once) but some large C++ projects take hours to compile.
This will hopefully bring compilation times back down to reasonable levels.

>>713
>if you only use it for 5% of what it can be used for, is used for, and is recommended to be used for, the feature is fine
Sounds like the feature is shit to me then.

fucking_stupid.webm
[Hide] (512.2KB, 1280x720, 00:06)

>>721
That %5(generics) is what the feature is intended for,retard.The rest is just implementation detail that got put in the standard because it gave someone a few boners once upon a time.

>>710
>>721
>>723
How can you even argue about such basic things?
The C++ standard library already makes heavy use of templates.
https://en.cppreference.com/w/cpp/container
Just look at all these template classes.
Of course you could make functions for each fucking type but what about custom types?
If you used a custom type, you would have to copy the code from the standard library and adjust it to match your custom type.
Is there any point in doing so and will it make things easier and faster? No!
C++ templates are good! Stop nigging about positive language changes from decades ago.

>>740
>it's either sepples templates or nothing
No you nigger, there are much better ways to do generics and metaprogramming.

>>740
>The C++ standard library already makes heavy use of templates.
And that's why it's treated like a bloated piece of shit.

This Anon is correct. Between the Algorithms and Containers already 'in the box' of the C++ Standard Library, there's little need to spend the time fighting with C -- only to discover the template metaprogramming approach blows it's shit right out of the water performance-wise. 

I've spent years dealing with both languages in a professional context, and IMO there are very few good programmers in either language. C devs tend to have a small bag of tricks, think they're the world's greatest geniuses b/c of it, and CBA to get out of the '70's & '80's with their coding approaches. C++ devs tend to have little understanding of the underlying machine and much like Python 'coders' just believe in magic(tm). Their coding approach generally involves lots of copypasta and throwing things against the wall until something sticks.

Both sets of developers described are abysmal to work with, by and large. But between the two groups, I certainly prefer the latter simply because A) it's far easier to actually get working systems using C++ than C, and B) they don't  display anywhere near the insufferable degree of arrogance the former group generally does.

Unfortunately, we live in a real world with real laws of physics. Because of this we actually need systems-oriented languages like C & C++ to get by creating big and important systems. C++ has plenty of issues, but not nearly as many as C does. Rather than trying to spell every little thing out, I'd just suggest you read this post
http://warp.povusers.org/grrr/HateC.html

I really couldn't put it much better. Back to my original point, Algorithms and Containers -- and especially the generic natures of both -- really set C++ apart from practically every other language going that postures itself as a systems language IMO.

One more thing I'd like to offer here, just in case there are astute, mathematically inclined here is a copy of EoP. It's about as rigorous a treatment of the fundamental basis of programming as exists.

>>752
I don't think templates were ever criticized for their runtime speed in here. It's everything else that's the problem.

>>753
I saw this book praised to high heavens in the past so I finally decided to check it out. Am I being pranked? Is it an elaborate joke I'm not in on? Definitions are convoluted yet often imprecise; almost all terminology is subtly different from the established one for no reason; concepts are unnecessarily tied to their incarnation in C++ with all kinds of warts as a result; everything has six gorililon pathological cases, half of which are literally never used, half of which are later glossed over, making most definitions unusable for reasoning; all while presenting the mathematical content as an impenetrable symbol soup to no benefit.

Who is the target audience for this book? I hope to god this is a mega shitpost and C++ people don't actually have enough brain damage to think this book is amazing. I can't think of a worse one I've seen in the last few years. It's hard to believe that Stepanov wrote this.

>>753
anon, I want to be charitable here, but this textbook does not cover programming fundamentals. I think you might have meant to say it's a rigorous formal definition of generic OOP concepts. It does not cover state machines, data structures or algorithms. Uses, yes, but it does not cover the actual fundamentals. There are many fields of programming that do not use OOP in theory or practice. If you actually think this is fundamental then I would recommend studying theory from another paradigm. (Logic programming, functional programming, imperative programming)

>>765
Well, a) the book isn't about OOP. b) Alright, I could have spelled out more clearly; the mathematical, fundamental, underpinnings of programming. It's a sophisticated treatment of the topic at large, not a hurr, babby mek first python gaem book, so yeah. 

>tl;dr
It's fundamental in the same way Euclid's Elements is fundamental.

>>955

>a) the book isn't about OOP.
Didn't say it was, though I can see it looks like I implied that. The concept of generics is tied to OOP, though other paradigms have similar ideas. And sure, generics are a useful concept. The book has value in formalizing a construction of generics. I would not deny that. If you're saying that generics are the "underpinnings of programming" I would have to disagree. It's a formalization of SOME constructed domain of programming. (Like how Euclidean geometry is a constructed domain of math. Important, but it is not foundational to all math. Non-Euclidean geometry exists, as does set theory and so on. I would argue generics are less important to programming than geometry is to mathematics, but that is a matter of perspective. )

I think my objection is that "Fundamental" and "Programming" generally implies lambda calculus or Turing machines: mathematical constructions from first principles that provably express the full space of computation. On one hand, I suppose any sufficiently complex system is Turing complete and can be put in that category, but surely when we talk about fundamentals we're trying to avoid needless complexity. In this way, I don't see how EOP provides something more fundamental or rigorous than earlier papers on computation. It is more directly tied to an existing programming practice, which may be of pragmatic value, but not theoretical.

>It's about as rigorous a treatment of the fundamental basis of programming as exists.
I could accept this if you meant it as "it's good." If you meant that it's one of the best, I find this to be unfounded.

>>955
>the mathematical, fundamental, underpinnings of programming
Lol no. He could have easily talked about actual mathematical underpinnings in the first chapter, in fact it would have made the book much better. He chose not to, and I strongly suspect he did so because it would have revealed just how sloppy the treatment actually is. I'm not saying he's a fraud, this type of self-deception is common.

I'm not even saying that there is nothing you can learn from this book, but all the interesting things in there (which aren't even by Stepanov though at least he cites them properly) are so hopelessly buried under a deluge of symbol soup and bureaucratic classification of pathologies (fucking partial models) that you could learn them from other sources more easily and thoroughly. Even so it might be worth it if he handled all this crap properly, but he doesn't. I can't blame him for this one, the book would be an even bigger mess if he did. The foundation is fucked.

And before the inevitable "you just didn't understand it" reply comes: I originally studied mathematics. The problem isn't that the topic is hard and advanced, it's that it's presented in a godawful pseudomathematical manner and once you strip the obscurantist nonsense, what remains is actually not all that impressive. It's as if this book was written for people who are easily impressed by symbols, which would also explain some of the "interesting" citation choices. Comparing it to Euclid's Elements is a fucking insult, plain and simple.

>>958
>the concept of generics is tied to OOP
Even Haskell has generics, arguably better ones than many OOP languages. They aren't tied to OOP at all.

>>959
>They aren't tied to OOP at all.
They are conceptually tied. If you have generics, you need types with associated operations. That's an object (by the OOP definition at least.) Even in Haskell or C, you can write OOP code. Not necessarily a good idea of course, but feasible.

>>960
That definition seems uselessly broad. What can you even say about OOP in the abstract at that point?

>>961
>OOP is uselessly broad
It's a cult anon

>>961
To answer more less vaguely: Objects are a formalized construction in CS, while OOP is just a set of practices that emerged over the last few decades. An OOP language is a language that facilitates and encourages various arbitrary design decisions using objects. Just because you have one or two data structures with some function pointers, that doesn't mean your code is object oriented; you just used some objects. Object oriented programming is the process of building a program entirely (mostly) out of objects, and the "best practices" around doing that. 

Of course, most code bases aren't fully OOP, because it's not a particularly helpful tool for modelling the structure of software. It's really only useful for interfacing between high-level components. Most commonly, it's just a set of practices to build software out of pajeet tier lego blocks without having the whole thing collapse. I suppose that's some kind of merit, but it's definitely not good design.

>>574 (OP) 
Seems you have good intentions and an interest in doing a good job as well as learning your field OP. If this guess is true I assume you already know C and haven't touched the likes of C++, Python, Rust, and so on for that reason.

You should go learn some assembly language, read Practice of Programming, Programming With POSIX Threads, C Interfaces and Implementations, source code from OpenBSD and Suckless, and other books and source I don't know.
Assembly will give you a better understanding of what compiled programs are like, it's useless to wank over progarm design when your program isn't the source but rather the machine code it compiles into. The other suggestions should be self evident.

>>574 (OP) 
The way to structure your programs is to get a good grasp on abstraction. Whenever there's a pattern in your code, make it a function/macro. Whenever there's substantial work to be done, or the method might need to change, make that a function/macro as well. Learn to program in terms of concepts, not actual operations. Make the computer do the work for you whenever possible.
In other words, read SICP and learn Lisp.

>>3352
I disagree with programming in terms of concepts. The programmer should be responsible to know what he is telling the computer to do. Letting computer do the work means letting others who write abstraction layers do the thinking for him and keeps him ignorant. This is how performance and simplicity get lost because the programmer was only focusing on letting the computer to do all the work and don't know what was going on underneath. Programmers should not treat the computer as a magic box that you produce a spell and magic happens. They should do it knowing what is happening inside. The understanding doesn't have to be very detailed, but he shouldn't do it without a good idea of what's going on.

>>574 (OP) 
Apart from SICP, "Grokking Simplicity: Taming complex software with functional thinking " and "Pattern Oriented Software Architecture Vol 1" helped me a lot. They're both available online.

>>3355
Programming in terms of concepts is programming, not importing 6 gorillion retard libraries to do it for you. I can eval (disassemble 'main) and read the instructions my main function compiled to easily, but I can also just trust the builtin operators to do what they're specified to so I don't have to reinvent the wheel. Sure, I could reimplement everything in hand-tuned assembly for performance - but I could also spend that time thinking of a better algorithm, or just not optimising because it isn't necessary for my program.
Though to be fair, even assembly has macroinstructions. Nobody likes cuntpasting blocks of code everywhere when they can just give it a logical name and use that. It makes your intent clearer, prevents possible mistakes like pasting into the wrong line, and lets you concentrate on thinking about what the program is going to do rather than how exactly you're going to tardwrangle the computer into working.

>>3442
Correct. Programming is compiling concepts to languages.
>Don't have to reinvent the wheel
Not always practical indeed. But answering solved questions is a very good way of learning.

Read "The Architecture of Open Source Applications"
https://aosabook.org/en/index.html

>How To Design Programs
https://htdp.org is a bit like mini SICP. It uses a Racket subset.

>Structure and Interpretation of Computer Programs
https://mitpress.mit.edu/sites/default/files/sicp/index.html
https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090&index=1
If you choose to use Racket, either set the language to R5RS or get the SICP language (https://pkgs.racket-lang.org/package/sicp).

>>3476
I don't even know what words to use to describe it, but there's a certain mindset that is required before a person can ever utter something of worth, and the architect anecdote that your link starts off with proves the writers have the right mindset.

I'll read it, thanks anon.

>>3479
guile worked perfectlu for SICp for me.
A friend who used racket had to create his own versions of certain function, in order to run certain programs.

>>3538
>A friend who used racket had to create his own versions of certain function, in order to run certain programs.
AFAIK, you don't have to do that if you use the SICP language (#lang sicp)

>>574 (OP) 
> I've heard "just do it" or "practice dude" but here's the thing: practice doesn't make perfect, it makes permanent. Trying to undo the damage of bad habits is effort on top of learning things the right way, the only saving grace is that is gets easier as you do it more. 
Alas, it’s not a failure, it’s the entire point. See also: semi-literacy training (teaching to read a letter based alphabet not letter by letter and/or with artificial interruptions). This produces all those TL/DRs who cannot read anything longer than a slogan. It’s not a bug, it’s a feature.

By now, it’s not even intentional, just intrinsic: everyone in educrap is a less-than-bright schizoid trained at parroting  the previous iteration of garbage and unable to do anything else. Garbage In, Garbage Out, in a feedback loop.
The thing with schizoids is that after some point they have trouble understanding “structure” at all. Thus everything gradually turns into Celestial Emporium of Benevolent Knowledge grade nonsense.

> In conclusion, what is good programming structure? 
Just like with everything: whatever fits the practical usage. Obviously, there are several approaches. And lots of bad practices. But even a bad practice beats a good air castle.

>>575
Now, now, comrade. It’s a permanent revolution.