Sickeningly Sweet - <AUTHOR> https://news.weill.cornell.edu/news/2019/03/sickeningly-sweet <comment><USER2> > _"I have a very simple rule," he says. "I eat fruit, but I don't eat > anything that has sugar added to it._

I'm curious to know how people actually draw lines around sugar intake. Presumably fruit juice is not allowed? What about foods that have fruit juice as an ingredient? Do you decide based on what the ingredients are, or how much of the ingredient there is? Seems like there's a number of reasonable ways to make rules, but it isn't immediately apparent which one is most principled, or easiest to stick to.

EDIT: Any explanation on the downvotes? I'd love to know how folks draw lines around eating sugary foods. If you've got it all figured out, please share your secrets!

<comment><USER3> We are sugar free in our house w/3 kids and draw the line at fruit juice. Not allowed in our house. We will blend our own smoothies that have some bananas and berries but also include greens.

It is very hard to avoid sugar completely. It's in everything especially anything marketed toward kids.

<comment><USER4> The issue is not juice in and of itself, but the amount. A small glass a day is a good way to get some of the benefits from fruit.

We're not sugar free, but sweets are for occasional eating, not for week days. We watch a Disney show every Friday, and my children get to make a small bag of candy (100g) for that. They rarely eat it all. Beyond that we simply load them with greens, and make sure there is always some green that they like and some they have to taste. Hungry when they get home from school? Grab a carrot. Hunger 1 hour before dinner? Take an apple. Need an late lunch snack? Eat some nuts. The battle is won if parents give their children healthy eating habits in their daily life.

</comment></comment></comment><comment><USER5> Sugar really is an addiction and it's very hard to escape it due to its vicious cycle. You may stop eating for a while but as soon as you think "just this once" it's very hard to stop again. Or maybe it's just me and my lack of will power but I did quit tobacco. I think tobacco not being sold and advertised everywhere I go probably helped.

<comment><USER6> I haven't totally given up sugar but I eat foods with less sugar now and whenever I try something with a high sugar level again its really disgusting.

</comment></comment><comment><USER7> After the Brian Wansink thing, I have a natural skepticism of nutrition science coming out of Cornell, especially with a hypeworthy subject, glossy photos and a PR campaign.

<comment><USER8> I am more wary of any nutrition study though .. A lot of these scientists aim for newspaper coverage than actual honest research or science. Most of these are touchy-feely social science stuff that shouldn't be in the category of science to begin with.

</comment></comment><comment><USER9> I'm not quite sure if this is talking about the same research but it seems relevant:

"Important note: there's a lot of craziness out there around "keto" diets, and this does not mean that a ketogenic diet prevents cancer or is a treatment for it. No, what it means is that if you're a cancer patient taking a PI3K inhibitor, a ketogenic diet could help the drug to work, and that's it. In fact, in at least one rodent model (AML), putting the animals on the diet actually accelerated the cancer before the PI3K inhibitor treatment began, so be aware."

[http://blogs.sciencemag.org/pipeline/archives/2018/11/16/pi3...](http://blogs.sciencemag.org/pipeline/archives/2018/11/16/pi3k-inhibitors- youre-doing-it-wrong)

</comment><comment><USER10> Is this the thread where we humblebrag about how we find desserts (sometimes even bread) too sweet?

</comment><comment><USER11> I think everyone agrees sugar is bad, but I'm pretty sure it's only part of the picture.

The amount of sugar (and other sweeteners) we eat has actually gone down in the last 20 years, but we haven't seen a drop in obesity or other metabolic diseases at all.

My gut feeling is vegetable oils are another part of the problem. Unlike sugar, we keep eating more and more of them. And unlike sugar, we only started eating them around 100 years ago.

There are a few nutrition people talking about vegetable oils but it doesn't have the same mass consciousness as sugar. Maybe because there are still old school nutritionists telling us we should avoid saturated fats.

<comment><USER12> In Serbia, at least the northern part, a lot of people (used to) cook on pig's (or mangulitsa's) fat instead of vegetable oil. We rarely used any oil aside from pumpkin seed oil and olive oil for salads. Unsure what's the popular opinion on that, but it's a worthy replacement.

<comment> black-tea I only use lard and butter for cooking and have done for years. I hope people keep using vegetable oil, though, because it makes lard really cheap.

</comment></comment></comment><comment><USER13> Am I reading this wrong or has the study not actually started yet?

</comment><comment><USER14> If you get sugar lows easily, as I do, you learn to hate sugar. I try hard to avoid sugar.

</comment><comment><USER15> I can give up sugar, but I can't give up chocolate, and chocolate without sugar is inedible.

I did get some 70% chocolate though, just enough sugar to be edible, but not sweet exactly.

<comment><USER14> I eat 100% chocolate _only_. I can't stand the sugar even in 87% chocolate -- I find that inedible.

Not all 100% chocolate is great, but some brands are excellent.

<comment><AUTHOR> What's your favorite 100%?

<comment><USER14> Callebaut. I buy 5lb bags of 100% chips.

</comment></comment></comment></comment><comment><USER16> Sad but true. All those Reese's Peanut Butter eggs that are now being sold are deadly.

If you have some, send them to me. I'll dispose of them.

</comment><comment><USER17> I'm on a lazy keto and never been one to crave sweets so it wasn't that difficult for me to give it up completely. Occasionally if I'm having a rare drink I'll make a margarita with truvia and can't really taste any difference between it and real sugar.</comment>


Write Libraries, Not Frameworks - <AUTHOR> https://www.brandonsmith.ninja/blog/libraries-not-frameworks <comment><USER3> _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...](http://web.archive.org/web/20141018110445/http://discuss.joelonsoftware.com/?joel.3.219431.12)

(Sadly, that site is gone, but the memories live on...)

Addendum: to see this in practice, one needs to look no farther than Spring, the famous Java framework:

