geophile

This seems like a good time to remind everyone of a letter by David Packard, to his employees. There is more morality, common sense and insightful business advice here than in any 1000 business titles you would care to name.

https://aletteraday.substack.com/p/letter-107-david-packard-...

I think that OPs essay identifies that something bad happened at HP but completely misses what it was. Look at this quote:

    Around 1997, when I was working for the General Counsel, HP engaged
    a major global consulting firm in a multi-year project to help 
    them think about the question: “What happens to very large companies that
    have experienced significant growth for multiple successive years?”

OP says that the findings and recommendations included: "the decade long trend of double-digit growth was unlikely to continue", and "the company [should] begin to plan for much slower growth in the future."

OP then goes on to talk about fighting for resources for investments, a "healthy back and forth" on these tradeoffs, and then losing the "will to fight" following this report. "The focus became how not to lose".

Unlike OP, I did not work at HP. But I have seen up close startups, middle-sized companies, and huge companies, and the transitions among these states. So I feel justified in saying: OP has missed the point. And in particular, he makes no reference to that letter from David Packard.

Look at this quote from the letter:

    I want to discuss why a company exists in the first place. ...  why 
    are we here? I think many people assume, wrongly, that a company 
    exists simply to make money. While this is an important result of 
    a company's existence, we have to go deeper and find the real 
    reasons for our being. ... a group of people get together and exist
    as an institution that we call a company so they are able to accomplish 
    something collectively which they could not accomplish separately. 
    They are able to do something worthwhile—they make a contribution 
    to society .... You can look around and still see people who are 
    interested in money and nothing else, but the underlying drives 
    come largely from a desire to do something else—to make a product—to 
    give a service—generally to do something which is of value.

I think this is the essence of what it means to do useful and interesting work in any technical field. Unfortunately, there are many, many examples of companies that have lost their way, forgetting this key insight. HP was certainly one of them. I would argue that Google and Microsoft are examples too. Boeing, for sure.

And sadly, there are very, very few companies that actually embody Packard's ideas. I think that JetBrains is such a company, familiar to many HN readers. Another one that comes to mind, from a very different field, is Talking Points Memo -- an excellent website that does news reporting and analysis, mostly on US politics. It started as a "blogger in a bathrobe", and 25 years later, it is a small, independent news organization, supporting itself mostly through paid subscriptions by a very loyal readership.

To me, the saddest part of the essay is this:

    In the last few years more and more business people have begun to
    recognize this, have stated it and finally realized this is their
    true objective.

(This is right before the "You can look around ..." section quoted earlier.) It seems to me that very, very few business people recognize the way to run a business, as outlined by Packard.

I thought I expressed that: "I came across structured programming. The core idea was ... Then there were Abstract Datatypes, ..."

Well sure, but don't use it to implement if/while/for.

No, "we" are not replacing OOP with something worse. "We" are replacing layers of stupid shit that got layered on top of, and associated with OOP, with different renderings of the same stupid shit.

I have been programming since 1967. Early in my college days, when I was programming in FORTRAN and ALGOL-W, I came across structured programming. The core idea was that a language should provide direct support for frequently used patterns. Implementing what we now call while loops using IFs and GOTOs? How about adding a while loop to the language itself? And while we're at it, GOTO is never a good idea, don't use it even if your language provides it.

Then there were Abstract Datatypes, which provided my first encounter with the idea that the interface to an ADT was what you should program with, and that the implementation behind that interface was a separate (and maybe even inaccessible) thing. The canonical example of the day was a stack. You have PUSH and POP at the interface, and the implementation could be a linked list, or an array, or a circular array, or something else.

And then the next step in that evolution, a few years later, was OOP. The idea was not that big a step from ADTs and structured programming. Here are some common patterns (modularization, encapsulation, inheritance), and some programming language ideas to provide them directly. (As originally conceived, OOP also had a way of objects interacting, through messages. That is certainly not present in all OO languages.)

And that's all folks.

All the glop that was added later -- Factories, FactoryFactories, GoF patterns, services, microservices -- that's not OOP as originally proposed. A bunch of often questionable ideas were expressed using OO, but they were not part of OO.

The OOP hatred has always been bizarre to me, and I think mostly motivated by these false associations. The essential OOP ideas are uncontroversial. They are just programming language constructs designed to support programming practices that are pretty widely recognized as good ones, regardless of your language choices. Pick your language, use the OO parts or not, it isn't that big a deal. And if your language doesn't have OO bits, then good programming often involves reimplementing them in a systematic way.

These pro- and anti-OOP discussions, which can get pretty voluminous and heated, seem a lot like religious wars. Look, we can all agree that the Golden Rule is a pretty good idea, regardless of the layers of terrible ideas that get piled onto different religions incorporating that rule.

