Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write Libraries, Not Frameworks

brandons.me

Post reply on HN
Print view View original

131–140 of 338 posts

Re: Write Libraries, Not Frameworks

#131

Post by sgrove »

brabel wrote: post #120
fulafel wrote: post #115

Earlier quoted context omitted.

For those of us hazy on the AOP concept... Is it an artifact stemming from restrictions of static languages, or would it be a valid concept with dynamic languages too?

In the dynamic languages world this is done with monkey patching. If you invent a declarative way to monkey patch your code, you've got AOP as done in Spring.

I believe emacs lisp's advice system is an AOP system in a highly dynamic language, and doesn't make much use of monkey-patching.

Advice/AOP is a pattern that can fit (if you want it) in dynamic language as well.

Re: Write Libraries, Not Frameworks

#132

Post by arendtio »

Most of the time you need one framework (to give a best practice structure to your project) and many additional libraries to add functionality. So it should be obvious that the number of frameworks this world needs is quite a bit lower than the number of libraries.

In addition, you are always free to go with your own implementation and that is true for the structure dictating frameworks as well as for the libraries.

Re: Write Libraries, Not Frameworks

#133

Post by lmm »

quelltext wrote: post #113
lmm wrote: post #104

Earlier quoted context omitted.

Just use a language where it's possible to implement those things in plain old code. When you have higher-kinded types you don't need any bytecode manipulation, you can just have a type that wraps anything that needs to happen in a transaction, and compose together transactional operations in a visible but type-safe way - and you don't even need the runtime cost. How anyone can look at Java as it's actually used and…

You can also do it visibly in Java without too much noise IMO. The point of AspectJ is to hide this stuff completely from application code (but it's still visible in its definitions). Whether that makes sense or not I'm not going to debate (I personally don't think AspectJ is particularly great) but arguing that other languages allow you to do that in a more or less visible way is besides the point. AspectJ is a lang…

> AspectJ is a language, these aspects are visible and have their own language abstractions, just separate from the application code. Just like you have monad implementations separate from their uses. So writing aspects is also "plain code".

Code containing aspects is certainly not plain Java code, because the aspect annotations (or, worse, invisible string-name based pointcuts) change the behaviour of the code they're on, breaking the normal rules of the language. You'll see "impossible" behaviour at runtime: call a method and the call stack jumps to a completely different method. A method throws an exception that's thrown nowhere in its body. If you want to say that AspectJ is a language in its own right, then it's a language that breaks all the rules of good language design: it essentially contains COMEFROM as a core language feature. Whereas monad implementations are (generally) plain old code that follows the normal rules of the language.

> Also, AspectJ isn't Java

It (or other libraries that do much the same thing) is the vast majority of Java as it actually exists in the real world. I've yet to see a substantial Java codebase that wasn't using some form of AOP or reflection (even if only indirectly via these big frameworks).

Re: Write Libraries, Not Frameworks

#134

Post by mrweasel »

ianmcgowan wrote: post #66
wetmore wrote: post #12

Earlier 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?

I still think it’s funny and I’m sure that many people still do, even if they won’t admit it.

You don’t have to be a bad person to have a dark sense of humor and you don’t have hate women to find the joke in the hammer factory story funny.

Re: Write Libraries, Not Frameworks

#135

Post by fulafel »

sgrove wrote: post #131
brabel wrote: post #120

Earlier quoted context omitted.

In the dynamic languages world this is done with monkey patching. If you invent a declarative way to monkey patch your code, you've got AOP as done in Spring.

I believe emacs lisp's advice system is an AOP system in a highly dynamic language, and doesn't make much use of monkey-patching. Advice/AOP is a pattern that can fit (if you want it) in dynamic language as well.

What about this Clojure library?

https://github.com/technomancy/robert-hooke

Re: Write Libraries, Not Frameworks

#136

Post by euoia »

thomk wrote: post #44
phkahler wrote: post #15

Earlier quoted context omitted.

That was good. I still use the Joel Test to evaluate companies.

Did you ever see his YouTube channel? It has exactly one video and it is awesome: https://www.youtube.com/channel/UC65NUFfqjWn3y02kYYl9nSQ

That’s amazing, thank you. Is Google Sheets still missing the table functionality from Excel? It’s the first time I’ve seen this and it looks great. Normally I’d be forced to create a new “sheet”. On a side note, Joel is using Excel for Mac and I was wondering at what point it would beachball, which it does around 42 minutes.

Re: Write Libraries, Not Frameworks

#137

Post by edem »

userbinator wrote: post #9

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…

Spring is not a good example. If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding.

Spring used to be a bad example yes, but not anymore. They really put the thought and work into fixing its design. Right now I can write an app __completely__ independent of Spring. In fact that's what I'm usually doing. You can do Clean Architecture with Spring now. Please keep your facts straight.

Re: Write Libraries, Not Frameworks

#138

Post by skohan »

tanilama wrote: post #49

I think the key difference is that frameworks usually hijack your control flow, while library are not. But is framework necessarily bad or inferior to library? I would like to present React as an example. React heavily regulates the control flow for its developer, leaving several specific hooks to allow you control the timing when your code would trigger. But React is an excellent piece of software. And assuming in a…

I think React is somewhat of a special case, because a lot of what makes React good is that it mitigates a lot of the issues which make web painful to deal with: "the browser" is this highly inconsistent target, and Javascript doesn't have built-in facilities for modularizing code, and React gives you a sensible way to get consisten behavior and implement reusable components in this type of environment.

Another way to put it is that for web you're already pretty heavily invested in the "framework" of HTML/CSS/JS wheather you like it or not. React is essentially just choosing another baseline framework to replace it, not adding a framework where none exists.

Re: Write Libraries, Not Frameworks

#139

Post by blackrock »

Koshkin wrote: post #47
userbinator wrote: post #9

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…

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.

This reads like a circular definition.

Re: Write Libraries, Not Frameworks

#140

Post by BossingAround »

Orou wrote: post #68
hyperpape wrote: post #59

Earlier quoted context omitted.

Any kind of app where you might reach for a framework. The point is to have a reasonable contrast between "here's how you do it with a framework, here's how you do it without one". I think size is important, as I can imagine that the benefits of a framework might show when there's more to do. Personally I'd think of a web app, since this is one place the discussion comes up a lot, but I don't know that's a requiremen…

I'd love to see this as well. Web apps seem really tricky when it comes to not using frameworks though. You can use JQuery - it's tried and true - but it also seems to be on the way out. Great if you know it, but is it worth learning if you don't? I had the unfortunate experience of building a static site using Nuxt recently which included Jupyter Notebook exports as html files. I ran into so many problems that the c…

> Great if you know it, but is it worth learning if you don't?

The main thing with a lot of these small web libraries (I'd consider JQuery a library) is that they are incredibly easy to learn. You can be productive with JQuery within an afternoon. You can be productive with React within a weekend or two. These are not Java frameworks with Hibernate, XML configuration, database drivers, migration paths, etc etc. You pick one up, do what you need to do, and forget it within a week if you so desire.

That said, if you use JQuery in 2020, with a new project, the vast majority of frontend devs I know would consider that a serious code smell (as in, you don't know JS and that's the reason you have to result to JQuery). Check [1] for some info about vanilla JS.

[1] http://youmightnotneedjquery.com/

Post reply on HN