[https://docs.spring.io/spring- framework/docs/current/javadoc...](https://docs.spring.io/spring- framework/docs/current/javadoc-api/)

[https://docs.spring.io/spring- framework/docs/current/javadoc...](https://docs.spring.io/spring- framework/docs/current/javadoc- api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

[https://docs.spring.io/spring- framework/docs/current/javadoc...](https://docs.spring.io/spring- framework/docs/current/javadoc- api/org/springframework/web/servlet/support/AbstractAnnotationConfigDispatcherServletInitializer.html)

<comment><USER4> The repeated joke about killing your ex-girlfriend did not age well.

<comment><USER5> 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."

<comment><USER6> This too shall pass.

<comment><USER5> I don't have as much faith as you. I believe being "woke" is one of many things filling a void left behind by religion as more and more people find that void needing to be filled. I can't see that changing anytime soon.

</comment></comment></comment></comment></comment><comment><USER7> I was expecting a one-sided rant. Instead, I got a reasoned distinction between two different approaches, the trade-offs of each, and a discussion about the cases where one approach (frameworks) can be beneficial but also identifying the added risks of going that route. I agree with the conclusion, and why.

I wish even more people were willing to write down a discussion of alternatives and their trade-offs. Instead of "Google does it this way, so it's obviously the way everyone should do it"... a reasoned discussion of the pros and cons. Good to see.

<comment><USER8> Yeah, I was expecting something a lot less nuanced after that warning at the beginning. I both love using full-featured frameworks (I reach for Django over Flask) and totally agree with the article.

This was the blog equivalent of someone sincerely saying "Pardon my language, but gosh darn it that man is a jerk!"

<comment><USER9> Flask always looks better at the start but Django always gets me further, faster, safer (protecting me of my mistakes).

I've spent the past 4 months learning rails and it makes me realize how much I didn't appreciate about Django and its magic compared to rails magic.

</comment></comment></comment><comment><USER10> 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 functions, and it's my job to figure out how to spread them out over the hardware.

<comment><USER11> 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.

<comment><USER12> 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 be as fast as regular old json due to the checking but that slow? Must be something someone can do :)

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

</comment></comment></comment></comment><comment><USER13> 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 browser and potentially an API in a way that keeps things nicely layered.

I'd done all this before with PHP but my architecture was a dogs dinner. I could structure my own code nicely now - but only because of the experience I gained from using an opinionated framework.

<comment><USER14> 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.

</comment></comment><comment><USER15> 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 perfect world, if everything we interact are more or less functional or self-containing, then timing doesn't really matter, and uncertainty is thus controlled.

In the end, the lesson here seems to me is, making good frameworks are much harder than making good libraries. For libraries, you need to make sure the building blocks are solid, but for frameworks you are defining a whole world for people to visit.

<comment><USER16> I would argue React is actually a great example why the article title is on point.

Idiomatic React has completely changed several times over the course of a few years. This shows that it did not anticipate people's needs well enough. And React is in the fairly enviable position of receiving corporate backing in the tune of a million dollars per year.

Now consider tools like Redis or Postgresql. You can interface with them from just about any language and you can go years without your usage of them ever becoming unidiomatic.

<comment><USER17> This thread is peculiar.

Framework <-> library is a spectrum, of course, but as an obvious indicator of React's location on that spectrum—you can feasibly use it inside, say, an Angular app to render a particular third-party widget. At its core, React is a super-efficient unopinionated render() and tools for constructing its input. On its landing page it establishes right away (IMO, correctly) that it's a library.

The reverse, bringing a single Angular component into an otherwise React-based webapp, is basically an oxymoron. Angular will generate e2e test scaffolding for your entire project, prescribe where to query data, expect you to follow a particular file layout in your codebase, and pull in enough machinery to rule out any auxiliary uses.

<comment><USER16> Just because you can do something doesn't mean that it makes sense to, or that it's idiomatic to do it. The use case of bringing in a single 3rd party React component into an Angular app is far into edge case territory. Realistically, you would never consider doing it unless there was absolutely no Angular-only alternative in any way, shape or form.

FWIW, it _is_ also possible to render Angular code inside of React [1] (but again, this falls well into non-idiomatic territory for both Angular and React)

Idiomatically, React is the only thing dealing w/ DOM in an app, and the way it's used is rather frameworky ("don't call us, we'll call you"). And when it's used that way - which is the vast majority of the time - the used idioms do vary heavily depending on when the code was written.

Tying this back to what I mentioned about postgres: _within_ a React codebase, you need to be aware of the _semantics_ of the system: performance is achieved through reasoning about the semantics of things like shouldComponentUpdate/memo and even object identity, one needs to understand the semantics of stale closures and useCallback, etc. This is similar to having to understand the semantics of how various ORM idioms translate to underlying SQL queries. By comparison, the cost of any given jQuery idiom tends to correlate more directly with the underlying semantics, just as the cost of a raw SQL query does - i.e. it's pretty obvious without context how expensive `$('html').html(html)` is, just as it's more obvious what is the performance profile of a CTE vs a subquery, in comparison to whatever the high-level ORM idiom is (assuming, of course, that you know SQL)

[1] [https://medium.com/@balramchavan/integrate-import- angular-v6...](https://medium.com/@balramchavan/integrate-import- angular-v6-component-s-inside-react-js-applications-da5cc03107b4)

<comment><USER18> The same holds true for Postgres: idiomatically, it's _the_ data store and thus comes with its own set of instructions. I'm not really sure what you're arguing here. Redis gets even worse: here are a few datasets we support, now go architect your use cases around them.

Of course, none of these reasons make them bad tools. Quote the contrary. We are about to ship a react + postgres + redis product. They all work great together for the very fact that like good libraries, we can borrow from each where they are needed.

Just because idiomatically React is the only thing interacting with the DOM isn't an indictment...it just means React is really good at that and most people would rather use it exclusively for DOM manipulation. The same way that Postgres is often the only data store, not because it forces it upon you, but because it's really really good at it.

</comment></comment></comment></comment></comment><comment><USER19> The best distinction I've read is:

When something is a library, your code calls functions on it.

When something is a framework, it calls functions on your code

<comment><USER20> it's a rough rule of thumb at best though – higher-order-functions or other things that take a callback blur the line a lot (IoC, what a sibling comment said). or say a library has an event-loop, or maybe does networking and you only provide some handlers – would that make it a framework?

i guess it's about frameworks being "the main thing happening". i.e. a framework controls the whole program's execution, occasionally yielding control to your code. which is a bit wordier to be sure :)

<comment><USER21> The article also makes a good point that there is no hard line between library and framework, it is spectrum.

</comment></comment></comment><comment><USER22> 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 constraining rather than liberating, but per the sculptural analogy the roughed-out shape provided by the framework liberates you to concentrate on the details rather than suffer from analysis- paralysis when there is too much freedom of approach (just a large block of marble from which you might sculpt literally anything).

But it depends on the scope and nature of what you are trying to do ...

If your problem fits withing the scope/form of the framework, and your value- add is in the details, then using a framework, all else considered, make sense.

Alternatively, when you are trying to do something outside of the norms of gentrified frameworks, then the flexibility of libraries (or ultimately a blank sheet of paper) is what is called for.

Of course, the devil is in the details... a poorly designed framework may be TOO constraining and not provide enough flexibility to be widely applicable, while poorly designed libraries may be overly restrictive due to poorly designed APIs that don't place nice with other libraries or the data structures you'd like to use.

<comment><USER23> 1 more plus for the form of frameworks. People on your team must be on the same page and work within that form. If everyone is left to their own devices you will get a lot of friction when going into parts of the code you did not create yourself.

I like to think of frameworks like a kitchen. The chef sets the menu and everyone works to produce how the chef thought it should be.

Sure sometimes you will run into things that you fight the framework, but a good framework normally allows a "raw" way of doing it "by hand" instead of the sugary framework way that "just works (most of the time)". But most of the time it does work out fine and you can hop between other's proejcts/parts of the code and have instant familiarity and intent

</comment></comment><comment><USER24> > Do you introduce a domain-specific language? You're now responsible for part > of the build chain, and for editor integration.

> Now, if there's a major organization backing the framework, maybe the > calculus works out. Google can back Angular...

In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angular and it still has no tool for performing codeshifts. The editor integration to date still leaves much to be desired.

With the number of years and man-hours dedicated to this point, I'd imagine these thing would've happened by now, or they may not happen at all. Lately, Angular's push has to been to 'make it faster', which helps with developer productivity, but not much movement on the developer experience (better editor integration) part.

Agree with the thesis, but it's still understated how expensive creating your own DSL is.

<comment><USER25> I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]

It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.

[0] [https://github.com/arijs/ari](https://github.com/arijs/ari)

<comment><AUTHOR> You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

<comment><USER26> For years I used react without jsx - with a few minor conventions to make it shorter to write elements via JS (`_div(...)` being equivalent to the jsx `<div>{...}</div>`, and some minor variant for elems with attrs) it's quite easy to build trees using plain old JS syntax.

The advantages of doing that were better tooling support, since everything under the sun supported JS, but not necessarily JSX very well, and jsx isn't really all that important anyhow. Obviously that's not a factor anymore today ;-).

<comment><AUTHOR> Yep! Really the non-JSX syntax is very close to that of _most_ virtual DOM- based rendering libraries, including the fairly popular Mithril.js

</comment></comment></comment></comment></comment><comment><USER27> The corollary to this is:

        *Use* libraries, not frameworks

Similar to the case of writing, this isn't absolute. But when you decide to use a framework in your project, you are accepting a set of limitations and should do it with your eyes open.

Unfortunately, framework authors make this difficult. It's understandable but frameworks spend a lot of effort promoting their "pros" to developers and none on clarifying their "cons" (well, typically).

When you adopt a third-party framework for a project, you want to do an analysis of the longer-term implications of the limitations the framework. Sometimes that analysis is easy. E.g., if I am making an "event" app -- like an app for "XYZ's 2021 Comedy Tour" \-- there isn't a long term (though there, it makes sense to take it further and see if there's an even more restrictive "template" app that will still nicely meet requirements).

But if you are hoping to extend and build-out your app/project/solution over time, especially if you don't know details of how, up-front, it's tough to accept the limitations of a framework.

</comment><comment><USER28> > A framework, usually, must predict ahead of time every kind of thing a user > of it might need to do within its walls.

Well, when I'm building something opinionated like something resembling a framework, I usually aim for something that handles 80% of the use-cases, and then make sure that you can go around the framework for the other 20%.

Your "thing" should always have a way to get out of the way and fall back to the un-abstracted way of doing things. Then you don't have to predict the future.

</comment><comment><USER29> I'm pretty sympathetic to this, as my experience with Spring has been "it's convenient when it works, but awful to deal with when it's not working".

However, I think to push this line of thought, it would help if we had examples of how to build significant applications without a framework. Ideally someone could provide a walkthrough of an app like that. Unfortunately I can't volunteer myself: the last time I built without a framework, it was a mess.

<comment><USER30> If you're trying to build an entire app, you are not building a library. An app uses libraries and frameworks to stitch them together. A library brings functions, and a framework brings connectivity and logical flows. An app without a framework is an app with a hidden framework. An app without libraries is an app with a hidden framework and monolithic, catch-all, single- purpose library.

