Not really MCU, but controversial. - Page 1
Forum section: electronics / general

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: July 04, 2020, 02:12:02 am
content: Its controversy is inversely proportional to the amount of Stroustrup-flavoured Kool-Aid one has drunk. Fromthe Hacker News discussion:> Brian's video is one of the most influential bits of wisdom I've received in my career. Up until this video I did not have a language for explaining the problems I ran into trying to build OO systems. It also helped me understand why writing procedural-functional code felt so natural and easy.> I was a die hard OO/UML guy. I even contributed to various open source software projects for a model-driven-architecture framework, a UML editor, and integrations with Rational Rose. I was an evangelist for good OO practices, SOLID, etc... As a development coach I was quite fervent.> Looking back on that I feel like a fool. When I read the code refactoring examples from Uncle Bob and others I see all the problems Brian talks about in his video (and more). OO was a nice idea but we got the granularity and implementation wrong.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 04, 2020, 10:51:12 am
content: The problem is, the OO became such a massive business, that itneededto become something that is above critique. The OO paradigm totally swept over education; for example, universities aresupposedto be institutes that teach scientific argumentation and critical thinking, yet OO penetrated them in a way like it was a well-proven fundamental law of physics that is automatically true and need no questioning.Yet the critique against OO is very well founded, and this particular video is quite OK in showing some of the problems.Now the funny thing is, thisdoes notmean that OO is a complete farce, or a total error, no, quite the opposite. Almost anyone appreciates this; the "C greybeard" strawman stereotype as described by some OO evangelists is almost non-existent.We just need to understand that sometimes there is no one universal truth, but there should be discussion and exchange of ideas to find best ways to deal with things. It's just that the OO paradigm, and some other similar so-called "modern" (many of them actually old and coming and going in cycles) "patterns" are being so heavily force-fed that such discussion often isn't very fruitful. When you are forced to use the OO paradigm, you automatically develop kind of a Stockholm syndrome like condition. This blurs your vision. The issue is that we have very few people left whohaven'tbeen exposed to massive amounts of marketing-originated non-scientific, non-engineering reasoning that is very difficult tounlearn.Evenif you end up seeing the OO is the right thing to do, unlearning the Church of Oo mentality and gaining understanding from the computer/software science viewpoint is the prerequisite for fruitful discussion and finding the best tools for the actual software engineering jobs.Given how inefficient, buggy and bloated most software around us is, and how many developers we need to build such software, over such long project timelines, it isobviousthat the paradigms used are not silver bullets. Hence the argument "it has to be used because it is what is being used and it works" is useless; thingsclearlyare not working too well. It's unclear if any other paradigm, such as "C greybeardism" would work any better, but it's also clear you can't say they are any worse; there is no evidence for either simplistic claim.One problem I don't see much discussion about is that a complex software project kind of needs to pick their poison; it's a bit difficult tocombineparadigms so that eachpartof the program would use the best paradigm for that job. To be fair, C++ surprisingly does quite a good job here, but it's most often criticized just for this reason, unpurity. The problem is, in a large project, it's difficult to get people agree that multiple paradigms are being used, instead people want to find out "who's the winner" and then the project is either completely C with no libraries and every data structure memory handling operation written from scratch, or then it's a huge flashy cathedral using all the nicest OO paradigms everywhere so that once you need to change one object relationship somewhere, the whole thing collapses.Another problem is how you measure success. The software industry measures success by the money, and money is related to how much work you need to do. While you can argue that people pay for results, that is only true if there isrealcompetition who provides the results with least amount of work. But ifmostproviders are using similar techniques, then you are paying for the amount of work done. So now inefficiency leads to apparent success. And from the software house point of view, this is of course true! It isn't only good for the management; manyprogrammerslike this as well; they don't consider it inefficiency, they think it's a nice technical challenge to be able to perform a simple task through all the modern software stack layers. And who wouldn't like to be employed, even paid well?The fallacy is, you can always tell your customers that software isreusableand can becopied, hence investing large amounts of money developing it pays itself back quickly. Yet the same marketing guys tell you next that software goes stale quickly so you need new software projects for the same task every two years or so. If you measured success by getting job X done - i.e. delivering result X, this must be a very high level specification, for example "sell train ticket to a customer", in least amount of resources, the story would be completely different.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 04, 2020, 06:12:19 pm
content: As you said, the criterions for judging a given approach must be clearly defined.We might assume that one of them would be TTM, thus reducing development time as much as possible, but that is only true (and maybe not even completely) if the development team is directly part of the company shipping the product. Subcontractors are ubiquitous these days, and their interest is not completely aligned with that of the companies they work for. Even for the developers themselves, whether they work in-house or as subcontractors, reducing development time is not necessarily a benefit. So it's all in whatever a given company will still find "acceptable", rather than optimal.As to reusability, IME, for software developers themselves, it's largely a mixed feeling.Some of them like, and take pride in writing reusable code, and enjoy reusing it in later projects. But many of them enjoy rewriting stuff even more, because it's just more interesting, more exciting, and most developers often have new ideas once they have coded something, and want to test them. That's where management comes into play, but managing software development teams is hard, and I guess enforcing some methods (such as OOP, and others), even if unperfect, makes the task easier.

