strictfp

I've seen work environments that are chaotic, and people are expected to deliver things that they can't deliver without navigating and taming the chaos to do their bidding.

If course that's stressful. You can't expect individuals to tame the organization.

I think some parts of IT have deteriorated into anarchy with tyrannic leadership.

Sure, you can have anarchy. But then don't expect any particular timelines.

You can hire armies of people. But then don't expect one corner of the org to be able to deliver something that involves talking to everyone.

You can't have the cake and eat it too.

That's true. But that's only really a concert if you're building an SPA. If you're not, having multiple pages is generally faster than running some js framework to reload parts of the page. Plus that you get the benefit of every state combination having it's own URL. You don't need to write any custom state reconstruction code.

This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.

Node is essentially a single-threaded API to a very capable multithreaded engine.

https://youtu.be/ztspvPYybIY

My tip for this is Node.js and some stream processing lib like Highland. You can get ridiculous IO parallelism with a very little code and a nice API.

Python just scales terribly, no matter if you use multi-process or not. Java can get pretty good perf, but you'll need some libs or quite a bit of code to get nonblocking IO sending working well, or you're going to eat huge amounts of resources for moderate returns.

Node really excels at this use case. You can saturate the lines pretty easily.

Reminds me of the 90s EDM band Antiloop.

Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.

I disagree with the problem statement; that the framework is trying to solve a meta-problem.

The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin.

This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompatible with other frameworks and libs etc.

Contrary to that, a library does one thing and one thing well. Like a Unix tool. Much easier to use, better coverage, and usually easy to combine. And you can plug them in anywhere.

Frameworks are overreaching, but not in the way that the article paints it.

Class diagrams and object diagrams are also really useful, for instance when making presentations.

The problem with UML is that the industry went overboard with it's usage, like it did with pretty much every tech trend.

I'm interested to hear their business plan, given that there's already established ones like https://elastx.se/en/, and they're not running terribly well, although they have quite a good product IMO.

Hot take: the mobile site also isn't good for cellphones

They've been pulling shady stuff for ages. Ever heard of the false flag attacks in relation to Cuba? The bay of pigs false flag bombings, and the proposed https://en.m.wikipedia.org/wiki/Operation_Northwoods ? Terrible stuff.

They could solve that by keeping track of references and asking you though.

I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense.

But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practice to me. I'm seeing more and more of that in our systems.

I think ECSes are becoming too dynamic, and will start to eat perf, and hide relations. Like some message bus.

Anyone else with the same gut feeling?

Yes. If you design a distributed system you need to consider the network traffic very carefully, and choose your segmentation in such a way that you minimize traffic and still achieve good scalability.

For this reason, I've been trying to push for building a monolithic app first, then splitting into components, and introducing libs for common functionality. Only when this is all done, you think about the communication patterns and discuss how to scale the app.

Most microservice shops I've been in have instead done the naïve thing; just come up with random functionally separate things and put them in different micro services; "voting service", "login service", "user service" etc. This can come with a very very high price. Not only in terms of network traffic, but also in debuggability, having a high amount of code duplication, and getting locked into the existing architecture, cementing the design and functionality.

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components.

What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail.

You also cannot produce any meaningful end-user value without involving several teams.

Microservices is just "backend, frontend, and database team" reincarnated.

My take: do Microservices all you want, but don't organize teams around the services!

Yup. If you consider that a simple int can have billions of states, and that you can have 100% test coverage while testing just one of those, 100% really doesn't mean much. And with several variables, the total state space quickly becomes almost infinite.

I'm saying that references between heaps should be disallowed altogether.

Ooooh, thanks for mentioning that!

I've been following your school of thought as well as the one proposed by the author.

I would argue that your model is a lot freer and will lead to better code quality in the long run, since you're not feeling so restricted when working.

Meticulously crafting commits feel like one of those "good in theory" approaches that feels good but hurts you more than you realize. They're good for workflows where you move commits between lots of (release) branches, sure, but if you're doing trunk-based development I'm going to call it a bit formalistic.

I would love it if some language would implement a segmented heap, where each part could be GCed separately.

Erlang has this model with it's lightweight processes. And it's a great model that helps not only with GC, but also guaranteeing no shared state between different parts of the code.

Bugzilla is still one of the best, change my mind :D

A simple list is a pretty good solution IMO.

Aside from Trello and friends, Azure boards is actually also pretty OK, if you disregard their very confusing naming and weird menus. It's fast and easy to use in the board view.

The harsh truth is that you need to think about every single case of failure, and decide what to do when things go south.

If you look at how POSIX does it, pretty much every single function has error codes, signaling everything from lost connections, to running out of memory, entropy or whatnot. Failures are hard to abstract away. Unless you have some real viable fallback to use, you're going to have to tell the user that something went wrong and leave it up to them to decide what the application can best do in this case.

So in your case, I would return Result<T>, and encode the errors in that. Simply expose the problem to the caller.

Cue VPNs being banned

Generally I would say yes. POSIX dictates that a line must end in newline, and some tools rely on it. See https://stackoverflow.com/a/729795

Interesting. I'm not arguing, but I'm very interested in this history, because I was personally bit by Java EE.

The EJB wikipedia page says that IBM developed the first version

The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems

, and there's also some other references online about "San Francisco" being folded into EJB;

The San Francisco Project (SFP) basically failed, with much of the technology being folded into other efforts, notably Enterprise Java Beans (EJB) in 1998.

https://redmonk.com/jgovernor/2005/11/07/time-for-ibm-to-res...

https://en.m.wikipedia.org/wiki/Jakarta_Enterprise_Beans

Might it have been a combination of both?

Interesting. I can't find any sources for the IBM story, but I thought I read it here on HN. I found at least one similar comment; https://news.ycombinator.com/item?id=30538784 .

So you're saying it was just Sun and not IBM?

In a sense this is about the fundamental difference between frameworks and libraries. So to a certain extent, you're right. But there's extra complexity in not knowing why some annotation was picked up. With any API call you know you're trying to register something and can debug into it. With an annotation project you're sometimes stuck at "nothing happens".

Which is also true for node projects I guess :D

And the metaprogramming comment stands IMO.

This is why I left Java. Everything "looks nice" on the surface with annotations, but you loose the flexibility of code and a lot of the available tooling. Plus you need to be a real expert to debug issues and solve problems; understand framework architecture and read reflection code. You can't just put a breakpoint in there and start debugging. It's optimizing for the wrong thing.

The bad news is; this culture is permeating somewhat into Rust now that more Java devs are moving over.

This whole attitude is IBMs fault. They tried to get into the Java market by applying their big iron terminal thinking to create Java EE.

Java under Suns management was a lot more like golang today; pragmatism, fewer language features, and focus on writing code.

This sounds very similar to how Jetbrains tried to improve on Java but in the end deciding to invent Kotlin; a new language with more consise syntax, better defaults, some new features, and great interop back and forth with Java.