<comment><USER29> So then turn the question on its head. What are the examples of frameworks that should have been libraries?

It's not that I disagree with you, necessarily. I'm just trying to extract a more specific claim from this post.

</comment></comment></comment><comment><USER31> 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 expect it to.

The big problem of making everything a small well thought-out library is large integration surface + having to be flexible and accommodate for all potential cases of integration.

That's why we mostly have hundreds of overlapping "fat" libraries - too much trouble and too much integration complexity to split them up.

<comment><USER32> 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 can do everything right and your users still abuse it.

<comment><USER31> 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".

</comment></comment></comment><comment><USER33> This was eerie to read. I've made some of the exact same points, word for word to others. It would be fascinating to do a survey/quiz for developers to see who's tempted to write tiny custom frameworks, and who knows better. This rant would also make a good first day read in an enterprise software engineering class.

Thinking over my career, I've seen a lot of libraries and tools out there that are really trying to be tiny frameworks. One example is [ngOptions]([https://docs.angularjs.org/api/ng/directive/ngOptions](https://docs.angularjs.org/api/ng/directive/ngOptions)) from angular 1. As a web developer, you're already using javascript, html and css at the very minimum. Yet ngOptions went ahead and created a new configuration language just for rendering a drop down. It was ok for simple stuff, but it rarely felt right for more complex widgets.

I think java bean mappers kind of fall into this trap as well. On the surface, bean mappers look like libraries. But once you start customizing the mappings, you see that each library has created a complex configuration language. The problem is that configuring custom mappings takes about the same amount of space as creating a tiny method to manage a specific field mapping. The difference is that I have to read a bunch of documentation to understand the bean mapper, but I already know how to write java.

At the end of the day, library vs framework boils down to imperative vs declarative. Libraries and imperative languages are composable and relatively easy to understand but can sometimes require a lot of work to accomplish difficult tasks. Frameworks and declarative languages require a lot of work to get right and are really only appropriate for problems that are well understood or formally described. They take on a tremendous amount of responsibility, but when done well they are incredibly valuable. There's a reason the world runs on SQL.

<comment><AUTHOR> > The difference is that I have to read a bunch of documentation to understand > the bean mapper, but I already know how to write java.

I think this is spot-on, and sums up one of my points in a way that's a bit closer to the heart of the issue. However:

> At the end of the day, library vs framework boils down to imperative vs > declarative.

I don't think this is true at all. There's a correlation, maybe. Particularly in languages like Java that don't have great support for declarative stuff themselves, frameworks like Spring have served as a kind of workaround for that shortcoming. But if anything I would say pure functions lend themselves even more to library-thinking than imperative code does.

</comment></comment><comment><USER34> This has generally been the approach in the Clojure community. Of course, lacking standard frameworks, every library gets abandoned every few years so you have to learn a new even cleverer one. And wherever you might benefit from a group of very cohesive abstractions (e.g. in data science) you're instead left with a bunch of random incompatible things (that again, will be abandoned in due course).

<comment><USER35> What are you talking about? Every Clojure library does not get abandoned. It's just a process of survival of the fittest, like with any language. The popular libraries in Clojure are (mostly) actively maintained like with any other language.

<comment><USER34> It's great that this has been your experience, but I'm on my fourth SQL library at this point. I've been through several HTML rendering libraries, same with authentication, same with config management. The zipper and component libraries I used are abandoned. The data science story is sad compared to the R or Python ecosystems: Incanter dying, clj-ml unmaintained, Fastmath is good for some random stuff but not comprehensive, tech.ml on the rise but still not standard to the point anything actually integrates with it, multiple competing viz libraries, some of which require a browser. Even core stuff like spec hasn't stabilised yet.

I have used Clojure full time for 11 years and it's nonsense to pretend that the ecosystem doesn't have problems that most Ruby, R, Python or .NET developers don't have at all or as often, by virtue of them having strong frontrunning frameworks. I'm not saying they're necessarily more happy or productive than Clojurists, but there is constant churn everywhere in the Clojure ecosystem, and it increases the cognitive load on every project I have ever done in the language.

<comment><USER35> Well, let's agree to disagree then.

<comment><USER34> 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.

<comment><USER35> 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.

<comment><USER34> 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.

<comment><USER35> 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.

<comment><USER34> 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. :)

<comment><USER35> Not sure what you think your many straw men are going to accomplish. Pretty sure almost no one but the two of will be reading this...?

I guess you think your attitude is a mark of superiority, but in reality you sound about as intellectual as Holden Caulfield in The Catcher in the Rye.

<comment><USER34> I'm not trying to sound intellectual, I'm just trying to convince you my experience is real. I posted a very simple response to the article, detailing one direct consequence of a preference for libraries over frameworks. You're the one that jumped in to tell me I was making it up.