author: hans
author_rank: Super Contributor
timestamp: July 06, 2020, 07:37:14 am
content: I watched some parts of this video (I skipped the cartoony BS), and his message could be summarized as:Don't let objects gossip about their current state, otherwise you get global/shared state and things get messed upHe suggests writing programs that are structured top-down and, if needed, bottom-up. Ironically, this is exactly what functional programming paradigms enforces, as functions are pure by default and therefore there is no state present in the function. In fact, FP does away with objects since there is no state stored in them. What then remains is to provide type classes, monoids or use applicatives for the types you have, and provide some kind of IO environment on top which actually persists state.IMO monoids or applicates are almost like implementation details. The structuring of programs is probably what seasoned programmers have taught themselves over the years.Quote from: Siwastaja on July 04, 2020, 10:51:12 amI fully agree. I often see people re-implementing features in C that are really basic stuff in C++ or STL (or static library variants), which also has all the benefits of compile-time sanity checks.Your point about (I assume: perfectly polymorphically typed) cathedrals reminds me about functional programming as well. I've seen so many cases where type polymorphism would be resolved only until the very end at the top level definition of the program or module. That was great, because you could change 1 generic/parameter and the whole structure implementation of the code would automatically adjust to what you need. All static assertions or other sanity-checks would see if buffers are sufficiently sized, vector manipulations will be accurately sized, index types are fit large enough, hash/CRC tables are regenerated on-the-fly, etc.The problem arises when working at code where types still need to be resolved. This quickly becomes a huge clusterfuck. In a language like Haskell this is still managable and part of the learning curve they say. However I've made the mistake of writing such code in C++ as well, and I would literally get type errors in GCC 8 that are as wide as 2x 1080p screens, with text filled up twice (and I doubt I set any kind of highscore in that regard). It turns it this was from just 1 error I made in some double templated parameter. I think these kind of cathedrals can still be very powerful in certain places, but only on a very local context that would greatly benefit from metaprogramming.

author: paulca
author_rank: Super Contributor
timestamp: July 07, 2020, 03:15:03 pm
content: Haskel. I tried to compile that on my Linux box once. After 3 hours I aborted it and installed the program that wanted it from binary. Never seen something that compiles so slowly in my life.The problem of scale comes up regarding both software complexity and team size. OOP still hasn't fixed those.Both are just inherent problems in engineering anything. Modularisation is the answer. Top down, split it up. Only splitting when needed, when it's obvious. Not starting from the bottom trying to design every possible thing you "might" need. Speculative design and adding abstraction in everyplace you can without actually knowing if you will need it or not. It just generates complexity and when it tries to resolve an existing problem, it claims to simplify it, but all it did was spread it out into more code. They push code complexity into architecture complexity.We had to reverse engineer the functional code for a single process out of an OOP Death Star in work last year. The senior engineer doing it, identified 140 nested method calls through patters and frameworks and when the method contents where serialised out a single sequence, there only were 4 that had any effect and 2 of them were wrong and undid each other. That took 3 days to do. It took 5 minutes to rewrite in a single method.Functional programming. I get the stateless bit, but I absolutely HATE the academic information/category/group theory bullshit. I also hate the Perl like implicit syntax (thinking Scala). I try to use Java static methods wherever I can, but I hate the new functional API. It just doesn't read like English.. or any other human language either, except maybe data scientists and information theorists language.I wanna get a job done, usually with limited people of limited experience in a rubbish restrictive environment.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 07, 2020, 05:20:29 pm
content: There was a discussion on Slashdot a while back on this subject that generated a lot of heat.https://developers.slashdot.org/story/19/07/22/0426201/is-object-oriented-programming-a-trillion-dollar-disaster?sdsrc=popbyskidbtmprev