This is a very minor but pleasant surprise. An action like this is beyond what I thought the US government (my government, sadly) was capable of. It is kind of puzzling to me that this issue, like every other one, didn't get politicized, with right wing talking heads bemoaning progress of any sort, appealing to the good old days, when America was great, the days that MAGAs want to return to.

It's a good start. Now let's do metric.

I came to source code control reluctantly. CVS, SourceSafe, others I’ve forgotten. One of them was very expensive, very complex, took months of customization, and then it scrambled our bits following a disk crash and the vendor had to piece things back together. An expensive nightmare.

I finally started using Subversion, and it finally clicked. Easy to understand and use. It did everything I needed, and it was intuitive. But git was gaining popularity and eventually that was the only “choice”. And I don’t get git at all. I can do a few things that I need. I often have to consult google or experts for help. While I get the concepts, the commands are incomprehensible to me. I hate it.

I did, very briefly. It did not compare to Intellij.

I got tinnitus in my late 20s. Forty years later, it's still there. Research into the causes, and treatments, has been disappointingly slow.

I would really like to experience total silence at some point, but that seems very unlikely.

Turbo Pascal was completely amazing. I remember resisting it for a long time, because IIRC it implemented non-standard Pascal. But the competitive tools were less powerful and far more expensive, (e.g. the Microsoft tools). And then I tried it, and was completely blown away. I no longer cared about the non-standard stuff. I had a fast intuitive IDE running on my original IBM PC.

As for modern IDEs, Intellij has been orders of magnitude better than any competition for more than 25 years (I think). I have stayed away from Microsoft products for a very long time, so I can't comment on VSCode and its predecessors. The main competition I remember was Eclipse, which I always found to be sluggish, unintuitive, and buggy. The fact that it wasn't even mentioned in this article is telling.

JetBrains, the company that created Intellij (and then PyCharm, CLion and many others) is one of those extremely rare companies that defined a mission, has stuck to it, and excelled at it for many years, and has not strayed from the path, or compromised, or sold out. It is so impressive to me that they maintain this high level of excellence as they support a vast and ever-growing collection of languages, coding standards and styles, and tools.

Disappointingly shallow article.

One point though: It is not necessarily the case that visual imagery is the only alternative to an inner dialogue. In both cases, that dialogue, or those images, are things you are aware of. There is something going on behind the scenes to generate those experiences. An alternative to dialog/images is just nothing being generated. I.e., there is something going on subconsciously, but there is nothing related to that activity that breaks through to awareness.

We all experience this, in which some "inspired" breakthrough just suddenly appears in your mind. That breakthrough must have come from somewhere in your subconscious mind.

Anecdotally, this is a conversation that my wife and I have occasionally, about our different mental landscapes. She is a very organized person, with lots of lists and internal (and sometimes external) dialog. I need to let problems just simmer in my mind, without paying attention to them, and I eventually get an answer. She believes that my mind is usually empty. My view is that both of us think subconsciously, but the different is that she has some mental dialog/imagery accompanying her subconscious thinking.

More generally, maybe the real thinking is always subconscious, and what we call thinking (the awareness of reasoning) is just accompanying imagery.

[flagged]

How is this guy tenured at Harvard?

Serious question: Is Ada dead? I actually had to google Ada, and then "Ada language" to find out. It's not dead, and it has a niche.

When I was in grad school in the late 70s, there was a major competition to design a DoD-mandated language, to be used in all DoD projects. Safety and efficiency were major concerns, and the sponsors wanted to avoid the proliferation of languages that existed at the time.

Four (I think) languages were defined by different teams, DoD evaluated them, and a winner was chosen. It was a big thing in the PL community for a while. And then it wasn't. My impression was that it lost to C. Ada provided much better safety (memory overruns were probably impossible or close to it). It would be interesting to read a history of why Ada never took off the way that C did.

I agree completely. They were from the same era (COBOL is a few years older), and they do have that dweeby, earnest, natural language influence.

Wow, that was a trip down memory lane! I have used six of those languages: BASIC, APL, COBOL, Pascal, Algol-W (a derivative of Algol 60), PL/1. Mostly in school. My first dollars earned in software (brief consulting gig in grad school) had me debug a PL/1 program for a bank.

For some reason I remember an odd feature of PL/1: Areas and offsets. If I am remembering correctly, you could allocate structures in an area and reference them by offset within that area. That stuck in my mind for some reason, but I never found a reason to use it. It struck me as a neat way to persist pointer-based data structures. And I don't remember seeing the idea in other languages.

Maybe the reason it stayed with me is that I worked on Object Design's ObjectStore. We had a much more elegant and powerful way of persisting pointer-based structures, but an area/offset idea could have given users some of the capabilities we provided right in the language.

