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

311–320 of 338 posts

Re: Write Libraries, Not Frameworks

#311

Post by lmm »

jmchuster wrote: post #255
lmm wrote: post #166

Earlier quoted context omitted.

> Well, the whole point of AOP is to handle these "not good examples". I don't have a problem with AOP that doesn't change the functioning of the code. I have a problem with AOP that changes the functioning of the code, which is the overwhelming majority of AOP that I've seen in real life. > Now, certainly if you use the wrong tools for the wrong job, you'll shoot yourself in the foot. But there are many powerful too…

I mean, you can do anything you want, it's just code, but I would argue that I can get more maintainability and better results with less code by using AOP to implement application-wide profiling.

For cases where you need to change the behaviour of the function, you get more maintainability and better results by doing it in a way that's visible in the code. For profiling, you get more maintainability and better results by using something less powerful than full AOP (e.g. stack sampling or tracing). There is certainly no case on the JVM where AOP leaves you better off than not having AOP, and I'd be surprised if there were such a case anywhere else.

Re: Write Libraries, Not Frameworks

#312

Post by lmm »

_ZeD_ wrote: post #142
louiskottmann wrote: post #129

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

Python decorators are a (limited) form of AOP: they let you transform functions in-place to implement cross-cutting concerns. Aspectlib allows you to do a more intrusive form of AOP.

Re: Write Libraries, Not Frameworks

#313

Post by oreally »

edem wrote: post #200
oreally wrote: post #161

Earlier quoted context omitted.

> If you're a seasoned Java developer you look at an `AbstractDestinationResolvingMessageTemplate` and you just know what it does. I'm not kidding. This claim is so bad. You could look at the name AbstractDestinationResolvingMessageTemplate and the useful information they would be gaining is that it's a message template. They would still not know how to use it; they'd still have to do an additional step like checking…

I didn't say that you would know how to use it. You don't need to know, the framework uses it. What I said is that you would know _what_ it is if you ever get an exception from that class. I'm 95% sure that all those people complaining about Spring never read the reference documentation. I did, and whenever I bump into a problem I have an idea about how to solve it. Besides reading it only takes a few days and you're…

What's your definition of 'know'? It's very common to have surface level knowledge of the class only to dive in and see that it does something else. So do you 'know' the code as well as you thought so? Probably not. Fact of the matter is you can't magically 'know' everything about a class based off a class name. And this includes your 'seasoned Java developers'.

You're throwing out some very large assumptions as well.

Re: Write Libraries, Not Frameworks

#314

Post by GuiA »

ngngngng wrote: post #91
wetmore wrote: post #12

Earlier quoted context omitted.

The repeated joke about killing your ex-girlfriend did not age well.

I hope, one day, that we look back on the "woke" over-analysis of the last few years and say "That didn't age well."

Dark humor is just not professional, and many people expect the content they interact with on HN to be professional in tone.

Re: Write Libraries, Not Frameworks

#315

Post by goatlover »

UK-Al05 wrote: post #167
smitty1e wrote: post #60

Earlier quoted context omitted.

I always figured that Java folks were - paid per class - sought to reduce the number of executable lines per class to 1.

Tbh that was Alan Kay's vision of object oriented programming. Lots of tiny objects collaborating via messages.

Was it tiny objects or tiny messages, or both? And I wonder how much of the Smalltalk system was made that way. I think at some point your class needs to handle some complexity that isn't easily broken into smaller classes.

Re: Write Libraries, Not Frameworks

#316

Post by goatlover »

ljm wrote: post #266
ivalm wrote: post #149

Earlier quoted context omitted.

No, real people use EmotionSensorFactoryFactoryFactory. Why limit yourself only to HumorSensorFactory objects?

You really need the MaybeEmotionSensorFactoryFactoryFactory to avoid getting NullPointerExceptions when applying to psychopaths. An AbstractEmotionSensorSensorFactory would be required to unwrap that.

Java really did a number on the respectability of OOP, but at least it's good for learning and laughs.