author: NorthGuy
author_rank: Super Contributor
timestamp: July 07, 2020, 05:46:44 pm
content: OOP is a very useful concept. It is very simple. Functions and data are combined together and form objects. This is really useful. You can do it in any language. I was actually doing it before I have even heard of OOP. Saved me lots of time and effort over the years.However, there always been esoteric people swarming around programming, trying to make rules how things must be done, some just rediculous, such as everything must be encapsulated, or everything must be an object, you can only access this, but not that. Finally, there are so many rules, it gets impossible to program. People have to create ugly workarounds just to make work done. That's where the programming theory stands now. This reminds me of communist society where the government issued so many rules that it is impossible to work without breaking them, and the economy comes to a halt.Apparently, this guy on the video does not see any distinction between systems of rules surrounding contemporary programming and OOP concepts. For him, the system of rules is the OOP concept. No wonder he hates it. He doesn't even want to speak about inheritance, because "nobody speaks of it any more" (sic!).

author: paulca
author_rank: Super Contributor
timestamp: July 07, 2020, 05:52:32 pm
content: It is worth watching his other videos to gain insight into where he stands.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 07, 2020, 06:29:21 pm
content: that video is too generic. he assumed you must be on the same boat as him developing/maintaining very complex system. to be frank, i dont get the clue to what he's talking about. what i understand is he's trying to make a new rule on top of OOP that everything must go through the God object (i like the termmuch better than anything else nonsensical) but then suggesting back to procedural programming? did he suggest we should stick to the stone age? or is he blaming the tool? or barking at the wrong tree? or is it Java that should be blame for imposing OOP on low level stage of the language (everything must be built on OOP) he's talking about stable state or some sort, if C calls A, after B calls A, or vice versa, then its unstable state... if another object has to make a copy of another object's state then he must be wrong i guess, no?

author: nctnico
author_rank: Super Contributor
timestamp: July 07, 2020, 08:24:44 pm
content: Quote from: NorthGuy on July 07, 2020, 05:46:44 pmI guess the bottom line is that before you start programming you need to design the data structure of a program first. From the example in the video: if you need to share a state between various seperate objects then the design of the program is simply wrong. And yes, maybe the OO approach isn't suitable to it's full extend for a certain programming problem but saying OO is always bad is just going too far.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 07, 2020, 09:44:13 pm
content: Quote from: nctnico on July 07, 2020, 08:24:44 pmExactly. You need to design the whole thing first - data structures, operations etc. Then everything falls into place by itself when you program. You cannot achieve this by following rules.

author: Bassman59
author_rank: Super Contributor
timestamp: July 07, 2020, 10:42:04 pm
content: Quote from: NorthGuy on July 07, 2020, 09:44:13 pm.. but but but isn't it a rule that you should design the whole thing before you start coding?

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 07, 2020, 10:56:48 pm
content: there are sensible rules there are not... following the nonsensible one usually ends up in nonsensical outcome, such as thinking any system should be or can be maintainable, expandable or scalable as easy after its design and development time. OOP was meant to solve this very problem in procedural methodnow he suggesting its the backward.

author: nctnico
author_rank: Super Contributor
timestamp: July 08, 2020, 08:44:33 pm
content: Quote from: Bassman59 on July 07, 2020, 10:42:04 pmYes. But from the video I get the distinct feeling that the creator gets the output of a sloppy systems designer thrown in his lap and that he thinks he should implement a piece of software the obfustigated way the systems designer has designed it. Suggesting the need for global variables sets of my alarm bells.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 08, 2020, 10:26:58 pm
content: yes my thinking too. if you want to make sure everything has to go through the God object from the start, then by all mean do it, its the rule made at the design time by the architect (designer). but once its finished, it will take tremendous effort trying to change that rule in the whole code structure (even if you are the one making it 10 years ago), similar to sloppy rules/systems. there is one guy he posted sometime ago surrendered at a procedural based library just because the namings are to obfuscated, but looking at the code example he provided, they are just a bunch of simple well known function, so i guess programmer's compentency and experience also comes in the play.good documentation is also equally important but usually missed by the design team. for large OOP or abstraction layer based structure, there must be clear diagram showing which object/layer relating to each other in the structure, in graphical or diagram manner, tree structure etc. so later, other programmers can easily pinpoint which part to modify/expand/fix. i find the usually mentioned doxygen system is far from adequate of providing this, simply putting a comment on the start of every functions wont be adequate. only very very very few codes/libraries i've seen providing this and they are from large enterprises such as microsoft. i think Qt also provides this on their Qt library but they dont make it so easy to search for that i need to do some digging and a little bit of cursing. my 2 cents...

