Scubabear68

This is a really good observation, and matches something I had to learn painfully over 30 years ago. At a Wall Street bank, we were trying to really push the limits with some middleware, and my mentor at the time very quietly suggested "before you test your system's performance, understand the theoretical maximum of your setup first with no work".

The gist was - find your resource limits and saturate them and see what the best possible performance could be, then measure your system, and you can express it as a percentage of optimal. Or if you can't directly test/saturate your limits at least be aware of them.

> Cybertrucks are for pioneers.

Well, here in NJ at least, Cybertrucks are not for pioneers, but inevitably for wealth signaling of mostly clueless people to show they have cash to throw away.

There are of course many wealth signaling cars, but the Cybertruck is in a special noisome class all its own.

From what I recall, one of the hazards of long term space travel is that nearly any material will start sublimating atoms in the hard vacuum of space, with things like cosmic rays adding to the woes. Some over time it will start deteriorating.

Not sure about “melting” into an amorphous mass, I guess in theory the probes gravity could do that, but I would imagine even the tiniest force would disturb that and dissipate it.

That's a nice narrative but very revisionist.

Microservices came about because Netflix and soon some other FAANGS found they were so big that it made sense to make single-function "micro"-services. They literally chose to massively duplicate functionality across services because their scale was so big it made sense for them.

This is great for FAANG-scale companies.

It makes little sense for most other companies, and in fact incurs all of the overhead you would expect - overly complex architecture, an explosion of failure points, a direct elongation of latency as microservices chain calls to each other, chicken-and-egg circular references among services, and all of the mental and physical work to maintain those dozens (or hundreds, or thousands!) of services.

The funny thing to me is people point to monoliths and say "see, problem waiting to happen, and it will be so hard to undo it later!". But I see microservices, and usually the reality is "We have problems right now due to this architecture, and making it sane basically means throwing most or all of it away".

In reality, unraveling monoliths is not as hard as many people have made out, while reasoning about microservices is much harder than advertised.

Tooling in particular makes this a very hard nut to crack. Particularly in the statically typed world, there are great tools to verify large code bases.

The tooling for verifying entire architectures - like a huge set of microservices - is way behind. Of course this lack of tooling impacts everyone, but it makes microservices even harder to bear in the real world.

Forget about convenient refactoring, and a thousand other things....

Sorry, you lost me at "hence the name".

Microservices was originally envisioned to literally create the smallest possible service you could, with canonical Netflix use cases being literally only one or two endpoints per microservice.

Which is great I guess for FAANGs. But makes no sense for just about anyone else.

I know one place that did all of their transactional payment flow through lambdas. There were about 20 lambdas in the critical auth path, and they regularly hit the AWS per-global-account limits.

Another place did all their image processing via lambdas, about fifty of them. They literally used lambdas and REST calls where anyone sane would have done it in one process with library calls. It cost them tens of thousands of dollars a month to do basic image processing that should have cost about $100 or so.

I think the big problem no one speaks about is the name "microservices" was incredibly poorly named.

Your design goal should not be "create the smallest service you can to satisfy the 'micro' label". Your design goal should be to create right-sized services aligned to your domain and organization.

The deployment side is of course a red herring. People can and do deploy monoliths with multiple deployments and different endpoints. And I've seen numerous places do "microservices" which have extensive shared libraries where the bulk of the code actually lives. Technically not a monolith - except it really is, just packaged differently.

Somewhat related, one of my thoughts was “what if these concierge doctors just keep running tests until they find something, anything, to justify their fees”?

No, I haven't ignored those tools. They were all stop-gaps that worked in a "meh" way to various degrees. Smalltalk was always optimized to one guy banging away on their solution. Add a second developer and things got much hairier, and more so as you kept adding them.

I think we could quibble over the relative importance of these points, but I agree in general. The image locking you into that ecosystem is definitely a good point.

I disagree, it really was the image concept, or very specifically how it was created and maintained over time.

A docker container is composed typically of underlying components. You can cowboy it for sure, but the intent is to have a composable system.

The Smalltalk image resulted from the developer just banging on the system.

The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution.

The image meant you basically got whatever state the developer ended up with, frozen in time, with no indication really of how they got there.