You can take personally any criticism of your favourite language and its proponents (I'm still one of them, honest!), or you can approach technology with a degree of scepticism. Really no interest of mine, and it's clear the feeling is mutual. Good luck in your future endeavours (and for what it's worth, I used to work for a Clojure NLP startup so I do genuinely mean that - wouldn't it be nice if there was a nice cohesive framework for NLP tasks in Clojure?)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> This article looking at frameworks as introducing cyclic dependencies of interpretation is illuminating: [https://parametri.city/blog/2018-12-23-language-oriented- sof...](https://parametri.city/blog/2018-12-23-language-oriented-software- engineering/index.html)

> The trouble with frameworks is that to use it, you have to match your > application to the language of the API. If you're not careful, you end up > coupling your system to the framework. This means that you create a cycle > between yourself and the framework by architecting your component as an > interpreter from F_o to F_i.

You can avoid this cyclic dependency by _marginalizing_ the framework at the edges of your application, as suggested in the post, but that strikes me as much easier to do with libraries.

</comment><comment><USER37> _Frameworks ' key trait is that they impose limitations on the programmer_

You could say that a type system also imposes limitations on the programmer. Is a type system a framework? Would you rather use a library than a type system?

I think the point is rather that making a framework is much much harder than making a library. So it makes sense to first create a library to solve a problem if that is feasible. Once you are reasonably comfortable with your choices during creating your library, you might think about turning your solution into a framework. You should do that only if there is an actual benefit in doing so.

I think frameworks live on a higher abstraction level than libraries. If you need that higher level, libraries are a poor fit. If you don't need it, why make your life harder in going there?

</comment><comment><USER38> I rather have the comfort of frameworks, and the occasional edge case than dealing with creating the world from scratch.

This is what gives "hunt for libraries" mentality of Khronos versus the comfort of using MetalKit or DirectXTK.

Happily using frameworks since Turbo Vision.

</comment><comment><USER39> I have noticed 2 kinds of developers: Vanilla vs Frameworks

the later seems a lot more demanded by the market, but the formers are usually producing better/unique applications, and with much better perf compared to a framework based app

2 weeks ago a customer asked me to optimize a slow Angular SPA frontend for a simple CRUD app. It was taking 30 seconds to load nearly 15MB of js for the login screen!

I have simply trashed everything, 250MB of code and dependencies, ALL replaced by 15KB of Vanilla HTML/CSS/JS. The customer just could not believe how fast and efficient the new frontend was! His first question was which magical framework I used ...

<comment><USER40> Did you tell him about the new framework called [http://vanilla- js.com/](http://vanilla-js.com/)? : )

</comment></comment><comment><USER41> This is my core experience with Tensorflow vs Torch for deep learning -- Tensorflow keeps trying to predict how users will want to structure their research code, while Torch just sticks to making really nice building blocks.

</comment><comment><USER42> That's why you can use several libraries at once, but you can only use one framework at a time.

That's also why I refrain myself to use things like unity, unreal engine, godot, etc.

Once you wrote something, a framework prevents you from using another framework, or the cost of porting is way too high. Libraries are more easily interchangeable.

<comment><USER43> You can do so to some extent in PHP. I'll wait for the PHP has rep to slow down....

In PHP, there is Framework Interior Group that created a few standards to which many frameworks implement their components. The interfaces are designed by FIG, and frameworks implement them (or rather, use libraries that implement them).

Containers, HTTP message objects, request handlers, middleware, caches, they all can be interchanged if they implement these interfaces.

Frameworks can now give the choice to the user to pick their own preferred libraries.

There is Laravel, which is on the far end of opinionated frameworks, but Symfony andnSlim for example provided a lot of flexibility.

</comment></comment><comment><USER44> The frameworks that people really like are things like emacs and xmonad. That is to say, the framework is opinionated enough that you are writing configuration not applications but also flexible enough that your configuration can be completely arbitrary.

Many frameworks are too close to being libraries while still being frameworks, so you lose your control for a dubious return (you don't start with working software and tweak it, rather you have to build from scratch inside of someones else's paradigm).

</comment><comment><USER45> Just write whatever you want. I cite the following rule:

Given enough time, the best code will inevitably be perceived as crap. – Ravenstine's Law

<comment><USER46> All code has bugs. - me (and everyone else)

</comment></comment><comment><USER47> This feels like an apples vs oranges comparison. Libraries tend to be more focused and single purpose (e.g., provide an interface for technology X).

When you begin composing libraries together to do a multitude of things you tend to end up with a defacto framework whether you call it that or not.

Frankly, I'd rather use a framework that has been battle tasted and hardened through open source and is well documented instead of one that is incomplete and lacks conventions built in-house.

<comment><USER48> React is a great example of a library that provides enough structure that you typically don't need a framework. I don't think you always need a framework for this reason. And it's definitely battle tested as are all the extras like router etc.

<comment><USER47> Aside from the fact that create-react-app itself is pretty much a framework, even if you don't use that and roll it all yourself you end up with a codebase that has many of the same hallmarks of a framework such as directory conventions, common class patterns, a bootstrapping mechanism, etc. There's plenty of messy React codebases out there that screw this up.

</comment></comment></comment><comment><USER49> Yeah, but nobody gets to have their own conference for a library. Frameworks are a product. Frameworks have cults. Libraries are parts. There's no money in parts.

</comment><comment><USER50> Framework often kill themselves because when there's new innovation or paradigm, it's hard to change. (Angular 1 is example).

So there'll be a rewrite or a complete new framework born. But a library will live forever whatever technology changed or not.

But framework is useful to integrate or test out many libraries into one to build something fast. Think it's like a boilerplate to reuse.

TLDR: Library is the primitive to build upon. Framework is just one use of libraries.

</comment><comment><USER51> Well that just makes me want to know what his week was like / brought him to that point.

Not that I can't imagine, I just want to hear about the train wreck.

<comment><AUTHOR> Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.

<comment><USER51> Totally understandable.

You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).

<comment><USER52> IMO magic is the result of one of three things

1\. Developer does not have enough imagination to create necessary abstractions without resorting to magic.

2\. Developer does not like commonly accepted approach to solving things in that particular language.

3\. The language is objectively not expressive enough and magic is necessary.

IMO everyone thinks that it's 3-rd point, but it usually is #1 or #2.

<comment><AUTHOR> A good example of "magic" that is 100% worthwhile is the MobX library (I may actually write a post on it soon). A few key things that make this the case:

\- It accomplishes something that would be dramatically messier and more error-prone in the host language without the use of magic

\- It introduces a very small number of "magical" concepts, and their behavior WRT the outside world is very intuitive

\- While every abstraction has leaks, the ones in MobX gravitate towards performance rather than correctness. I.e. it virtually always does what you expect, and usually does it efficiently.

\- It provides trap-doors and hooks for dealing with every possible abstraction leak you might run into

</comment></comment></comment></comment></comment><comment><USER53> Same thing from years ago: [http://tomasp.net/blog/2015/library- frameworks/](http://tomasp.net/blog/2015/library-frameworks/)

</comment><comment><USER54> I totally get what would have gone in to come up with this. Often frameworks are released and their versions are bumped up with major changes without thinking about the struggles/emotions developers might face. Speaking from experience, just recently I had to sit together fixing and upgrading my codebase to the latest version of a framework that I was using. More than the development process itself these take more time and the developer frustrates himself going over StackOverflow and reading through comments on GitHub issues to figure the point he is missing out on.

More importantly, I think that framework writers need to think of their developers as their users and make sure everyone is notified about the updates happening and are on the same level. I know it is a lot to ask for given that these projects are open source but a huge gap in the way we leverage open- source products for its use.

</comment><comment><USER55> I think the article leaves a bit of a blind spot where the dreaded "in-house framework" lives. Those are always the worst of frameworks when evaluated like you would evaluate a "proper" framework, but they can make up a lot by being used exclusively by their original authors or at least under their personal supervision (then it all depends on people skills). The biggest drawback is that they can cut you off from a lot of upstream innovation, so maybe don't go that way in client side front-end dev... (but sometimes even that can be good, a properly fossilized pure servlet source tree can be nicer to work with than one that has gone through every hype since struts2)

</comment><comment><USER56> Good article. A while ago I worked a little with Angular and I thought to myself that probably 80% of it could easily be in a reusable library instead of tying it to the framework.

That way you could write a lightweight framework with a powerful library under it.

</comment><comment><USER57> Framework and libraries are both useful. Besides those, languages are also useful.

The problem is there are too many frameworks instead of libraries. People are writing frameworks by default, and frameworks make strong assumptions, making things not flexible, thus frequently burn people.

When tackling a new domain, it's better to write libraries first. Then write frameworks if it can indeed improve things. On top of that, when framework works, there's a chance a language may work better.

In brief, frameworks are overused, while libraries and languages are overlooked.

</comment><comment><USER58> As I see it. A good framework is an extraction of common used patterns and a set of libraries. Sometimes people make the mistake of not dogfooding their frameworks or turning that process around, starting with a framework hoping that it will make life easier. Someone from their ivory tower saying, this his how it should academically work. Like the early .net enterprise block framework or asp.net. The frameworks that are painful to use are usually extracted to soon or not accommodate the 80% for that specific use case

EDIT: Words

</comment><comment><USER59> This is a really bad take imo.

Frameworks exist to prevent you from having to do work that has already been done, to a much greater extent than libraries. Those interfaces between libraries are the part that waste the most time for little reward. For web development in particular, reinventing the wheel will waste a huge amount of time. Looking at them as limiting rather than accelerating is an idealist dev's mistake that ignores the realities of business.

While you're busy gluing those components together, your competitors who used a framework already made it to market. While you're reinventing authentication, they've got their first customers. After launch, while you're figuring out new ways to add features that come with the framework, they are able to focus on scaling and growing their customer base.

Sure, this works out differently if you're one of the big tech companies, with tons of bodies to throw at any problem. But if you're on a small to medium sized team, use a framework. There's a reason so many successful startups and mid-sized teams (and large teams) start and grow with Rails or Django compared to non-framework paradigms - and it's not that there are more people doing it. Node-based non-framework app attempts seem to be far more popular and far less successful on average.

</comment><comment><USER60> I don't recall from where I heard it, but I've heard libraries described as proper tools where you get to take their facilities and (to an extent) use them as you wish, versus frameworks which are an old text adventure game; you have to work within the constraints (and hopefully the frame work is both sane and well documented, otherwise "You are standing in an open field west of a white house, with a boarded front door.")

</comment><comment><USER61> I would like to share my view as of an author of a JS UI framework. It largely depends on the project, but sometimes it can be very difficult to integrate many libraries to play nicely together. To build an admin web application with some data entry, a developer would need a set of standard widgets like inputs and menus, a nice data table implementation, form validation engine, a router and a state management library. For more serious applications charts may also be needed, multi-lingual support and some advanced widgets like maps, html editor, calendar, or diagrams. If each of those is a separate library with separate rules for styling, state management, selection, number and date formatting, context menus, tooltips, the project quickly becomes very very complex. If all things are integrated into a framework you get a sane development experience. There are always some sacrifices and some features may be missing, but frameworks usually cover 80-90% of all requirements. The problem is that requirements change and frameworks usually have hard time to catch up and preserve backward compatibility.

</comment><comment><USER62> It's primarly a matter of taste, but I suppose that if you use only libraries instead of a framework: you will end up copy/pasting the same boilerplate to tie each library from one another over every project.

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 ?

<comment><USER63> I find that this type of duplication is incidental: I happen to need to do the same thing, but if one project has special requirements the other projects don't need to change. Hence the boilerplate is fine and doesn't need to be dragged into a library.

</comment></comment><comment><USER64> This is good advice and of course, because of the nature of computer science and software engineering, it WLOGs its way to many other topics.

For example: I've always enjoyed the tools that come as a pile of small Unix utilities, rather as one single application (GUI or not, but usually GUI.)

BitTornado in the early 2000s. Git of course, where you build your own workflows that work for you using the different command line tools (fetch and rebase, pull and merge, cherry-pick if you want to.)

Much of the Debian helper script suite is designed to be reusable in small components in a makefile, rather than enforcing you do it all their way in one big invocation. And of course the current systemd vs bash-plus-lsb-shell- functions comparison.

I found I couldn't use ZFS without systemd recently, on an Ubuntu install. ZFS shipped with init scripts that only worked with systemd, but systemd meant my console booted blank. I decided to fix the former rather than the latter and it was pretty easy to write my own ZFS init scripts using the LSB init shell functions — a library, not a framework.

</comment><comment><USER65> Whenever I've had tools a platform/infra team provides that feels like I'm working with my hands tied, maybe it makes things withing some predicted boundaries and everything else hard, this seems to be the culprit. I never realized it until I had a teammate redesign an infra tool from a framework into a library, explicitly pointing out this distinction. Now I explicitly think about it as a fuzzy spectrum when I'm writing what's kinda analogous to higher order code, or really anything that feels like "investment" code I want to leverage to help myself down the line. Being aware of the spectrum has let me be intentional about my choices in a way that may be the biggest improvement in my programming since I learned about unit tests.

Recently, pytorch-lightning has been interesting to me because it seems to be relatively close to the boundary between these two ideas.

</comment><comment><USER66> What about the compatibilty issue for Libraries.. Do you think if dependent libraries are not compatible it will create issues? Like back in 1998, half of the developers time went in figuring what version of hibernate works with what version of Spring mvc.

Later on, BOM came into existence.

Then everything was packaged in extendible autoConfiguration and Boot came along.

</comment><comment><USER67> This makes no sense, both have their place and limits are good! Ossification has a purpose!

I often use the metaphor of a tree:

      leaf = library
      stem = framework
      root = platform

Write platforms so you can hot-deploy everything including the database and change the turnaround of the iteration to as close to zero as you can!

In my MMO engine client I have a couple of hundred of milliseconds turnaround from saved source to running in the engine (platform + framework + library) without any reloading of assets.

Same thing on the Server.

Only use OS + language (C+ (only string/stream and classes for structure only) for client and JavaSE for server) and build everything else yourself except if there are libraries built by one person (personally I use JSON and DNS4J for Java and GLEW + SoftAL for C, all of those are at the edges!). Everything else is a recipe for long-term disaster!

</comment><comment><USER68> One other huge downside of frameworks is that they don't (easily) compose with other frameworks and libraries.

</comment><comment><USER69> One way to improve both frameworks and libraries (but is especially needed with frameworks) is if they create 'safety valves' \- places where it's possible for the programmer to just break free of what the framework/library is doing and do their own thing. With this approach, and sufficiently modular architecture, you get ease of use at the highest level, but can drop down to as a low a level as needed to work around limitations (a common example is ORMs just letting you write raw SQL when you want to, but most of the time you can get the benefit of their abstractions).

</comment><comment><USER70> I have to admit that I never use frameworks, only libraries. I feel everytime I use a framework there is some kind of mismatch between what the author of the framework had in mind and the problem at hand.

</comment><comment><USER71> The general principal the author is talking about — ie not being overly opinionated— and asking yourself " _Could I use this in combination with something else like it?_ " — could be applied to even something like a programming language.

For example, Elm 0.19+ would be the counter-example in this case. It makes it very hard t/ almost impossible to interact with JS code. A more flexible web front-end wouldn't force such a strong opinion upon its users. It would let the users decide, and leave flexibility / room in various aspects of the language.

</comment><comment><USER72> A common objection to this is the proposition that eventually engineering will produce a framework, even if it's not intentional, so why not just choose an existing one and adapt/patch as necessary?

I tend to agree that _good_ engineering teams will produce a useful framework, eventually--but this framework will be very specific to the domain of the problem it solves. It will be extensible and flexible to add new features to. It won't be something that can be generalized well to other problems, though.

</comment><comment><USER73> Frameworks can't be composed. This property is a huge red flag.

</comment><comment><USER74> There is also _Write Libraries, not language features_.

The progression _language - > library -> framework_ maps to _semantics_ -> _a vocabulary of expression_ -> _ideology_.

I think the OP has made an error in considering a framework as a sort of 'maximalist' construct that must cater to any and all possiblities.

Let's consider a (known) rigirously and formally specified 'framework' approach and see if it needs to "predict ... every kind of thing ... [possible to accomplish] within its [constraints]":

[https://www.oracle.com/technetwork/java/javase/documentation...](https://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html)

A framework design team is tasked with facilitating a technical goal:

RoR: "MVC for the world!".

Java Beans: "Tool makers of the world, unite!"

J2EE: "Look ma, my IT commodity programmer can do distributed component oriented programming and not even know it!".

At its most abstract consideration, RoR is an _idoelogical_ take on writing MVC. "This is how you do it". Beans nails down an approach for wirable components that can be supported at both design and runtime with tooling and automation. JEE says lays down 4 canonical and formally boxed contexts of _reference (naming)_ , _transaction_ , _persistence_ , _life-cycle_.

None of the above had to predict ahead of time "everything". Frameworks are almost always really about top-down considerations.

[p.s. follows]:

Keep in mind that we're always building on top of the 2 fundamental layers of _langauge semantics_ and _libraries_. The proverbial "standard library" is the reminder. So that just leaves the final layer, and the critical consideration of "more libraries" or "manifesto on how to use libraries".

The actual core issue is composition limitations. It is far easier to compose libraries (vocab-a + vocab-b + ..) than it is to compose framework (which may not even be possible).

A framework is a 'final consideration' of the best approach for a (set of) niche technical concern(s).

</comment><comment><USER75> Could this also be stated that a DSL or code that seeks to abstract away most code in the real language is more overhead to maintain, grow, and build on top of than building stuff mostly on top of real language?

In which case, are we merely saying adding code abstraction layers are at the extremes - where you need to add a lot of custom code - more overhead than working on top of the bare language.

</comment><comment><USER76> I found the blog post to be just another take on the micro-services vs monolithic application debate. Where micro-services = library and monolithic = framework. As a full-time coder I take a different approach - documentation is everything.

I could care less if a piece of code is a library, a framework, is made up of micro-services, or is monolithic. It all means diddly-squat if the documentation sucks and you can't figure out how to use the damn thing. It really doesn't matter if a big company sponsors the code either, because they usually have the worse documentation. Take the Mongoose Application Framework by Infor ([https://mongoose.infor.com](https://mongoose.infor.com)) which is supposed to be designed to help developers quickly build applications. The API has virtually no documentation. It has tons of libraries but you don't know what they do or what they are capable of unless you dig into the code to see what it does. They re-implement tons of standard .NET API with their own twist on it.

That experience changes the way I develop for fun. I have taken to do a lot my free-time coding with Python because the documentation, for the most part, is very well done. Most of the Python developers seem to take a documentation- first approach to their code which makes it easy to take on new concepts and branch out into different areas such as IoT or AI.

<comment><USER9> Django's docs are world class. It's by far the example I always reach for when talking to people about how I think "great" docs should be written and served.

</comment></comment><comment><USER77> On another note here a a few claims framework authors make which are usually short sighted

1\. Frameworks promote code reuse

Frameworks however don't promote reuse within different versions of the same framework, which makes the code reuse claim hypocritical at best.

Where is the code reuse between Angular 1 and Angular 2 ?

Libraries also promote code reuse by the use of shared object files (C) or modules (Python, Node.js ...) and it is usually more long lasting.

2\. Frameworks are easier for beginners to use

Frameworks get difficult quickly once the initial use case is run out. Frameworks appear deceptively simple because they hide complex code under the rug, but anytime you need to do functionality similar but different to that initial complex code, you will have a problem.

With a library, you can inspect the code ... copy it and edit it to do what you want, it is not as simple with frameworks especially when you have to deal with 100 levels of inheritance.

In a way frameworks encourage code illiteracy.

3\. Frameworks are not composable

Using two or more frameworks is next to impossible because of all the assumptions frameworks make. Frameworks are totalitarian in this regard.

4\. Object Relational mismatch is real

By forcing the object model on everything, it makes understanding non OO models for data, which is most data ... very difficult.

Relational model is more generic as it supports references and is obviously more efficient.

</comment><comment><USER78> I liked this piece, but came out of it more on the side of frameworks, oddly, than libraries. I went into it with a bias ostensibly shared by the author based on the title but here we are. Probably different priorities or values in terms of what constitutes 'shipping' I would guess based on our respective backgrounds.

</comment><comment><USER79> It's the most honourable way, but kiss goodbye to recognition and money. Somebody will slap a UI/app on top of it and get all the credit and get paid for it. It's one of the paradoxes of free software/open source.

AGPL fixes this somewhat but it just makes it practically not profitable for everybody involved.

</comment><comment><USER80> One nice benefit of framework restrictions is standardization. For example a Django developer can jump into a lot of Django projects and instantly know a lot about them. Things like the builtin admin are often very similar between projects. This can ease onboarding a great deal, to everyone's benefit.

</comment><comment><USER81> Phoenix is the only web framework I like, because I can understand and control its control flow in a way that I can't with, say, Rails. Plus running on BEAM is great - the whole Erlang ecosystem has always felt like what OOP hype-men promised us in the 90s and 00s, but in reality.

</comment><comment><USER82> > Google can back Angular, Pivotal can back Spring

Funny, when you talk about frameworks that create more problems than they solve, these two are the first two that pop into my head. In fact, I've been trying for years to find any problems that either of these two actually _do_ solve.

</comment><comment><USER83> One more of those Libraries, not frameworks

[https://atultechspace.wordpress.com/2019/02/19/libraries- vs-...](https://atultechspace.wordpress.com/2019/02/19/libraries-vs- frameworks/)

</comment><comment><USER84> Do we need frameworks? If you think a framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You dont need angular to write web app but you need browser and OS. So someone needs to write frameworks.

</comment><comment><USER85> First you write libs, then you get tired of always doing the same scaffolding work, so you build the boilerplates to cover the most common flows - <USER2> before you realized you end up with a framework... the resistance is futile

</comment><comment><USER86> I think the best way to make a framework is as a collection of libraries that are designed to work well together, but can also be used independently. Then users can pick and choose which parts they need.

<comment><USER87> This is why I like bootstrap. I usually pick the sass version, remove all includes, and only include what I use.

I like frameworks that allow this. Most don't, even if they claim they do.

</comment></comment><comment><USER88> Write free code, extract libraries, then organize some into frameworks.

We don't need to exclude any of those practice. In fact, focusing on only one of those is what leads to the most problems in my experience.

</comment><comment><USER89> I guess I should weigh in with my experience in this area, as author of both libraries and frameworks, in a lot of different domains, over a number of years.

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...](https://medium.com/chrismarshallny/testing-harness-vs- unit-498766c499aa)) 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.

[http://www.solipsys.co.uk/new/TheParableOfTheToaster.html](http://www.solipsys.co.uk/new/TheParableOfTheToaster.html)

</comment><comment><USER90> I like microframeworks because they do one thing well and they don't in the way - like a library. When I use batteries-included frameworks, I end up not using a lot of what they offer.

</comment><comment><USER91> I don't see Chefs complaining about the difference between getting better kitchen utensils versus working in a more functional kitchen. They go hand in hand.

</comment><comment><USER89> I agree.

However, I program for Apple devices, so my libraries are called "Frameworks."

I'd say that we should call them "Modules," instead. That probably covers all the bases.

<comment><USER92> > so my libraries are called "Frameworks."

Not if you make them static libraries.

<comment><USER89> Tru, dat, but static libraries are so "five minutes ago."

</comment></comment></comment><comment><USER93> This discussion is reminiscent of "composition" vs "inheritance" programming patterns.

You can "compose" libraries or "inherit" frameworks to execute the job.

</comment><comment><USER94> In a fundamental way, any programming language is a framework with many of the attached strings mentioned in the article.

</comment><comment><USER95> 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.

</comment><comment><USER87> Strapi. I just want the CMS/admin panel. I don't want the... well everything else

</comment><comment><USER96> Frameworks compose libraries for you, this is not always a good thing...

</comment><comment><USER84> Do we need frameworks? If you think framework is a layer of abstraction, then an OS is a framework, a browser is a framework. You don't need angular to write a web app, but you'll need OS and browser. So someone needs to write frameworks.

</comment><comment><USER97> Very well-written. Sounds like a discussion, not just a rant.

</comment><comment><USER98> You use libraries. Frameworks use you.

</comment><comment><USER99> >Libraries aren't everything, but they should be preferred.

The story is much much more complicated than this. Every single one of you is using a framework everyday, that is unless you program in assembly language.

All Programming languages are highly opinionated frameworks on top of assembly languages.

When you know this, then you know that you can't just say something simplistic like libraries are "preferred."

If all programming languages are frameworks on top of assembly language then frameworks are not only preferred they are Required for humans to make sense of complexity.

When you write a framework like django within the framework of python you are putting a framework within a framework. It's similar to writing a compiler that compiles some PL into python. You are building layers and layers of interfaces between your logic.

For every extra layer you add, two things, in general, happen:

         1. Complexity decreases
         2. Restriction increases

So when someone writes an article like this, what they are actually saying is this:

        "The complexity and restriction balance in the current framework/programming language
         strikes the right balance so in my opinion (keyword)
         writing another framework on top of the current framework will
         increase the restriction to the point where the trade off is not worth it."

When writing a library as opposed to a framework, what people are essentially doing is augmenting the capabilities of the current framework without creating an extra layer of abstraction. Another good way to think about it is that frameworks are equivalent to extra layers of abstraction and therefore the benefits and downsides of adding more layers of abstraction are equivalent to adding more frameworks. So it's really not as simple to say that "Libraries are preferred."

The story actually gets even more complicated then this. I spoke previously as if there is a trade off between Complexity and Restriction. While a decrease in complexity is always good, an increase in restriction is not always bad.

Take for example ELM. ELM is a language (or framework) that compiles to javascript and HTML. It is more restrictive then javascript due to type checking. Yes type checking is a framework that decreases freedom and increases restriction. But people think type checking is a good thing. Why? Well, the ELM type checker/framework is so powerful that it restricts you from ever writing a run time error. You absolutely do not have the freedom to write code that has certain bugs in ELM while in javascript you absolutely have the freedom to pollute your code with thousands of obscure bugs.

Restriction can be good, really good. In fact restriction outside of testing is our greatest tool and weapon for combating the problem of bugs occurring as a result of too much complexity.

In short, I don't like this article because it doesn't illustrate the full story. It kind of biases against frameworks. The author did not think deeply enough, he thinks of frameworks in terms of things like rails or django, but he does not think of what a framework is from a more general perspective.

Keep in mind, react or how react is used is basically a framework as well. Nobody uses it as a library, they prefer the component abstraction to take over the entire notion of the DOM.

</comment><comment><USER100> However if yo write a framework write a framework.

Don't cripple the community by doing the IoC part and the framework calls you but create a fragmented ecosystem of a million ways to do state, routing and so on.

Looking at you React. Doing Vue was so much easier when I had a Vue project because there were a lot fewer choices.

</comment><comment><USER101> _When a programmer thinks to herself_

I see the author is in the "they is not a singular pronoun" camp, which means we cannot be friends.

Anyway I don't know how it is in other parts of the stack, but based on my experiences on the front-end, to build a large-scale project you're going to need a:

\- Router

\- Way to manage forms & validation

\- Way to communicate with the backend

\- Set of tools for testing

\- Set of commonly used components - that includes layout

\- 118n support

\- Convention where to put certain files and how to name them

\- Store

So it would make sense to have all this in one coherent framework. That being said not all projects are large-scale projects. Normally you'll only need a subset of the mentioned.

Bottom line is it's a question of scale.</comment>


My Python Development Environment, 2020 Edition - <AUTHOR> https://jacobian.org/2019/nov/11/python-environment-2020/#atom-entries <comment><USER2> Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating.

I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv.

"pipenv install" gave me an error about accepting 1 argument, but 3 were provided.

Then I switched to Poetry. Poetry kept on detecting my Python2 installation, but not my Python3 installation. It seemed like I had to use pyenv, which I didn't want to use, since that's another tool to use and setup on different machines.

I gave up and started rewriting the project (web scraper) in Node.js with Puppeteer.

<comment><USER3> Yes. As someone who has never dove deep into python, but has had some contact with it: the package manager ecosystem is the #1 thing keeping me away from it.

npm sucks and all, but at least _it just works_ and doesn't get in my way as much.

<comment><USER4> What does npm do that python can't? I'm curious.

<comment><USER5> npm is equivalent to combining pip and virtualenv into a single tool. This gives better ergonomics when switching between projects since you never have to "activate" your environment, it's always activated when standing in the project directory.

<comment><USER6> Isn't this what Pipenv does? What has been a downer for me is that many of the cloud providers do not support pipfiles in their serverless app services (Elastic Beanstalk, App Engine etc.)

<comment><USER6> On second thought, at least on GCP I should be able to put the pipfiles into .gcloudignore and just update the requirements.txt file with each new commit using git hooks, build scripts or a ci/cd tool.

</comment></comment></comment></comment></comment></comment><comment><USER7> I have never understood the need for all the different tools surrounding Python packaging, development environments, or things like Pipenv. For years, I have used Virtualenv and a script to create a virtual environment in my project folder. It's as simple as a node_modules folder, the confusion around it is puzzling to me.

Nowadays, using setuptools to create packages is really easy too, there's a great tutorial on the main Python site. It's not as easy as node.js, sure, but there's tools like Cookiecutter to remove the boilerplate from new packages.

requirements.txt files aren't very elegant, but they work well enough.

And with docker, all this is is even easier. The python + docker story is really nice.

Honestly I just love these basic tools and how they let me do my job without worrying about are they the latest and greatest. My python setup has been stable for years and I am so productive with it.

<comment><USER8> I'm firmly set on virtualenv with virtualenvwrapper for some convenience functions. Need a new space for a project? mkvirtualenv -p /path/to/python projectname (-p only if I'm not using the default configured in the virtualenv config file, which is rare)

From there it's just "workon projectname" and just "deactivate" when I'm done (or "workon otherprojectname")

It has been stable and working for ages now. I just don't see any strong incentive to change.

<comment><USER9> I have been doing this starting Ubuntu 14.04. it's been stable even when I upgraded now to 18.04 which has python 3 as default. The only downside compared with tool such as pipenv is the automatic update of packages that pipenv can offer and it's ability to be integrated into CI/CD pipelines.

</comment></comment></comment><comment><USER10> For those new or unfamiliar with python, I think the best solution is the simplest: pip and virtualenv

<comment><USER11> Seriously. The author is bending over backwards to accommodate poetry from every direction, from the stupidest installation instructions I've heard, to "can't transfer from requirements.txt" to "it doesn't work well with docker but doable". Like what exactly does it add that's worth all this complexity? Make you a maitai every hour?

</comment></comment><comment><USER12> Eeeehhh I think I will be downvoted to hell and back for this but after I read the article I had the feeling of "why are you making this feel more complex than it needs to be?"

I mean compared to Java and C# I have a MUCH MORE EASIER time to set up my development environment. Installing Python, if I am on a Windows box I mean, is enough to satisfy a lot of the requirements. I then clone the repo of the project and

source venv/bin/activate

pip install -r requirements.txt

is enough to get me to start coding.

<comment><USER13> > "why are you making this feel more complex than it needs to be?"

Because it's more complex if you have projects on multiple Python versions and if you want to lock your Python packages to specific versions. (Pip can bite you when different packages have different requirements for the same lib).

</comment></comment><comment><USER14> If you're going to be using pyenv + poetry you should be aware of #571 that causes issues with activating the virtualenv

[https://github.com/sdispater/poetry/issues/571](https://github.com/sdispater/poetry/issues/571)

the OP himself has a fix for this in his own dotfiles repo:

[https://github.com/jacobian/dotfiles/commit/e7889c5954daacfe...](https://github.com/jacobian/dotfiles/commit/e7889c5954daacfe0988fc05ff9e8e87eb1241b7)

<comment><USER15> Ha, I'd forgotten about that. Thanks for the reminder.

(Though, how'd you find that? Mildly creepy that you know more about my dotfiles than I do!)

<comment><USER14> I landed on that issue a while ago and your pull request was linked so I ripped your solution and added it to my own dotfiles :)

</comment></comment></comment><comment><USER16> > Although Docker meets all these requirements, I don't really like using it. > I find it slow, frustrating, and overkill for my purposes.

How so? I've been using Docker for development for years now and haven't experienced this EXCEPT with some slowness I experienced with Docker Compose upon upgrading to MacOS Catalina (which turned out to be bug with PyInstaller, not Docker or Docker Compose). This is on a Mac, btw; I hear that Docker on Linux is blazing fast.

I personally would absolutely leverage Docker for the setup being described here: multiple versions with lots of environmental differences between each other. That's what Docker was made for!

<comment><USER17> The build step for installing or upgrading a package can be a killer with nontrivial projects.

<comment><USER18> It seems like long builds are either (a) necessary or (b) user error. (a) If you have a tree of dependencies and you change the root, you should rebuild everything that depends on it to make sure it's still compatible. (b) if you placed your application into one of the initial Dockerfile layers, but then you're installing dependencies that don't depend on you, it's user error.

What's the situation where your application needs to go first in the Dockerfile, and then you need to put a bunch of stuff that doesn't depend on your application?

</comment></comment></comment><comment><USER19> The Dockerfile that's provided looks like it would be very slow to build. I always try to make Dockerfiles that install deps and then install my python package (usually just copy in the code and set PYTHONPATH) to fully take advantage of the docker build cache. When you have lots of services it really reduces the time it takes to iterate with `docker-compose up -d --build`-like setups.

</comment><comment><USER20> In addition to the popular conda, it's worth checking out WinPython for scientific use. Each WinPython installation is an isolated environment that resides in a folder. To move an installation to another computer, just copy the folder. To completely remove it from your system, delete the folder.

I find it useful to keep a WinPython installation on a flash drive in my pocket. I can plug it into somebody's computer and run my own stuff, without worrying that I'm going to bollix up their system.

</comment><comment><USER21> Curious to hear other's experiences with pipenv vs poetry. Has anyone made the switch?

<comment><USER22> I switched from pipenv to poetry over 1 year ago. I love it!

The main reasoning was so that I could easily build and publish packages to a private repository and then easily import packages from both pypi and the private repository.

Happy to answer more questions.

<comment><USER23> I'd like to use poetry however ran into [https://github.com/sdispater/poetry/issues/1554](https://github.com/sdispater/poetry/issues/1554)

We have a custom pypi server and need all requests to go through it, however haven't figured a way to make poetry always use our index server for all modules instead of pypi.org

<comment><USER24> Add a second source and it will prioritise that over pypi.

      [[tool.poetry.source]]
      name = "my-repo-name"
      url = "https://myrepo.url/"

</comment></comment></comment></comment><comment><USER25> > On Linux, the system Python is used by the OS itself, so if you hose your > Python you can hose your system.

I never manged to hose the OS Python on Linux, by sticking to a very simple rule: DON'T BE ROOT. Don't work as root, don't run `sudo`.

On Linux, I use the system python + virtualenv. Good enough.

When I need a different python version, I use docker (or podman, which is an awesome docker replacement in context of development environments) + virtualenv in the container. (Why virtualenv in the container? Because I use them outside the container as well, and IMHO it can't hurt to be consistent).

</comment><comment><USER26> I love Python syntax, but I still haven't found a sufficiently popular way that can deploy my code in the same set of setting s as my dev box (other than literally shipping a VM). So setting up a dev env is one problem, but deploying it so that the prod env is the same and works the same is another.

</comment><comment><USER27>
        python -m venv venv
        source venv/bin/activate
        pip install -U pip
        pip install whatever
        # <do you stuff here>
        deactivate

no need any third-party tools, venv is built-in the above steps always worked for me out of the box.

<comment><USER28> But how about replacing all of these commands with two words? poetry install

<comment><USER27> which is another layer of abstraction and dependency that I do not really need, e.g poetry no longer maintained, poetry(or whatever) has an urgent bugfix,etc

</comment></comment></comment><comment><USER29> This article is great, those are viable solutions for sure. One of the alternatives is conda: it's common among data scientists, but many of its features (isolation between environments, you can keep private repository off the internet) meet enterprise needs.

</comment><comment><USER30> I would generally reach for conda instead of this, but they seem quite comparable in aggregate.

And, given that I've been trying NixOS lately and had loads of trouble and failing to get Conda to work, I will definitely give this setup a try.

(I haven't quite embraced the nix-shell everything solution. It still has trouble with some things. My current workaround is a Dockerfile and a requirements.txt file, which does work...)

</comment><comment><USER31> I like Python has a language, but when I see how clean are the tools of other similar languages, for example Ruby, compared to the clusterf __k of the Python ecosystem, it just make me want to close the terminal. I 'm always wondering how it became the language #1 on StackOverflow.

</comment><comment><USER32> I recommend asdf for version management if you use more than one programming language

<comment><USER33> [https://common-lisp.net/project/asdf/](https://common-lisp.net/project/asdf/) ?

<comment><USER34> [https://asdf-vm.com/](https://asdf-vm.com/)

</comment></comment></comment><comment><USER35> There are two things that I find a bit elusive with Python:

1\. Highlight to run 2\. Remoting into a kernel

Both features are somewhat related. I want to be able to fire up a Python Kernel on a remote server. I want to be able to connect to it easily (not having to ssh tunnel over 6 different ports). I want connect my IDE to it and easily send commands and view data objects remotely. Spyder does all this but its not great. You have to run a custom kernel to be able to view variables locally.

Finally, I want to be able to connect to a Nameko or Flask instance as I would any remote kernel and hot-swap code out as needed.

</comment><comment><USER36> So far using docker and setup.py files is working for me, I've never felt they were particularly slow, so I'll keep using them.

I gotta give poetry a try, though.

</comment><comment><USER37> Why not just use conda for envs and deps (or env-specific pip), and install youtube-dl etc. via your platform's package manager?

<comment><USER38> In my experience, conda breaks quite often. Most recently, conda has changed the location where it stores DLLs (e.g. for PyQt), which broke pyinstaller- based workflows.

In principle, it's a good idea; in practice, I'm not satisfied. On Windows, it's an easy solution, especially for packages that depend on non-python dependencies (e.g. hdf5).

</comment></comment><comment><USER39> I've been manually deploying my projects for years.

Can anyone comment on the Docker learning & troubleshooting story for python?

<comment><USER18> Docker + setuptools/pip + python is great for development and production. Docker is definitely worth learning, and is pretty easy to learn.

</comment></comment><comment><USER40> I like pip-tools for venv requirements management, but I don't see it mentioned much.

<comment> globular-toast I use pip-tools. It fits in nicely as an additional component to the standard toolset (pip and virtualenv). But most people probably do not need to freeze environments so it's great to be able to _not_ use it for most projects.

</comment></comment><comment><USER41> My sole use of Python is writing plugins (mostly single-user: me) for Sublime Text.

It feels pretty comfy to effectively be on an island and far away from the hustle and bustle of the industrial Python tooling.

</comment><comment><USER42> Related from 2018: [https://news.ycombinator.com/item?id=16439270](https://news.ycombinator.com/item?id=16439270)

</comment><comment><USER43> I've moved to ASDF and haven't really looked back. It's working well with low fuss, and supporting far more than just python on my machine.

</comment><comment><USER44> I'll pay anyone who can assist me with my Python setup. Is there a service like this, where one can find a developer on demand?

<comment><USER45> I have been using a consistent setup that hasn't yet failed me for the past 2 years.

1\. Install Anaconda to your home user directory .

2\. create environment using (conda create --name myenv python=3.6) .

3\. Switch to the environment using (conda activate myenv) .

4\. Use (conda install mypackage), (pip install mypackage) in that priority order .

5\. Export environment using (conda env export > conda_env.yaml) .

6\. Environment can be created on an other system using (conda env create -f conda_env.yaml) .

Anaconda: [https://www.anaconda.com/distribution/#download- section](https://www.anaconda.com/distribution/#download-section) .

Dockerized Anaconda: [https://docs.anaconda.com/anaconda/user- guide/tasks/docker/](https://docs.anaconda.com/anaconda/user- guide/tasks/docker/) .

<comment><USER46> I can vouch for this. Anaconda is especially good for simulation/data stuff (based on the focus on which packages are included by default).

One pain point though: getting it to work with Sublime Text 3 requires you to set the `CONDA_DLL_SEARCH_MODIFICATION_ENABLE` environment variable to `1` on Windows.

Not a flaw of Anaconda: it just pays attention to how to with multiple Python installations on Windows.

</comment></comment></comment><comment><USER47> Why pipx vs just using pip?

<comment><USER48> With pipx when you install things they go into isolated environments. With pip you're just installing things globally.

This difference is important due to dependencies- if you have two different CLI tools you want to install but they have conflicting dependencies then pip is going to put at least one of them into an unusable state, while pipx will allow them to both coexist on the same system.

<comment><USER49> I haven't used pipx, but as far as I understand, pipx = pip + venv. If your pip executable is in a virtualenv, the "globally installed" is locally installed.

pipx, poetry, pipenv and co are still nice wrappers to have, I suppose. It just feel less useful now that most of my projects are dockerized.

<comment><USER50> pipx looks nice. Is there any way to persuade it to install 'wheel' before it installs the desired package?

That way 'pipx install foo' can download and install wheels rather than downloading source distributions and building/installing them...

</comment></comment></comment></comment><comment><USER51> > Governance: the lead of Pipenv was someone with a history of not treating > his collaborators well. That gave me some serious concerns about the future > of the project, and of my ability to get bugs fixed.

Doesn't seem fair. You're not abandoning requests, are you?

<comment><USER52> Just noticed requests moved from kennethreitz/requests to psf/requests. Interesting.

Edit: From [https://www.python.org/psf/github/](https://www.python.org/psf/github/),

> ... we have created a GitHub organization, @psf, to support and protect > projects that have outgrown ownership by their original author.

</comment></comment><comment><USER53> This is so painful to see compared to using conda.

<comment><USER54> 1\. The author of this post helped to create the Django framework and runs a successful Python consultancy.

2\. Conda is not used as much as you might think... it's really only used within the data science community.

<comment><USER53> 1\. Argument from authority doesn't mean anything to me. I also don't believe creating Django or running a Python consultancy endow someone with especially useful opinions of Python packaging tooling. (Not that the author isn't knowledgeable, just you seem to think there's an A implies B relationship between those two items and having good opinions about Python packaging, and there's not).

2\. Conda is quite widely used outside of data science. It's for example part of Anaconda enterprise offerings used by huge banks, government agencies, universities, etc., on large projects often with no use cases related to data science. Conda itself has no logical connection with data science, it's just a package & environment manager.

In each of my last 4 jobs, 2 at large Fortune 500 ecommerce companies, conda has been the environment manager used for all internal Python development. Still use pip a lot within conda envs, but conda is the one broader constant.

<comment><USER55> > huge banks, government agencies, universities

> large Fortune 500 e-commerce companies

Sorry, but argument from authority doesn't mean anything to me.

In all seriousness though, you literally did not provide any logical reasons to think conda is better.

<comment><USER53> Giving a counterexample is not argument from authority. I did not respond to the parent comment to discuss any feature of conda, only to dispel the wrong claim that only mostly data science projects rely on it.</comment></comment></comment></comment></comment>


Show HN: I made a JavaScript microframework in under 700 sloc - <AUTHOR> https://h3.js.org <comment><AUTHOR> See also an introductory article discussing why and how I made this: [https://h3rald.com/articles/h3/](https://h3rald.com/articles/h3/)

</comment><comment><USER2> The function naming is unfortunate, it looks like we're creating a bunch of
title
 elements.

<comment><AUTHOR> The h3 function is the default export, you can give it whatever name you want when you import it.</comment></comment>


Electric vehicles need new "assembly line" breakthrough - <AUTHOR> http://blogs.scientificamerican.com/plugged-in/2013/08/28/guest-post-electric-vehicles-need-new-assembly-line-breakthrough/

<comment><USER2> i think the best part of the article was the first comment by "Sault"</comment>


Etcher – A Modern USB and SD Card Image Writer Tool for Linux - <AUTHOR> https://www.fossmint.com/etcher-usb-sd-card-bootable-image-creator-for-linux/ <comment><USER2> And by "modern" they mean "a 50-lines script wrapped in 100MB Electron runtime"?</comment>


Judge orders New York to pay unemployment to Uber and Lyft drivers - m-watson https://arstechnica.com/tech-policy/2020/07/judge-orders-new-york-to-pay-unemployment-to-uber-and-lyft-drivers/ <comment><AUTHOR> Am I getting this right? New York (along with California) forced Uber and Lyft to reclassify their contractor drivers as employees -- and then refused to pay them unemployment, as their employee status would require?

<comment> m-watson It seems like a kind of situation from this part:

"Since 2016, the New York Department of Labor has held that ride-hail drivers were employees for purposes of unemployment insurance. But Uber and Lyft have dragged their feet, failing to provide wage data that would enable the agency to calculate unemployment payments for each worker."

So they have to consider them employees for purposes of insurance but seem to not have fully complied in the first place.

</comment></comment><comment> m-watson The actual ruling [PDF]: [https://www.courtlistener.com/recap/gov.uscourts.nyed.448390...](https://www.courtlistener.com/recap/gov.uscourts.nyed.448390/gov.uscourts.nyed.448390.24.0.pdf)</comment>