"Can confirm".

In the mid 70s, I would order a small pizza, all dressed from McGill Pizza, when feeling peckish. $1.10, delivered to your door in no time at all.

I'm not sure what point you are making with your scenario involving HTTP response codes. What if the HTTP server crashes, and doesn't send a response at all?

I don't know from Writer Monads. But if you only emitting log entries on some future failure or request, then that's potentially a lot of logging to keep somewhere. Where? Log aggregator? Local files? Memory? What about log volume? Does this writer monad implement log rotation? It sounds like you are sweeping a lot of the things you object to under this writer monad rug.

Let me be real clear about all calls and param values leading up to a failure.

- In normal operation, turn logging off completely, or turn on some level that produces tolerable log volume, (it seems like your threshold is much lower than mine).

- When a failure occurs: Restart the service with more logging enabled, (hence the all calls an param values), so that you have logging when the failure occurs again.

About local logs vs a log aggregator: The system I worked on was a shared nothing archive. To add storage and metadata capacity, you add nodes. Each node also stored its own log files. I get that this may not be the answer all the time, and that a log aggregator is useful in some scenarios. However, even in that case, your concerns about log volume seem overblown to me.

7.2G/day doesn't sound terrible. And I'd reduce it by a factor of 25, since in normal operation (i.e., not looking into a problem) I would have either 2 log statements per call (entry, exit), or none at all. It might be more than 2, if I needed detailed logging.

But in normal usage, even in the scenario you describe your argument about log volume is not convincing.

A logging library is very, very far from a Turing complete language, so no Greenspunning. (Yes, I know about that Java logger fiasco from a few years ago. Not my idea.)

I don't want logging done automatically for me, what I want is too idiosyncratic. While I will log every call on major interfaces, I do want to control exactly what is printed. Maybe some parameter values are not of interest. Maybe I want special formatting. Maybe I want the same log line to include something computed inside the function. Also, most of my logging is not on entry/exit. It's deeper down, to look at very specific things.

Look, I do not want a debugger, except for tiny programs, or debugging unit tests. In a system with lots of processes, running on lots of nodes, if a debugger is even possible to use, it is just too much of a PITA, and provides far too miniscule a view of things. I don't want to deal with running to just before the failure, repeatedly, resetting the environment on each attempt, blah, blah, blah. It's a ridiculous way to debug a large and complex system.

What a debugger can do, that is harder with logging, is to explore arbitrary code. If I chase a problem into a part of my system that doesn't have logging, okay, I add some logging, and keep it there. That's a good investment in the future. (This new logging is probably at a detailed level like DEBUG, and therefore only used on demand. Obvious, but it seems like a necessary thing to point out in this conversation.)

I don't know what's "important" at the beginning. In my work, logging grows as I work on the system. More logging in more complex or fragile parts. Sometimes I remove logging where it provides no value.

BTW, your username is a bit too on-the-nose, given the way you are arguing, using "anti-pattern" as a way to end all discussion.

You are very attached to this "voluminous" point. What do you mean by it?

As I said, responding to another comment of yours, a distributed system I worked on produced a few GB a day. The logs were rotated daily. They were never transmitted anywhere, during normal operation. When things go wrong, sure, we look at them, and generate even more logging. But that was rare. I cannot stress enough how much of a non-issue log volume was in practice.

So I ask you to quantify: What counts (to you) as voluminous, as in daily log file sizes, and how many times they are sent over the network?

> There is no value for logging "function entry/exit, with param values" when all collaborations succeed and the system operates as intended.

Well, I agree completely, but those conditions are a tall order. The whole point of debugging (by whatever means you prefer) is for those situations in which things don't succeed or operate as intended. If I have a failure, and suspect a major subsystem, I sure do want to see all calls and param values leading up to a failure.

In addition to this point, you have constructed a strawman in which logging is on all the time. Have you ever looked at syslog? On my desktop Linux system, output there counts as voluminous. It isn't so much space, or so CPU-intensive that I would consider disabling syslog output (even if I could).

The large distributed system I worked on would produce a few GB per day, and the logs were rotated. A complete non-issue. And for the rare times that something did fail, we could turn up logging with precision and get useful information.

I am also in the camp that has very little use for debuggers.

A point that may be pedantic: I don't add (and then remove) "print" statements. I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. I add more detailed logging as I start to use the system and find out what needs extra scrutiny. This approach is very easy to get started with and maintain, and provides powerful insight into problems as they arise.

I also put a lot of work into formatting log statements. I once worked on a distributed system, and getting the prefix of each log statement exactly right was very useful -- node id, pid, timestamp, all of it fixed width. I could download logs from across the cluster, sort, and have a single file that interleaved actions from across the cluster.