author: nctnico
author_rank: Super Contributor
timestamp: July 08, 2020, 10:45:42 pm
content: Yeah. Doxygen sucks because it doesn't capture the idea behind the software. Without understanding the idea behind the software it is very hard to use / modify it. I'm currently working on a somewhat larger software project. I already spend a week or so full-time on the architecture and drawing schematics and flow charts of the internal structure. Didn't write a single line of code yet. But for sure polymorphism is going to be very helpfull in this project.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 08, 2020, 11:25:50 pm
content: Quote from: Bassman59 on July 07, 2020, 10:42:04 pmNo. Nobody forces you to. If you feel you can code before designing, you certainly may.

author: paulca
author_rank: Super Contributor
timestamp: July 09, 2020, 08:02:09 am
content: Quote from: NorthGuy on July 08, 2020, 11:25:50 pmThis approach has also failed. We call it "Waterfall" and there are so many published and accredited methodologies following that approach.The trouble with it is that requirements change. Waterfall only works if the requirements stay the same. Literally if you are following something like PRINCE or PRINCE2 and a requirement changes, you have to stop everything and go back to the start with requirement elicitation. Interviews, workshops, etc. At each stage everything is documented formally and to exhaustion.The issue here is shown in many, many large scale projects which ended up running for and costing many multiples of the initial estimates and in many cases being scrapped completely.The effect of this was felt in the UK where government adminstrational services were not online for decades while the government insisted on such methodologies. Finally the government changed it's requirements to allow faster time based, interative approaches like DSDM and Agile. Now we actually have working online government services and a lot of them came in at or under budget.OOP proponents will argue that the extensibility OOP provides is required to deliver good software in an Agile way.I will re-iterate what the video creator finally gets to in other videos. Writing proper extensible, dynamic, flexible, abstractions in OOP is EXTREMELY difficult. IMHO it should be completely separate venture to application development. It's vaguely akin to electronics where ICs are developed without a highly specific application in mind. When you choose to use them they often force you to design you circuit in certain ways, but you take advantage of not having to do all the intense stuff the chip does in descrete components.OOP in the application development space is like people trying to design circuits with passives and diodes only. You can understand that this results in massively over complex non-sense and they should have used off the shelf ICs and left the complexities of the descrete components to whats inside them.

author: MarkMLl
author_rank: Frequent Contributor
timestamp: July 09, 2020, 09:15:11 am
content: Quote from: NorthGuy on July 07, 2020, 05:46:44 pmI agree, it's a useful compromise between "close to the metal" and "fancy".I also agree that a project should be designed top-down, but would suggest that there are also good points to the "let's design reusable components" philosophy. However I'd suggest that one of the biggest problems suffered by the software industry is that components are almost invariably poorly-documented, and there are no public registries which allow somebody with an itch to work out what pre-existing component best scratches it: GOOGLE IS NO SUBSTITUTE FOR PROPER INDEXING.Interestingly, if you go back to books describing Smalltalk-80 which is considered by most to have popularised OOP, you find that it actually had quite a lot of project management stuff built into the language.Finally, one of my betes noires is the sort of language design that says, for example,* Everything should be implemented as a list, i.e. ("l" "i" "s" "t")* Let's add syntactic sugar that allows people to use strings easily "list"* Even if we pretend that things are implemented as lists, let's have densely-packed data structures at the machine level.* Oh goody, we can get fifteen published papers out of that!There are far too many inveterate tossers in the software industry. At least hardware engineering /used/ to have a tradition that its practitioners spent some time on the shopfloor during their training, and the best entered via an apprenticeship and day-release rather than a degree from Cambridge.MarkMLl

