> I believe that the benefits of static typing somewhat decrease in the web arena

I’ve seen this sentiment expressed numerous times and have never found it to be true in my own work (e-comm), do you mind mentioning _what_ type of domain your web apps are in?

Edit: or if not domain, what do you mean by “web arena”

I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing is just getting some JSON and doing something with it, I'd rather just have the dynamic shape of the JSON in a lot of cases than have to declare an entire schema/codec.

We have so much boilerplate and tooling to share request/response types between services and it's just... heavy. The same feeling arises when I'm sitting here trying to share a shape between a web app and the backend service, where FINALLY I just want the types to get out of my way instead of having to go through all this ceremony.

And my domain is relatively precise and typeable - streaming video with a deterministic set of parameters.

Generally though I'm more likely to agree with the value of types than to undersell them; I just can't find a ways to describe the above experiences such that they reflect that perspective.

I think it's not that I don't want types, it's that I want simple types that play slightly more dynamically - maps of <string, heterogeneous values>, for example, and reasonable means of interacting with them (like various "safe traversal" operators that some languages have added).

In my experience it's boiled down to the type of data you're working with. Building nested, tree-like structures and then submitting that structure to the back-end as one request is more easily done via the front-end than a bunch of back-and-forth requests followed up by a "commit" request.

edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.

>These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.

I think you're right, and if that's the case, aren't these libraries (Lowtype, Literal) more akin to Design by Contract mechanisms?

Regarding Message Passing and Late-binding, I think it's important to take into account that Alan Kay was working on Smalltalk -- a system that was image based; a system where you could change things as it was running. I think that message passing and late-binding are often championed but then sort of fall flat given standard deployment techniques: build & deploy (often to a ephemeral runtime / container).

Smalltalk can use build & deploy. (Image as cache, not archive.)

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."

1984 "Smalltalk-80 The Interactive Programming Environment" page 500

Yes, you could also build and deploy a Smalltalk system, but my point is that the “build & deploy” approach (to me) seems antithetical to the message passing and late-binding paradigms. To use another example, it seems like you lose a lot of the benefits of Common Lisp via Slime (hot code reloading) if you deploy your Common Lisp app to a short-lived, ephemeral environment.

> (to me) seems antithetical to the message passing and late-binding paradigms

(To me) seems like build & deploy as dev process and message-passing & late-binding as implementation technique.

Separate concerns, I probably misunderstood.

Here's another thread talking about IO- vs CPU-Bound Rails apps from 10 months ago: https://news.ycombinator.com/item?id=42820419

I inherited a project where this was taken to the extreme. We have a class that's used to calculate final pricing taking into account discounts, coupons, shipping fees (or free shipping). Each one of those values was implemented as methods but then we have a call like: method_a - method_b + method_c, but it turns out, method_a may be adding shipping_cost for it to then be subtracted out in method_b. We ended up refactoring this and removing all the needless methods and just have a simple inline calculation. Definitely not "clean".

Interesting. If one were to legally change their name to their desired DBA name, I wonder how that would go over.

Legal name changes are handled in state courts, so there may be different rules depending on your state, but generally I think you could get away with it if you really wanted to... but doing business as a sole proprietor means you are personally liable for everything the business does. Way simpler and better to just form an LLC in most cases.

[US Government] Shutdown With No Clear End Poses New Economic Threat, for those who lack the context.

I'm not sure if you've tried it or not, but sdkman.io is a really handy JVM ecosystem environment manager that makes getting Java (and other JVM langs) really easy to install and switch between.

Windows 2000 was really solid IMO. I have really fond memories of learning and using it at school back around that time.

True, and it was some sort of "new technology".

Although quite some applications could not run on it, due to compatibility issues, so it is not in the list.