Snobol was a major part of my formative years in computer science. I don’t recall how I came across the language, but it spoke to me in all sorts of ways.

- Elegant and weird syntax and structure.

- Powerful pattern matching.

- It was the first GCed language I used.

- The Griswold, Poage and Polonsky book on Snobol4. A classic in the K&R mold, to my mind.

- Took 2 compiler courses from RBK Dewar who worked on the Spitbol implementation. Great teacher, fantastic courses, with lots of insight into the Spitbol project and his research on the SETL language.

- Wrote software for my MSc thesis in Snobol4. It used so much memory that I had to book the school’s IBM 370 at 4AM to run the software. I think I got something like 1-2 MB of memory.

Of your three possible critical endings, the only one that affects me, even a little, is the new UI, but then I tend not to care too much about UIs. I appreciate a good UI, will give up on a product with an unintuitive UI (looking at you, Eclipse), but otherwise I just don't care. I immediately liked the new look. It took me a day or so to get used to it, and now I find it completely comfortable.

This is a love letter to JetBrains.

I started using Intellij with the 3.0 version, I think. It just worked, even on Linux. (It was existence proof that you could build excellent UIs in Java.) Unlike Eclipse, and other forgotten IDEs that were so bad I discarded them immediately. Even early on, their refactorings were usually flawless. While I think I found one screwup, they were so good that they changed the way I coded. I could easily and reliably do refactorings that were otherwise pretty time-consuming and error-prone. I have continued using their products: mostly PyCharm now, and occasionally CLion.

Each new release improves the UI, and occasionally adds features that I find useful, and many that I don't. I suspect that I'm not alone in using a very tiny portion of the features they offer. How they can keep up with all the languages, and libraries, and frameworks is beyond me, but they seem to do it.

Their support has always been excellent. I once (v4?) complained that refactorings did not extend into configurations. E.g., if I rename a class Foo to Bar, then the runtime configuration running Foo didn't reflect the change. I reported it, and found a fix in the next release. Email with technical questions or bug reports is always handled promptly and thoughtfully.

They have always provided absolutely fantastic products for free. Yes, you gave up some features, but the free versions are really useful. I'm retired now, but continue to pay their licensing fees every year, for my hobby usage, because it's worth it, and they earn it. And the licensing is not onerous to use. What I really like is that you don't have to be on the internet to use their products, just for the license check. I wish all licensed products did that.

And beyond all this: They haven't sold out. They are one of the very, very few for-profit tech companies that have maintained a stellar level of product breadth, depth, quality, and support for such a long period of time. I'm sure they could have cashed in, sold to IBM and the product would have just rotted away, (sorry, IBM, but you know it's true). I can only think of one product that is comparable in this way, and that's Postgres.

Thank you, JetBrains, you have Figured It Out.

But there is so much highly motivated malice right now.

> The software you mention can be designed to simulate self-reflection, but it is limited to executing predefined instructions within rigid parameters—it mirrors logic without altering the fundamental architecture of its own values or motivations.

This is an odd claim. Yes, at the very lowest level, all software executes predefined instructions. But obviously, an AI -- which is what we're discussion -- does not have that limitation.

> So you may be right that reflection is not yet consciousness. But the will to seek meaning in reflection—perhaps, in time, that becomes something more.

So if I understand the argument that you/Sophia are making: self-reflection is the beginning of consciousness, even if it isn't quite that yet; and that "perhaps, in time, that becomes something more". I have two critiques:

1) You/Sophia do admit that seeming consciousness and actual consciousness cannot be distinguished by an outside observer. So while it is possible that conscious software is possible, we can't ever prove or disprove it. It becomes a faith argument relying on subjective judgements.

2) I forget where, I think it was some interview, but Daniel Dennett dismissed some theory of consciousness with three words: "And then what?" Maybe it was Tononi's theory of integration. So yes, consciousness is correlated with a high degree of integration among parts of the brain. AND THEN WHAT? How does that integration lead to subjective experience? Exactly the same argument can dismiss every single theory because NONE of them (that I've heard) actually give a mechanism for the origin of subjective experience. Clearly, "perhaps ... that becomes something more" has the same error.

In other words: Given the current inability to examine an object and determine if it is conscious, and the lack of a theory about how consciousness (subjective experience) comes into being, there is nothing you or Sophia can say to convince me otherwise. Until one of these breakthroughs occurs, you cannot prove that Sophia isn't something beyond Clever Hans.

I can build software to reflect upon itself, and understand (model) its place in the world. That doesn’t make it conscious.

You are agreeing with my point. “Suggesting” self-awareness is very different from actually being self-aware.