181–190 of 338 posts
Later on, BOM came into existence.
Then everything was packaged in extendible autoConfiguration and Boot came along.
A framework, usually, must predict ahead of time every kind of thing a user of it might need to do within its walls. The one thing not mentioned in the article is that the above line of thinking is almost guaranteed to lead to an insane level of abstraction, which was parodied in this classic article from nearly 15 years ago: http://web.archive.org/web/20141018110445/http://discuss.joe... (Sadly, that site is gone, b…
Anyone know what I mean?
You could make a library that standardizes a library format and take care of that boilerplate, then you can focus on what makes your project different, but that's not very different from a framework is it ?
I feel that it depends on what needs to be done.
For the most part, I prefer writing fairly atomic libraries. I like to use a “LEGO Block” approach, and [relatively] small, focused, modules are ideal for this.
I like each module to have an independent project identity and lifecycle. Makes for much higher quality and usefulness.
Sometimes, though, I need a really fundamental infrastructure. In that scenario, a framework is the best approach. In a lot of cases, we may have considerable control over the implementation of the framework, so that resolves a number of the downsides (like prediction of how it will be employed).
I’ve written a number of frameworks. It’s a huge PItA, and I avoid it, if at all possible. It is my experience that the biggest pain point is quality. I find that proper testing of a large infrastructure is damn near impossible.
If anyone has ever looked at my library (and framework) projects, they will see that my testing code (often harness, as opposed to unit - https://medium.com/chrismarshallny/testing-harness-vs-unit-4...) tends to dwarf the actual CoT.
I consider writing a framework to be the “nuclear option,” to be only employed when nothing else will do. Even then, my frameworks tend to be layered affairs, with coupling between layers as loose as possible.
Writing any reusable software module is like having a child. I can’t just walk away from it when I get bored.
A framework is a huge responsibility. Once it is written and out there, I need to take care of it, in all its contexts, and for all its life. It is a lot easier to deprecate a small module, than a large infrastructure.
The same goes for libraries, but the scope of a library is a great deal more manageable and flexible than a framework. I find flexibility to be a crucial aspect of long-term software (I have written software that has lasted decades).
When I design software, I am constantly looking to the future. It’s become force of habit, and, as Niels Bohr once said: ”Prediction is very difficult, especially about the future.” The less control I exert on the future, the better.
If I can accomplish the same job as a framework with a set of independent modules, even if it is more work to do the modules, that’s what I do. A framework is a big, fat atomic blob that tends to age badly (in my experience).
However, I am obsessed with quality; which is not always an acceptable posture in today’s fast-paced, competitive workplace.
Engineering, at its most fundamental level, is always about finding the most practical approach.
Earlier quoted context omitted.
Yep. React went from React.createClass -> class xxx extends Component -> Hooks. But I don't think that means...change? The fundamental concept of react, that UI is a derivative from the state, stays the same. Class based or Hook (or just a really nice way to write Functional Component), stays the same.
Fc and hooks force you to think in an entirely different manner though. I would say it is an entirely different paradigm. And it is a much higher learning curve. For instance I see a lot of developers and engineers with 6 months and more experience with functional components and still misunderstanding the point of all of this. And these are smart people at high tier companies. The main thing being the meaning of havi…
This is 100% a result of how react (ab)uses the host language semantics to implement their DSL to describe components and has nothing to do with the conceptual nature of functional components themselves.
It relatively easy to imagine a design that doesn’t require the dependency lists when capturing a callback closing over props or state.
Not saying that design would be better or worse, just that it could exist and still leverage concepts like FCs, hooks, effects etc.
Earlier quoted context omitted.
It is very close to python's @ syntax on top of methods definitions. Like: @get('/posts') mymethod ...
? no, it's not. look at https://python-aspectlib.readthedocs.io/en/latest/ for an example of using aspect with python
Earlier quoted context omitted.
> It allows you to remove the concern of logging from your classes completely. You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function…
Modern OSes don’t log to simple text files you can grep, tail, watch, open in a text editor, etc.
Earlier quoted context omitted.
> It allows you to remove the concern of logging from your classes completely. You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function…
Modern OSes don’t log to simple text files you can grep, tail, watch, open in a text editor, etc.
Earlier quoted context omitted.
It does have it's place. Aspect oriented programming will allow you to write, for example, logging code that are very configurable. It allows you to remove the concern of logging from your classes completely. In fact, any cross-cutting concerns - like transactions, can be done this way. So you can write code that don't care about transactions, but behind the scenes, it is all within a single transaction, and transact…
> It allows you to remove the concern of logging from your classes completely. You say that like it's a good thing. When there's a bug to look into grepping strings from the log is one of the first steps, the first step if you don't have a stack trace, I want that string to be where the problem is. Having the logging in with the rest of the code is an inevitability anyway and unless you only want logging at function…
The Java people are describing here is alien to me, and I code Java for a living at the moment.