Re: Write Libraries, Not Frameworks

#317

Post by kevsim »

nift wrote: post #208
kevsim wrote: post #191

Earlier quoted context omitted.

This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.

Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on. I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace. And I know that it won't…

Large queries with lots of nesting is exactly the situation I'm in. Perform a mutation and boom - very slow response from useQuery().

Re: Write Libraries, Not Frameworks

#318

Post by DmitryOlshansky »

atoav wrote: post #156
DmitryOlshansky wrote: post #143

Writing libraries is a never ending grind of: 1. trying hard to do one thing and do it well (and failing usually), but ... 2. there are many dependencies that you should allow your user to pass explicitly ... 3. and that’s the problem - you have 0% control on how the library is integrated but receive full responsibility for how well does it work. Even libc could be very different and will not behave the way you’d exp…

This is why I love writing libraries in Rust: the language provides so many ways of protecting users of your library to shoot themselves into the foot. Combine this with the built in and easy to use testing and I find myself often to break out core functionality of my applications into libraries just because it is a sane way to keep things decoupled. This is far harder in languages without a strict type system: you c…

Also to destroy your point on Rust making it safe for your end users.

Library that doesn’t have stable C API is next to useless outside of its original language/community/etc. and I have been bitten by this a few times already myself (my great libraries in D’s std cannot be easily exported outside of D).

Do not repeat my mistakes - provide stable C API (and ABI by extension) as soon as you can. You cannot make it safe though it’s simply not accounted for in the land of linker “technology”.

Re: Write Libraries, Not Frameworks

#319

Post by kovac »

skohan wrote: post #141

The 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…

How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that.

Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.

Re: Write Libraries, Not Frameworks

#320

Post by simongray »

thom wrote: post #307
simongray wrote: post #246

Earlier quoted context omitted.

Well, let's agree to disagree then.

If you like, but I don’t believe you can possibly have been using Clojure or ClojureScript in anger for very long if you haven’t had this experience.

You're not being rude, but you are being patronising.

Since you've been using Clojure full time for 11 years, don't you think there's chance that you might be biased yourself? I mean, you've basically used it since it was only just released and the library ecosystem is bound to be in flux just after a new language gets any traction.

I BTW never said Clojure was immune to churn. I just said it is comparable to any other language... which it is. You misrepresented my original reply which I find really disingenuous. It might not have been comparable to other languages a decade ago, but it sure is now. And the situation is much better than the most popular language at the moment, JavaScript.

...

I've been using Clojure/ClojureScript as my only language for more than 3 years. Currently on my third Clojure job. Prior to that, I was a heavy user of mainly Python, PHP and Java... all of them in anger (that's such a weird expression, but whatever).

I think your issues must be very tied to the data science domain? I've been following, though not actively using, the data science libraries in Clojure and it's true that the data science ecosystem seems quite immature compared to Python. Incanter was already DOA when I started using Clojure, Cortex came and went, Dragan's libraries are a sort of foundation that hasn't been tapped into yet, and now there's all this Python/R integration going on. Data visualisation seems to have converged heavily on Vega as of late.

But I'm doing web development and parsing. I find that the ecosystem is very stable for that sort of usage. Reagent is the default for frontend, Re-frame the most popular state-management library. There's an ecosystem around these two libraries that many tap into. There are basically only two popular SQL libs available (hug and honey, both using jdbc at their core), so you just pick whichever one fits your use case the best. It sucks that you went through 4 different ones, but I don't think that's very representative. Ring is the standard protocol for most web backends. There seems to be a convergence towards Datomic-style Datalog for newer Clojure databases. Instaparse is the only game in town for parsing using grammars and Clojure spec is widely used (although it's alpha) and can also used for certain forms of parsing.

The only thing I've really been changing has been my tooling, moving from Leiningen/figwheel to Clojure CLI/Shadow-cljs. And I didn't have to do that, it was only done out of an interest to explore these newer tools.

Post reply on HN