Think of today's modern systems and open source, with so many libraries easily downloadable and able to be incorporated in your system in a very reproducible way. Smalltalk folks derided this as a low tech, lowest-common-denominator approach. But in fact it gave us reusable components from disparate vendors and sources.

The image concept was a huge strength of Smalltalk but, really in the end in my opinion, one of the major areas that held it back.

Java in particular surged right past Smalltalk despite many shortcomings compared to it, partially because of this. The other part of course was being free at many levels. The other half of Smalltalk issues beyond the image one, was the cost of both developer licenses ($$$$!) and runtime licenses (ugh!).

This brings back fond memories of Heinlein's juvenile sci fi series.

I have to disagree. There are many areas where things are extremely deterministic, regulated financial services being one of those areas. As one example of zillions, look at something like Bond Math. All of it is very well defined, all the way down to what calendar model you will you use (360/30 or what have you), rounding, etc. It's all extremely well defined specifically so you can get apple to apple comparisons in the market place.

The same applies to my checkbook, and many other areas of either calculating actuals or where future state is well defined by a model.

That said, there can be a statistical aspect to any spreadsheet model. Obviously. But not all spreadsheets are statistical, and therein lies the rub. If an LLM wants to hallucinate a 9,000 day yearly calendar because it confuses our notion of a year with one of the outer planets, that falls well within probability, but not within determinism following well define rules.

The other side of the issue is LLMs trained on the Internet. What are the chances that Claude or whatever is going to make a change based on a widely prevalent but incorrect spreadsheet it found on some random corner of the Internet? Do I want Claude breaking my well-honed spreadsheet because Floyd in Nebraska counted sheep wrong in a spreadsheet he uploaded and forgot about 5 years ago, and Claude found it relevant?

Having wrangled many spreadsheets personally, and worked with CFOs who use them to run small-ish businesses, and all the way up to one of top 3 brokerage houses world-wide using them to model complex fixed income instruments... this is a disaster waiting to happen.

Spreadsheet UI is already a nightmare. The formula editing and relationship visioning is not there at all. Mistakes are rampant in spreadsheets, even my own carefully curated ones.

Claude is not going to improve this. It is going to make it far, far worse with subtle and not so subtle hallucinations happening left and right.

The key is really this - all LLMs that I know of rely on entropy and randomness to emulate human creativity. This works pretty well for pretty pictures and creating fan fiction or emulating someone's voice.

It is not a basis for getting correct spreadsheets that show what you want to show. I don't want my spreadsheet correctness to start from a random seed. I want it to spring from first principles.

Random condensation is a great way to put it. This is exactly what I see particularly in email and text summaries, they do not capture the gist of the message but instead just pull out random phrases that 99.9% of the time are not the gist at all. I have learned to completely ignore them.

I’m not sure what you mean by Azure being more painful for FOSS stacks. That is not my experience. Old you elaborate?

However I have seen many people flee from GCP because: Google lacks customer focus, Google is free about killing services, Google seems to not care about external users, people plain don’t trust Google with their code, data or reputation.

Trying to be as kind as possible in my interpretation of the article, my take was that the author got stock on the "spherical cow" analogy early on and couldn't let it go. I think there are nuggets of good ideas here which generally tries to talk to leaky abstractions and impedance mis-matches in general between hardware and software, but the author was stuck in spherical cow mode and the words all warped toward that flawed analogy.

This is a great example of why rewrites are often important, in both English essays and blogs as well as in software development. Don't get wedded to an idea too early, and if evidence starts piling up that you're going down a bad path, be fearless and don't be afraid of a partial or even total rewrite from the ground up.

Object Relational Mapping (ORM) tools, which focus on mapping between code based objects and SQL tables, often suffer from what is called the N+1 problem.

A naive ORM setup will often end up doing a 1 query to get a list of object it needs, and then perform N queries, one per object, usually fetching each object individually by ID or key.

So for example, if you wanted to see “all TVs by Samsung” on a consumer site, it would do 1 query to figure out the set of items that match, and then if say 200 items matched, it would do 200 queries to get those individual items.

