I haven't been following recent Java releases, but unless Java has some equivalent to Erlang's OTP library (at a minimum), I stand by my statement
5,154 karma · joined July 22, 2010
There is no way to detect consciousness. So you will have a very hard time distinguishing a system that seems conscious from a system that is conscious, (where "system" could be artificial or natural).
You know that you are conscious. How do you know that anyone else is?
We built the system in Java and C. The distribution layer was done completely in Java. It was only after the system was done that I discovered Erlang. I REALLY wish I had known about it earlier. Erlang solved so many of the problems we had to solve by ourselves.
That is remarkably dumb. Don't use an RDB if it doesn't fit your requirements. But "relational concepts" covers a lot of valuable ground, and rejecting them out of hand is a combination of ignorant and dumb.
Listen kids: Codd's 1970 paper on the relational model of data was absolutely revolutionary. Data processing involved low-level navigation of records. Separation of logical concerns from physical concerns (like 80-column cards) was regarded as crazy. Codd's message was this: a set-oriented data model, manipulated by a high-level, non-procedural language was the right way to process data. And yes, a lot of practical details need to be worked out, but it's still right.
And then followed decades of research into the implementation of relational database systems, which gave us working systems that fully realized that set of ideas. It was an incredibly bold research program, which delivered, and gave us incredibly valuable technology such as:
- SQL (love it or hate it, it's a mostly non-procedural high-level language that does a great job of data processing).
- Query optimization.
- Transactions, with levels of isolation and many different implementation approaches, most of which have proven practical at one time or another. Also, early work on distributed algorithms, e.g. two-phase commit.
Ignore these "relational concepts", and you will be reinventing it, badly, and at great expense.
So something goes wrong, and you need to back out an update to one of your microservices. But that back-out attempt goes wrong. Or happens after real-world actions have been based on that update you need to back out. Or the problem that caused a backout was transient, everything turns out to be fine, but now your backout is making its way across the microservices. Backout the backout? What if that goes wrong? The "or"s never end.
Just use a centralized relational database, use transactions, and be done with it. People not understanding what can go wrong, and how RDB transactions can deal with a vast subset of those problems -- that's like the 21st century version of how to safely use memory in C.
Yes, of course, centralized RDBs with transactions are sometimes the wrong answer, due to scale, or genuinely non-atomic update requirements, or transactions spanning multiple existing systems. But I have the sense that they are often rejected for nonsensical reasons, or not even considered at all.
I asked my daughters what music, from their teen years, (aughts and tens) would be listened to fifty years later, similar to the Beatles, Stones, Zeppelin, etc. They said none of their music would be remembered, it’s all disposable.
1) The stuff that happens in your teens is special because of your age. That may well explain why I think The Beatles (and the music of that era) was so special.
2) The music from the 60s really was special. There was certainly rock and roll well before The Beatles, and it grew out of black music, and blues, and can be viewed as nothing really new. And yet: it really was a significant break from the past in the global adulation for their music and the quantum change in tastes that they ushered in.
Not to minimize Nirvana (whose music I love) or metal, or anything else, but the musical examples that you cite were simply not as globally shattering as The Beatles. They just weren't. They were variations within the world of rock and roll. The only comparable change I can think of is the rise of rap music. Which I cannot stand, but I recognize how it changed the world in the same way that The Beatles did.
This tells the story of a vaudeville comedy act, a husband and wife team, booked on the Ed Sullivan show, on the day that The Beatles made their American debut. They were completely blindsided. They didn't have any comprehension of what was happening until they were in the middle of it. They didn't really get it until later. The story includes an encounter with John, surreal for the juxtaposition of the ordinariness of the interaction, and the symbolism -- these two completely different eras encountering one another without any awareness of what was represented.
To push the point too far maybe, what was changing was the very sound of life in the US. You hear these old timey comedians, and they have the rapid fire delivery, the tone of voice, the corny jokes, the style that characterized vaudeville and TV sitcoms. And then you have The Beatles, ushering in something brand new (to the vast majority of Americans). I think it's the same sort of difference you see in movies: Before the mid or late 60s you had this very stylized and artificial way of speaking, often with this weird and phony "mid-Atlantic" accent. And then you had much more realistic movies and ways of speaking, e.g. anything from that era with Jack Nicholson.
They put out a Unicomp clicky keyboard a few days later, picked up that too.
This is not to detract from the AIs accomplishment at all. If it read the scientist's prior work, then coming up with the same discovery as the scientist did is still astounding.
But it often isn't. The blog post starts out talking about how that field -> getter/setter pattern is very widespread, and tools (JavaBeans tools for example), make that pattern unavoidable sometimes. Yes, it should be an API decision, but for a variety of reasons -- tools, patterns, coding standards, cargo cult programming -- it isn't.
The point is that mechanically maintaining get/set methods for each field is completely at odds with encapsulation. To continue the example, sure, go ahead, have any or all of get/setX, get/setY, get/setR, get/setTheta if they make sense for your application. But writing them just because you've created a field, and the coding standards say they should be there is dumb. The coding standards that say this (like JavaBeans) may have their reasons, but OO ain't it.
In OO othodoxy, you aren't supposed to make state public, because it violates encapsulation. If you want to modify your Point object to use polar coordinates instead of cartesian, then if you expose your cartesian state (x and y), then all the code that relies on x and y is now broken.
So what getX() and setX() do is allow your x and y fields to be encapsulated. Problem solved! Except that once you change to polar coordinates you have your choice of problems:
1) Find all the getX() and getY() uses, and rewrite the affected code to use getR() and getTheta(), since you are now using polar coordinates. In other words, you have violated encapsulation by having getX() and getY() methods, and your get/set methodology hasn't achieved anything.
2) Re-implement getX() and getY() in terms of polar coordinates. That's doable. But do you also now have getR() and getTheta()? Why?
Having getFoo() and setFoo() methods for each field foo is this dumb idea that began, I think, with JavaBeans. It has nothing to do with OO as I understand it. The idea behind OO encapsulation is to separate your object's behavior (the methods) from private state. You can change state at will as long as you maintain behavior. Mechanically adding behavior (get/set methods) to track your private state has always been a stupid idea that has nothing to do with OO except to violate encapsulation.
I was in Florence in the mid 80s. It was a beautiful ancient Tuscan city, with plenty of tourists, but it seemed authentic.
I went again last year, and vast areas have turned into a glitzy shopping mall, with many international brands represented. (Also, so many leather goods shops.) It looks like the same disease that affects Prague: popularity has attracted high-end commerce and changed the city completely, destroying the original character.
Key boxes aren’t the problem.
1) Using a laptop at a desk with no peripherals. Fix was to raise the screen, sit up straight, and get an external keyboard and mouse.
2) Stopped using one of the sleek Apple mice from years ago, the one that looks like a bar of soap. My wrist was in very bad pain, and switching mice fixed it immediately.
Or the ridiculous Spring abstractions that many people insist on?
The former is a minor nuisance, easily filled in by an IDE. The latter is far worse, unnecessary bloat and complexity. Architecture Astronaut stuff.
- Don't get too fundamentalist about OO or functional programming. Each has its place.
- "Spend time hunting for an algebra" is somewhat obscure, but truly excellent advice, and I have spend a lot of my career doing exactly that. That has never been time wasted. This connects to a couple of other points. 1) Once you have an algebra, you have the basis of a good API for functional programming. (This point is not explicit in the list.) 2) The things manipulated by your algebra are also the basis of a good OO design.
- "Elegance is not a real metric." It is absolutely dangerous as a metric, because it is a subjective goal we all aim for, and can therefore be used to justify anything, no matter how dumb. That said, elegance is something to strive for in your day-to-day programming life. You know it when you see it in someone else's work, and you appreciate it. You see a small set of principles, implemented in one place, that can then combine in many ways to do many useful things. Hmm, sounds a lot like an algebra!
Bezos, Zuck etc. don't have that amount, in spite of their hundreds of billions, or else they wouldn't be doing what they are doing. "Yes, but they have to do this to maintain their businesses that are subject to Trump's whims." No they don't. They could put someone else in charge, take a few dozen billion, and still live fabulous lives, independent of Trump. Let someone else do the ass-kissing. But they choose not to do that.
In many scenarios (including JOOQ and all ORMs), X is SQL. I should know, I spent years working on a Java-based ORM. So believe me when I say: ORMs are terrible. To use SQL effectively, you have to understand how databases work at the physical level -- what's a B-tree lookup, what's a scan, how these combine, etc. etc. You can often rely on the optimizer to do a good job, but must also be able to figure out the physical picture when the optimizer (or DBA) got things wrong. You're using an ORM? To lift a phrase from another don't-do-this context: congratulations, you now have two problems. You now have to get the ORM to generate the SQL to do what really needs to be done.
And then there are the generalizations of point made above: There are lots of tools that work with SQL. Lots of programmers who know SQL. Lots of careers that depend on SQL. Nobody gives a shit about your ORM just because it saves you the trouble of the easiest part of the data management problem.
Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.
Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.
That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.
As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.
HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).
I worked at my first consumer-oriented tech company, right after the dotcom crash. It was a really unexciting interlude in my career. I was given the job of writing the database and Java representation of credit/debit cards, and the related business logic. As often happens, the code grew over time, as requirements and card types were added. And it was finally time for a rewrite, and this code became a poster child for technical debt.
Startup activity resumed, and I left for a far more interesting startup.
Then, maybe 15 years later, I was retired, and doing consulting, and ran into a friend from the company, who told me that a new company doing something very similar, and was looking for help. I go in and talk to them, and discover that they actually licensed the software from my former company. Including my long-in-the-tooth credit/debit/xyz-card software. The code was still completely recognizable, disturbingly so. It lived on far past the point that it should have.
I decided to not take the consulting job. I really did not relish the idea of going back to this very forgettable and uninteresting code. But most importantly, I had just retired, and wanted to spend my summer on a lake, not keeping this code alive a bit longer.