author: NorthGuy
author_rank: Super Contributor
timestamp: July 09, 2020, 03:06:13 pm
content: Quote from: paulca on July 09, 2020, 08:02:09 amThat's because his vew of OOP is weird. OOP is a concept which opens possibilities and gives you freedom to create. He regards it as a system of restrictions which forces him to program in a certain way.Quote from: paulca on July 09, 2020, 08:02:09 amYou've got to be kidding. For example, an IC to provide Vtt voltage for DDR3 memory, such as TPS51200. How more specific can it get? Or a stepper motor driver, such as DRV8886AT - drives a stepper motor and nothing else. You use them because the hardware implementation is more efficient in every way. You could, for example, create your own stepper motor driver with a beefy MCU, current sensors, discrete parts for FET drivers, 8 FETs for the bridges, but you would have 5x times BOM cost and yours would still not be as good as the hardware one.I like similar approach to software - lean and to the point.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 09, 2020, 03:50:32 pm
content: Interestingly, it seems we often confuse programming paradigms with software development methodologies, whereas the two have only remote connections, and almost any paradigm can be used with almost any methodology.As others have pointed out, OOP in itself (and its basic sense) is a pretty "natural" approach once you get into "structured programming".Define data structures and functions that operate on them, and you quickly realize it's only a step away from OOP. As soon as you start "encapsulating" data structures that have several members, you get "objects". There's nothing wrong with that, and I'd even say that in that sense, almost any (but the sloppiest) software these days is coded in some form of OOP, whatever the language.Some issues arise as soon as you start coupling data structures together, which inheritance is a form of. The corresponding hierarchy can be powerful, but it also defines a pretty rigid architecture, which becomes hard to change at all once it gets even moderately complex. In the very general sense, badly "coupled" objects can lead to an architectural disaster. The difficulty doesn't stem from OOP per se, but from methodologies that have often been taught along with OOP, which basically promote complex hierarchies.As to coding BEFORE designing, whether you use OOP or not, it's very likely to fail except for the most simple projects. You'd think that "OOP" would promote (/imply/make necessary) designing before coding, but we have unfortunately witnessed otherwise, especially with the advent of modern "agile" and such methodologies, which are often weirdly coupled with heavily OO languages. There is some technical paradox here IMO, but the explanation is pretty simple: it's just an addition of "modern" tools and methods. Whether they are a good match is another concern entirely.And then whether OOP per se helps reusability, I would say yes, but only considering the basic principles of OOP: data structures and functions operating on them, forming objects. That's because it's a relatively helpful and natural way of expressing functionalities and their interfaces. Then again, OOP with too many hierarchical levels and too many dependencies helps a lot less and can become a nightmare to maintain. In all cases, as I often say, OOP without modules is still pretty cumbersome as far as reusability is concerned.Finally, I think it's unfortunate, but pretty common in the software industry, that people would tend to favor tools and methods that look "hype", and are possibly publication material too, rather than approaches that have just proven to work whatever they are, even if that makes you look less cool. Software "engineering" heavily suffers from this, much more so than any other field of engineering at the moment IMHO. It's like the field tends to judge software developers not by their results anymore but just by the methods they use (even if they consistently deliver crap.) Which frankly looks like politics in some way.

author: MarkMLl
author_rank: Frequent Contributor
timestamp: July 09, 2020, 04:26:13 pm
content: Quote from: NorthGuy on July 09, 2020, 03:06:13 pmAgreed. In a substantial number of cases how to design a particular class is fairly obvious- provided obviously that the language is suitable.QuoteDisagreed in the general case. A 74LS00 or MC4000 chip isn't specialist, neither is an AVR microcontroller.MarkMLl

author: MarkMLl
author_rank: Frequent Contributor
timestamp: July 09, 2020, 04:39:56 pm
content: Quote from: SiliconWizard on July 09, 2020, 03:50:32 pmIt's unfortunate that- as specific examples- partisans of OOP and partisans of a functional style put far more effort into slagging off the opposition than into looking for some way to unify the concepts. Perhaps they quite simply don't have a good enough grip on reality to recognise that altimately the two paradigms are normally run by identical hardware, and to sonder how that could possibly be.As an- originally at least- low-level EE guy I don't have any problem with the idea that that an object encapsulating state and functions might possibly be related to a functor encapsulating functions and state.Unfortunately, more work goes into trying to shoehorn multiple paradigms into unified languages than trying to work out what they have in common and abstracting it.MarkMLl

author: paulca
author_rank: Super Contributor
timestamp: July 09, 2020, 05:47:51 pm
content: I get the feeling most people here are missing the point. We are talking about the modern OOP. They one nobody does right. The one full of problems and solutions to those problems with problems and solutions to those problems .... and so on. So one bit of code become 16 different bits of code and 0 sense to anyone anymore. The one where when you point out the issues with it, the proponents retort with "You are doing OO wrong! Try adding another 3 layers of abstraction"I'm not 100% in agreement with the dude in the video.... especially when you look through his library and find it's a Node.js / Go / Javascript kinda guy.We are not talking about using a class as an encapsulated module, we are taking about all the advanced masturbatory non-sense of design patterns on top of design patterns wrapped in single lineage hierarchies and interfaces with single implementations, empty or useless abstract classes.The picture in the post above is more what we are talking about.In fact, THIS is a perfect example and while it may be tongue in cheek... I have seen code this bad and the developers behind it defended it with a straight face.https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition