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

321–330 of 338 posts

Re: Write Libraries, Not Frameworks

#321

Post by Townley »

dkarl wrote: post #260
HarHarVeryFunny wrote: post #223

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

The devil is sometimes in the large as well. Form changes — code that used to run while generating a web page now runs in a REST service. Code that used to run in a REST service now runs as a FAAS. Code that used to run in a FAAS now runs in a stream processor. Your framework could tie you to a specific form, forcing you to implement your FAAS by posting each request to a REST service, or forcing you to implement you…

True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with)

That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases, and the migration path is about as painless a major architectural overhaul can be.

Re: Write Libraries, Not Frameworks

#322

Post by thom »

simongray wrote: post #320
thom wrote: post #307

Earlier quoted context omitted.

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

We’ve also made the same migration, working with cljsjs and lein-npm was horrible previously and Shadow is indeed nicer. We also use re-frame, and I have no real complaints with it, beyond Om having had a superior GraphQL like approach to querying but we managed to swerve that bullet because Om never looked finished or really intuitive. Many others did commit to it though.

Are you on the now largely deprecated clojure.java.jdbc or next.jdbc? Fun to rewrite all those serialisers to and from complex Postgres types. Also Instaparse is nice but dog slow compared to clj-antlr and I’ve had to write projects with both. There is no end to my safari park of pet peeves.

Anyway, I love Clojure and you’re obviously allowed to be happy with your tools. I wish you a long and productive career without grumpy folks like me sniping. But please don’t tell me my experience of this ecosystem is wrong or an outlier, because it’s really not. It is a core part of a culture based on granting power and flexibility to the smartest programmers. That comes at the cost of stability and productivity for other classes of programmer. You can’t optimise for everything.

Re: Write Libraries, Not Frameworks

#323

Post by simongray »

thom wrote: post #322
simongray wrote: post #320

Earlier quoted context omitted.

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

We’ve also made the same migration, working with cljsjs and lein-npm was horrible previously and Shadow is indeed nicer. We also use re-frame, and I have no real complaints with it, beyond Om having had a superior GraphQL like approach to querying but we managed to swerve that bullet because Om never looked finished or really intuitive. Many others did commit to it though. Are you on the now largely deprecated clojur…

I didn't say your experience was an outlier, just that you're surely a bit biased towards a certain point of view having taken up Clojure right after it was birthed. But yes, your experience is bound to be an outlier compared to people starting to use it in much a more mature state, which will be nearly everyone in the long run.

As for jdbc, I don't use it currently, but did at my old job (along with honey sql). If you think you have to rewrite some DB access code just because there's a newer library out, maybe the real problem is not Clojure, but your mindset. Perhaps something to think about.

Re: Write Libraries, Not Frameworks

#324

Post by dkarl »

Townley wrote: post #321
dkarl wrote: post #260

Earlier quoted context omitted.

The devil is sometimes in the large as well. Form changes — code that used to run while generating a web page now runs in a REST service. Code that used to run in a REST service now runs as a FAAS. Code that used to run in a FAAS now runs in a stream processor. Your framework could tie you to a specific form, forcing you to implement your FAAS by posting each request to a REST service, or forcing you to implement you…

True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with) That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choic…

It shouldn't need to be rewritten. The same Python code can be utilized in all of those different forms, unless you've tied yourself to a framework for functionality that needs to be used in the new context, i.e., for functionality that is not form-specific.

If you've fallen into the trap of thinking a specific form is eternal -- for example, if you've subconsciously identified "our back end == our REST services" and therefore "data serialization/deserialization, metrics, and data storage access should and will be done only in the REST services" then you might have relied on a REST service framework for that functionality. Then when you want to move functionality to an AWS Lambda or a Spark streaming job, you find yourself forced to choose between running a REST framework inside the Lambda or Spark streaming job (which will be hacky, if it works at all, since frameworks want to own the application lifecycle and be configured via specific mechanisms) or writing and maintaining a duplicate implementation of all your data serialization/deserialization code, metrics configs, S3 configs, etc.

I don't mean to say it's a disaster if you end up doing that, but it's a cost that will tend to hold you back from doing the right thing and make you persist with hacks and band-aids longer than you would have if you were free to change.

> good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases

That's a very modest change. It's still a long-lived service doing request/response over HTTP.

Re: Write Libraries, Not Frameworks

#325

Post by tomtomtom1 »

gombosg wrote: post #226
arethuza wrote: post #201

Earlier 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 genuinely hate the software architect title. It's like when we were in school and the teacher told us to write an outline before writing. No problem ! the majority wrote the text first and then the outline.

That's because people in general write to think.* The level of deep thought achieved through writing is harder to achieve beforehand.

In the same sense, the level of deep thought achieved through writing code, is hard to achieve beforehand. It's actually worse because your engineers, dangled in this web of classes, won't be able to think about the big picture for themselves.

An Architect thinks in terms of what sounds good, what is beautiful in OOP-land not in terms of what is easy to write, and what's performant to implement.

One poignant example is the interviewer who wants you to implement chess pieces as classes. which sounds good in the architects' world but is blatantly insane if you think about the actual code and the actual challenges you're facing.

* writing to think and writing to be read are conflicting goals that why editors exist.

Re: Write Libraries, Not Frameworks

#326

Post by thom »

simongray wrote: post #323
thom wrote: post #322

Earlier quoted context omitted.

We’ve also made the same migration, working with cljsjs and lein-npm was horrible previously and Shadow is indeed nicer. We also use re-frame, and I have no real complaints with it, beyond Om having had a superior GraphQL like approach to querying but we managed to swerve that bullet because Om never looked finished or really intuitive. Many others did commit to it though. Are you on the now largely deprecated clojur…

I didn't say your experience was an outlier, just that you're surely a bit biased towards a certain point of view having taken up Clojure right after it was birthed. But yes, your experience is bound to be an outlier compared to people starting to use it in much a more mature state, which will be nearly everyone in the long run. As for jdbc, I don't use it currently, but did at my old job (along with honey sql). If y…

The old library has always been painfully slow on large datasets, and is no longer actively maintained so that isn't getting fixed. And because Clojure people expect you to compose libraries not use frameworks, these sorts of upgrades are never transparent. Thus, a whole new library, the Clojure way.

And again, this is every year I've used Clojure (e.g. the Shadow migration you yourself went through on what I can only assume was one tiny web app). I'll happily stop patronising your 3 years experience if you stop gaslighting mine. You'll be telling people you never get type errors and you find Clojure's stacktraces really readable next, all the greatest hits. :)

Re: Write Libraries, Not Frameworks

#327

Post by therealdrag0 »

delusional wrote: post #232
nickbauman wrote: post #209

Earlier quoted context omitted.

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.

If they were JUST functions they could be static utils and wouldn't need to be beens. But these service classes themselves have their own fields/dependencies.

The Service class holds an instance of the Caching class and the Database class, each of those hold an instance of clients with connections, for example.

Can you explain how language support would remove this pattern?

I'm currently working on Scala services, and we don't have any DI, which is actually kinda nice, but it just means we "new-up" all these classes manually in our Main class and pass them through as arguments one to the next.

So far I like how there is no "spring magic"; however, in the end the pattern of dependencies is the same.

Re: Write Libraries, Not Frameworks

#328

Post by therealdrag0 »

lmm wrote: post #104
chii wrote: post #94

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…

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…

> Java .. Scala

To be fair, there's something to be said about a seasoned/documented library versus the cooked up micro-framework/function that a random coworker invented in Scala to do the same thing, and which might be implemented differently in each project in your company!

Source: I'm about a year into Scala after many years of Java. I like a lot about Scala, but 4/5 places where we have "plain old code" where in Java we'd have used an open source library, the "plain old code" is painful to read/reason about.

Re: Write Libraries, Not Frameworks

#329

Post by therealdrag0 »

zerkten wrote: post #57
Koshkin wrote: post #47

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

The people that use Spring love it, well, at least they did when I was last working with them. They also loved talking about patterns, often didn't have enough traffic to stress the systems built on these relatively heavy object hierarchies, and were relatively comfortable (the only competition was the other half of the company using .NET.)

lol. In my experience, in the enterprise world, yes people liked Java/spring, but also where comfortable giving it a ribbing. Everyone loved python but didn't get to use it for main-business code, and the Go and Scala projects have been very conflicted with both lovers and haters. In my ~20 person division, 1 person quit and another transferred with the main reason being their dislike of Scala!

Re: Write Libraries, Not Frameworks

#330

Post by willio58 »

andybak wrote: post #213

The one thing I do value from frameworks - especially in an unfamiliar domain - is that they teach me how to structure things. I can usually patch functionality together from various sources but understanding how to break a process down if you haven't done it before is often very challenging. For example - Django taught me how to structure server-side code that needed to handle input from both a database and a browse…

Recently I’ve discovered the world of Django (late to the party I know). It’s so nice to work with a well-developed web framework for once.
Post reply on HN