1. 29
  1.  

  2. 19

    I’m deep diving c2 and it’s a mindbending mix of primary-source history, paradigm archaeology, elitist flamewars, and utter crackpottery. This is a proto “falsehoods programmers believe about X” I found in a tangent of a tangent of an argument on whether OOP or databases were better. Because those two things are apparently incompatible.

    The linked article is pretty great though!

    1. 16

      “I’m deeping diving c2 and it’s a mindbending mix of primary-source history, paradigm archaeology, elitist flamewars, and utter crackpottery.”

      Those were heady times, but threads on lobste.rs are going to appear much the same in 20 years.

      One of my favorite things is to go to used book stores and flip through print books and magazines from 20-60 years ago. You get the sense of life of an era. You see misplaced passionate certainty, and then you look at us and you have a chance to imagine what the future will think.

      1. 4

        I discovered it shortly before they shut down comments from new folks. c2 is awesome. I recommend digging through it all. :)

        1. 3

          …it’s a mindbending mix of primary-source history, paradigm archaeology, elitist flamewars, and utter crackpottery.

          Ah yes. Good thing none of those has ever showed up on Lobsters. /s

          …an argument on whether OOP or databases were better. Because those two things are apparently incompatible.

          They actually are.

          1. 2

            A mismatch doesn’t equal incompatible. My work handles lots of data that absolutely should be in a relational database and it’s worth any additional friction it might cause is a reasonable trade-off for other benefits (reporting, sane modelling, etc).

            1. 2

              I don’t think I’ve seen anybody on lobsters (yet!) claim that they solved the halting problem.

              1. 1

                …that happened?

            2. 2

              …and it’s a mindbending mix of primary-source history, paradigm archaeology, elitist flamewars, and utter crackpottery.

              I find the same phenomenon in books about “programming your microcomputer” from the 70s and 80s, especially the crackpottery.

              1. 1

                That list of peculiarities sounds like a weird mix of challenging fun and hellish nightmare.

                1. 1

                  There was an interesting crackpot (or?) on C2 called “TopMind” (“top” for “Table-Oriented Programming”). He was antagonistic towards OOP but the OOP people were pretty hostile to his critiques too, so I kind of liked him as an underdog. And OO was almost religious there, due to its founding as an OO pattern discussion forum. TopMind’s ideas included the benefits of storing procedural code in tables, the superiority of FoxPro, etc.

                  1. 1

                    I think the most cringeworthy example here is this, which is a perfect example of How Not To Argue For HOF.

                2. 5

                  We have our own custom payroll system, and I agree payroll is crazy. I find it’s a mixture of 2 things that make it hard:

                  • People are very fuzzy and super hard to concretely define.
                  • People care A LOT about money, which increases their fuzzy nature, to competing ends, the company wants to minimize payroll as much as possible, while employees want to maximize (their) payroll, so we have a bunch of fuzzy people fighting over literal pennies in a never-ending game.

                  Not to mention all the laws from many different jurisdictions and payroll is ripe for insane complications.

                  Whenever people say payroll should be “easy” I just laugh and laugh.

                  1. 4

                    Was thinking about this. Many of those various complicated benefits that specific subgroups of people are entitled to are just something someone negotiated once. They’re worth a certain amount of money to that person and there’s some amount of money which you could pay them in return for them not having that benefit any more.

                    Has anyone seriously tried to do an ROI analysis of offering people more money to switch to less-complicated renumeration schemes… against the amount of money saved by making the payroll code some % simpler?

                    edit: obviously this doesn’t apply to most of the really complicated things like taxation, but some of these things they talk about like “these five specific people negotiated a remuneration scheme under which these slightly different rules apply to them and no one else” scenarios which are mentioned there.

                    1. 2

                      I think it’s interesting, but the people that fight over the $$’s are basically never the people that are very involved in having to implement said payroll system to pay those $$‘s. At least in my experience. So I’d be quite surprised if it was ever done at any large scale. That and by now, most payroll systems are sufficiently broad enough that most insanities perpetrated by companies can be implemented without new code… usually.

                      1. 1

                        That’s an interesting analysis in general, and one I don’t think I have thought of before. Not having feature X will cost us money, because reasons (X will be manual, won’t be done as fast, we’ll have to do Y which is costlier, etc), but adding X will increase code complexity a lot, resulting in added maintenance cost in the future. So, which is cheaper in the long run?

                        1. 3

                          I’m really hoping that someone else might have done that analysis and written about it somewhere because I would not even know where to begin with that myself. :)

                        2. 1

                          Has anyone seriously tried to do an ROI analysis of offering people more money to switch to less-complicated renumeration schemes… against the amount of money saved by making the payroll code some % simpler?

                          The incentives aren’t aligned.

                          Has anyone ever used a time reporting software that isn’t a huge pain to use? It’s because the people making those don’t sell them to the peons reporting times, they sell it to the managers looking at the results. Those people probably get great UI!

                          In similar ways, trying to get a union to accept simpler renumeration just to save the company some money reporting payroll and not having to pay expensive consultants - now you’ve pissed off the union and the consultants!

                        3. 3

                          The software I support at work generates schedules for people, so naturally customers want to use that data as a basis for payroll.

                          It’s a nightmare, especially since we were “nice” to customers in the beginning and hacked together custom solutions for their Payroll/HR systems without considering reusability etc. I once brought down an installation because I had to manually edit XML config files to add new holiday dates and forgot to save them in UTF-16…

                          Somewhere someone has dreams of the universal PayrollXML interchange format, but this is where the messy part of human relations (in the large) meets the part where programmers just want to have one interface - think how streamlined it will be!

                          This is why smart contracts will probably never work, either.

                        4. 3

                          The last sentence struck me (but here’s the paragraph for context):

                          Technicians are cheaper than a nation-wide strike. Lawmaker’s minds are difficult to fit into our etricate models not because these minds are crazy or whatever, but because they are human beings and they can’t be easily modelled using strict hierarchies. And that’s great news, by the way! In any case this is our job to make their business understood by the software, not theirs. The typical attitude of “You are presenting problems I can’t easily solve with my favorite tool, therefore you’re an idiot” should be banned from IT.

                          There have been a couple times where I’ve caught myself in this error.

                          1. 3

                            If you work in A and live in B, you can pay the lower of the two communities’ taxes. But if you live in B and work in A…

                            These mean the same thing :)

                            1. 2

                              Not always. It depends on the specifics of where A and B are, and what the regulations of each are.

                              1. 3

                                No, it’s literally the same thing.

                                1. 3

                                  Yup, on closer inspection I can’t read! Thanks for pointing that out, I wish I could edit my original comment.

                                  1. 3

                                    I interpreted it as “if you live in B and then get a job in A, you have different regulations than if you have job A and then move to B”. Which I can totally see having different regulations, like a travel tax deduction or something.

                            2. 2

                              Why hard?

                              1. A huge number of complex functional requirements that are hard to dicover, elicit, pin-down and understand.
                              2. No predictable and repeatable methodology to model such functional requirements into software.

                              We haven’t really made much progress since the heyday of c2 have we?

                              1. 10

                                It’s only been ten years, give or take. People have been arguing over payroll ever since the first person got paid. A large chunk of the Hammurabi Code regulates prices for services.

                              2. 1

                                Maybe, just maybe, objects are just the wrong abstraction for this problem. Maybe.

                                1. 1

                                  I fell into the classic trap of thinking through how I’d do this in my favorite language. Easy, no, but computable and of limited complexity? Yes.

                                  1. 1

                                    My first instinct here would be a logic programming language. What would you use?

                                    1. 1

                                      My mind went to Clojure, for it’s maps and simple ways to work with vectors, so you can put functions onto a person’s entry in the map and thread them to get that individuals tax rate, etc. The loose typing required appeals to me for a system where anything might change now or at a scheduled time in the future.