Hacker News Reader

Comment by karma_vaccum123 | Hacker News Reader

the author recognized one problem (hairball perl left undocumented by previous coworker) but replaced it with another problem (overly complex and needlessly configurable java)

what the author replaced was a classic "first system"...but he created a classic "second system".

I wish people would just realize that the best route is to solve the problem at hand...and JUST the problem at hand, with the smallest and simplest codebase possible....these tend to be the near-optimal "third systems" that eventually emerge.

View on HN

There is distinction between the scenario you describe, and the goal of YADA, which is that with YADA we strive to make the first (or existing) system useful, and to keep the bar low, by favoring the indispensable skills like SQL; or, to simplify the first, second, third, or whatever system by reducing the number of components, redundant configurations, and points of failure. Further, YADA facilitates solving a problem that many of the optimal systems create, those related to workflow, collaboration across teams, efficiency, repurposing, etc.

Thanks for taking the time to review and comment!

100 times this. What's the rule about frameworks? "Every system evolves towards supporting arbitrary programming|turing completeness". Something like that.

This could be true, yes.

But I have the feeling, that good frameworks still make some stuff easier than others, while supporting arbitrary programming/turing completeness.

For example Cycle.js, which is a structural framework for reactive programming with observables. It's made for front-end developoment, but I can also model REST and WebSocket servers with it, since almost everything can be modeled as a mix of source-streams + (input-data) sink-streams (output-data).

Since it uses observables all over the place, it makes handling these data-streams much easier an clearer, by making them first class citiziens in the app.

>almost everything can be modeled as a mix of source-streams + (input-data) sink-streams (output-data)

true. This is pretty much what i have been doing for 25 years and will be doing for the next like 20.

Reminds me about the time when one guy we had around read a book on finite state machines. It was, dare i say, an eye-opener for him. Since that moment until he parted with us, all what he was doing was FSAs.

lol, sounds a bit like he did Heroin. :D

Yep. I have found the mantra "Build what you need" works best.

Only once you end up having to solve a separate problem that shares common attributes/patterns with the first should you you extract a common framework and rebuild both on it. You have a proven need and you're not just blindly building "someday this could be used for"-type code.

Reply on news.ycombinator.com