Hacker News Reader

Comment by nitnelave | Hacker News Reader

It seems that after years of trying to develop programming languages and architectures to have separation of concerns, with the business logic, the presentation logic, and the data storage separated (or even going to full-blown microservices), this just... bunches everything together?

I get the appeal for a small program that fits in your head, but for anything more complex I don't want the code to take care of everything in a single module/file.

View on HN

The original promise of separation of concerns wasn't simply a code organization scheme, it was that we would be able to write composable software where components could be added or replaced with minimal systemic impact. We were going to be able to drop in new UIs without touching the BL or fix a bug in a component in one place and have it fixed everywhere, etc. The problem was that SoC, and the other various concepts from SOLID and design patterns didn't quite accomplish that - inter-dependencies remained and only became more difficult to reason about. Chasing this fantasy led object oriented programming down a path of increasingly complicated frameworks to try to manage and hide these dependencies until one would find themself thinking more about program structure and writing more plumbing code than doing actual work. Worse, now you have all the bits of logic necessary to understand how something works spread across multiple files so you have to have a system-wide understanding of a systems organization and understand the workings and vagaries of the half dozen or so different frameworks that were used to make it all seem magically loose-coupled. I'm sure there's some <insert name>'s Law somewhere that states it better, but it boils down to the fact that for any given set of tasks you can only reduce the complexity so much and anything else is just moving the complexity around, not eliminating it. I think there's something to be said for having all the logic you need to understand an interface in one or two files and focusing on making that as clean as possible, which is exactly what (at least some) of the 4GLs in the past seemed to do well, or at least made possible.

Beads uses the proven MODULE system of Modula-2 and Oberon. Of course we don't expect people to write in one single file. That the examples are small programs does not reflect the modular design of the language.

The entire purpose of the project is to build a world of software constructed by interchangeable parts. But to accomplish interchangeable parts, one has to make sure that there are as few external dependencies as possible, which is why the language has layout, drawing, event tracking, and database features pulled into the language, so as to not have one reaching outside, which would invariably break over time.

C proved that a standard library was a major feature of any language, and Beads has a well designed, but compact standard library, where you have a few functions, with lots of options so as to reduce the total number of functions one has to learn.

Wasn't Meteor.js trying to do that as well for the web a few years ago?

Meteor has a lot of users, and is still around. The problem with Meteor is that it uses JS, and that language has a lot of problems. Typescript has clobbered meteor, as people have realized that JS makes it far too easy to make a typographical error that crashes at runtime.

JS is still ahead of TS in usage according to the Tiobe Index and Github language commits. As far as typographical errors go, every already knew JS was a dynamic language, like Python and Ruby. I'd say other frameworks like React and Angular, or their predecessors out-competed Meteor.

Reply on news.ycombinator.com