Earlier quoted context omitted.
What's wrong with it?
It's no longer vogue to joke about murdering women
Write Libraries, Not Frameworks
101–110 of 338 posts
Re: Write Libraries, Not Frameworks
#102Earlier quoted context omitted.
Have you tried React? It feels fairly library-esque to me. You can be useful in as little as two lines of code: const elem = React.createElement('div', null, 'Hello World'); ReactDOM.render(elem, document.querySelector('body')); It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't p…
> Have you tried React? It feels fairly library-esque to me. Because it is, in fact, just a library.
Re: Write Libraries, Not Frameworks
#103Earlier quoted context omitted.
But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)
I will be honest and tell them it is because these are more productive and I enjoy being productive
Re: Write Libraries, Not Frameworks
#104Earlier quoted context omitted.
getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined ClassFileTransformers. Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.
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…
How anyone can look at Java as it's actually used and say Scala is too complex is beyond me.
Re: Write Libraries, Not Frameworks
#105Earlier quoted context omitted.
Could you point out which reactjs code has completely changed? I believe reactjs has remained the same, there are deprecations, hooks etc but basic premise is same.
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.
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 having dependencies for useEffect and other hooks.
Re: Write Libraries, Not Frameworks
#106Earlier quoted context omitted.
getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined ClassFileTransformers. Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.
Stuff like that always makes me feel like someone has turned off their logical reasoning and they are just basically creating code that fills in some personal mental gap that somehow 'completes the set' of the things they are working on at the moment.
It's the unruly mind coming up with generalised words.
Re: Write Libraries, Not Frameworks
#107Re: Write Libraries, Not Frameworks
#108A 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…
getInstrumentableClassLoader() Return a ClassLoader that supports instrumentation through AspectJ-style load-time weaving based on user-defined ClassFileTransformers. Oh man... I admire the people who have invented this. But at the same time I feel sorry for those who have to use this in order to earn their living.
Re: Write Libraries, Not Frameworks
#109Earlier quoted context omitted.
The repeated joke about killing your ex-girlfriend did not age well.
I think the same thing every time reading this otherwise-excellent post. I don't think we should attempt to erase history, but it is super jarring, at least for me. Was it ever actually funny?
But I recently saw "Dont Fck With Cats" on Netflix and if had been a joke about animals I'd also been jared (because in my mind it would no longer be absurd).
So I guess it depends on what media makes us fearful off right now.
Re: Write Libraries, Not Frameworks
#110A 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…
The repeated joke about killing your ex-girlfriend did not age well.
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.