ORMs are better at avoiding it these days, depending on the ORM or language, but it still can happen.

I’m with you on that. I live in NJ and unfortunately I have to deal with bridges, fear of heights or no.

I would agree with you except the UI is so horrible.

Give me a spreadsheet with a world cksss user interface and then you’ll have something!

I've been involved in a lot of due diligence efforts, from the tech side but I've seen all angles of it as the deals are often fast and intense and the various teams have to often coordinate to a degree (tech, legal, financial, tax, etc).

It is fairly common for the people initiating the acquisition to really want to close it in a hurry, and they do due diligence only as a check mark in someone's list. As someone else here mentioned, there is enormous pressure to close, and any red flags are often redirected, reworded, or even occasionally just squashed.

The further away a company is from something like private equity, who does acquisitions like we eat breakfast every day, the more likely you are to see rushed and potentially botched due diligence. Someone like a big bank may well have the main proponent not know anything at all about acquisitions or due diligence, and just wants to "get 'er done".

It is also very common for people to come in after-the-fact and do a second diligence, and while doing that diligence to hear one or more people opening the conversation with "I warned them about this before the acquisition...".

At the end of the day, particularly in a big public corp, people are focused on their bonuses and total comp, and people like that aren't going into a due diligence looking for red flags and "no's".

Agree, the money is the key here.

I got started in the 1980s, and super-curious and technical people were the norm. We were incredibly strongly attracted to computers.

The first real growth in computers in that kind of era was Wall Street and banks. Wall Street in particular started paying huge bonuses to developers because it was clear that software could make huge piles of money. Then we started seeing more people joining in for the money who were not necessarily passionate about technology.

Then came the dot com era and bust, and then the rise of social media, FAANG, and absurd corporate valuations allowing ridiculous total comp to developers, and the needle moved even more towards money.

The net result is the curious and the passionate are still here, but our numbers are massively diluted.

I come places like here to find that passionate niche.

I wonder when an Android phone will be released that includes a vape attachment.

Don't think Apple would go there, but who knows....

Hunterdon. One of the richest counties in the United States.

I live in the US in New Jersey, and here a big problem was the State flooded school districts with money during Covid with no material oversight of its spending.

The end result was huge increases in spending. But not on education. The money was spent on more MacBooks, more iPads, more buildings, more smart TVs, more consultants, more School Bullshit System as a Service, more scoreboards, more $50,000 signs in front of schools.

Meanwhile the good teachers are fleeing the system and test scores are plummeting as schools focus more on day care and “social justice”, and a declining emphasis on teaching core subjects and learning in general, coupled with social promotion where everybody gets a C or higher, and 80% of the school gets on the honor roll (spoiler alert: our district is not some outlier where 80% of the kids are geniuses).

Schools have very little to do with teaching, and really are just about baby sitting and trying to correct social issues.

Oh, and endless buckets of tax payer money with meaningless oversight.

I get it.

YAGANI.

A term coined by consultants who don’t understand an industry who basically say “do the least possible thing that will work” because they don’t understand the domain and don’t understand what requirements are often non-negotiable table stakes of complexity you need to compete.

It reminded me of a Martin Fowler post where he was showing implementation of discounts in some system and advocating to just hard code the first discount in the method (literally getDiscount() {return 0.5}).

Even the most shallow analysis would show this was incredibly stupid and short sighted.

But this was the state of the art, or so we were told.

See also Ward Cunningham trying and failing to solve Sudoku using TDD.

The reality is most business domains are actually complex, and the one who best tackles that complexity up front can take home all the marbles.

This basically ruins the term “hallucination” and makes it meaningless, when the term actually describes a real phenomenon.

That it is ultimately about object lifetime management. Dependency injection is a big part of it, but not the only thing.

"Hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature".

I used to avidly read all his stuff, and I remember 20ish years ago he decided to rename Inversion of Control to Dependency Injection. In doing so, and his accompany blog, he showed he didn't actually understand it at a deep level (and hence his poor renaming).

This feels similar. I know what he's trying to say, but he's just wrong. He's trying to say the LLM is hallucinating everything, but Fowler is missing is that Hallucination in LLM terms refers to a very specific negative behavior.