I don't see Chefs complaining about the difference between getting better kitchen utensils versus working in a more functional kitchen. They go hand in hand.
Write Libraries, Not Frameworks
231–240 of 338 posts
Re: Write Libraries, Not Frameworks
#232Earlier quoted context omitted.
Spring class names are the stuff of legend, but most of those classes you wouldn't deliberately use in your application. They're there so Spring can layer up its own functionality feature by feature. The only problematic part about this is when these class names leak into error messages, and the level of indirection becomes difficult to follow. The way you use the core inversion-of-control framework people often just…
DI/IoC is just another way of expressing global variables. The global variables exist because of the constraint of class-orientation getting in the way, among other things. Spring exists because of the relative weakness of the Java language. You won't see this kind of technology emerging in more powerful languages.
This is very often the case. So often you see these stateless "service" classes injected everywhere. It's not an object at all, it just free functions packaged in a namespace with a vtable in front of it that now need to be allocated. A language with free function support alleviates that problem.
Re: Write Libraries, Not Frameworks
#233This discussion reminds me of one of my favorite quotes: "form is liberating". I always associated this with the sculptor Henry Moore, but the beauty of the idea is that it can be applied to all sorts of domains, whence it's also associated with Brook's Mythical Man Month about software development. The association here is that frameworks are "form". One might intuitively think that form/frameworks is/are constrainin…
1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself.
I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be.
Sure sometimes you will run into things that you fight the framework, but a good framework normally allows a "raw" way of doing it "by hand" instead of the sugary framework way that "just works (most of the time)". But most of the time it does work out fine and you can hop between other's proejcts/parts of the code and have instant familiarity and intent
Re: Write Libraries, Not Frameworks
#234Earlier quoted context omitted.
My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work! I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - req…
The problem with over-engineered projects... our team inherited a project that was designed by some architects in an ivory tower and implemented by some other engineers. It was quite complex (message queues, multi-threading, async etc.) so that it would be 'scalable' yet crushed under the slightest load, customers were experiencing delays during peak hours. We removed about a quarter of the code (some intermittent qu…
> Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope.
This is a very good attitude, but I would like to tack on a second part to it: Instead of designing your code to be infinitely extensible in all directions, make it easily replaceable instead.
It's impossible to anticipate every future requirement, but certain choices will make it easier to deal with a new requirement as it pops up. One of these things is unit tests. If you have some gnarly business logic with tons of edge cases, you really really want a good test suite because it enables you to add new edge cases with confidence.
Re: Write Libraries, Not Frameworks
#235Earlier quoted context omitted.
Even the CPU adds at least one layer of abstraction. Spring JVM Container OS hypervisor x86 Real CPU instructions Electrons Unknown EDIT: formatting
And "EDIT: formatting" is now an additional layer, too :)
That's the layer that's argued about the most. :)
Re: Write Libraries, Not Frameworks
#236The more I program, the more I am convinced that owning flow of control is one of my primary jobs as a programmer. If I surrender this to a framework, there are a lot of decisions I can't make with regard to performance, and I have a lot less certainty about when and in what order exactly things are executed. There are of course some exceptions, but in general I want libraries to provide me simple, synchronous functi…
Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function. (I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)
Try the "imgui" library?
Re: Write Libraries, Not Frameworks
#237I like microframeworks because they do one thing well and they don't in the way - like a library. When I use batteries-included frameworks, I end up not using a lot of what they offer.
Re: Write Libraries, Not Frameworks
#238Earlier quoted context omitted.
My comment in that discussion from ~15 years ago was based on experiences with a project that I "inherited" - 30,000 Java classes and interfaces, 20+ layers of abstraction, team of 30+ people working for a long time. And most importantly, it didn't actually work! I actually "finished" it to the point of a working system for the customer with real customers in about 5 weeks by ignoring most of what they had done - req…
The problem with over-engineered projects... our team inherited a project that was designed by some architects in an ivory tower and implemented by some other engineers. It was quite complex (message queues, multi-threading, async etc.) so that it would be 'scalable' yet crushed under the slightest load, customers were experiencing delays during peak hours. We removed about a quarter of the code (some intermittent qu…
I was where you’re at 15 years ago; my language of choice was C++/Boost. I was advised to try C, not because it is a good language, but because it’s so hard to use, it helps you focus on the exact problem you need to solve. To this day I always “do one in C; do one in X”. I think Python (substitute any ‘batteries included’ language) can be good for this, too, as there’s no need to Yak shave with them.
Re: Write Libraries, Not Frameworks
#239Earlier quoted context omitted.
I agree in theory, but in practice I've found it very hard to keep Spring (Boot) out of my code. Part of the blame I think falls on Spring's DI container, which is "too good". It makes it easy to pull in any bean, even the wrong one, which means developers have to be disciplined managing how beans depend on each other, and you end up with controllers returning entities. Of course, any codebase turns into a mess if yo…
> The core turned out pretty well isolated, but the rest is all Spring. Database access? Spring Data. External interface? Spring MVC. Communication with external services? Spring RestTemplate. I'm not saying it's bad, it's actually awfully convenient, but it's not so easy to swap out External interfaces are just isolated interfaces, which end up being tied to a framework as frameworks do most if not all of the heavy…
> Just because you picked Spring Database to implement your persistence layer it doesn't mean you are bound to Spring to add a webapi or a web app, though.
I agree, you're definitely not bound to, but again, in theory. For what I've observed in practice, factors like convenience and friction in going off the beaten path mean that when you pick Spring your app ends up being 90% Spring stuff. Which is not necessarily bad, there are certainly many good things about using the well supported, robust, and predictable set of Spring components. But I wouldn't say that Spring is the kind of framework that merely helps you tie together your app, that otherwise stays out of the way, and that you can swap out at any time.
Re: Write Libraries, Not Frameworks
#240Earlier quoted context omitted.
The repeated joke about killing your ex-girlfriend did not age well.
I don't think that's ever been funny. What's that, standup comedy for psychos? It's that kind of joke that at best will make you look like a moron and ruin the mood... It's especially sad since the post is otherwise interesting.
> What's that, standup comedy for psychos?
You’ve got it backwards. No “psycho” would consider it funny; they would just consider murder something normal one could conceivably do with a hammer. There is nothing funny about it, to them; it’s just normal.
The murder joke was only funny to those people who consider murder something utterly unthinkable. It is its very outlandishness which creates the humor.
If it is no longer considered funny today, it can mean a few things: Either more people now believe that there are more “psychos” than they thought previously, or an extraordinary number of people have turned into “psychos”. Or possibly both.