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

Make for hipsters

mattandre.ws

Post reply on HN
Print view View original

161–170 of 200 posts

Re: Make for hipsters

#161

Post by nailer »

coldtea wrote: post #156
nailer wrote: post #148

Earlier quoted context omitted.

Totally agreed, that's why most npm modules are focused on specific tasks, and we use github and npm to track how active projects are before installing them. It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.

> It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it. The first part of this is a guess -- and it's wrong. I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying ut…

> and it's wrong.

Fair enough. Just saying that's the impression I get.

> even those focused on specific high level tasks tend to depend on tons of lower level modules

Yes. Good libraries do that. Smaller bits are made from bigger bits.

> living them open to things like the "leftpad" fiasco

I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.

> And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.

Indeed. It's an answer to your concern about "npm module du jour that gets abandoned 2-3 years later or completely rewritten".

I'm not sure that npm, gulp changing significantly is a bad thing. Good software evolves over times. As long as the changes are clearly communicated I'm 100% down with that. Look how much better express got!

Re: Make for hipsters

#162

Post by mhd »

agentgt wrote: post #99
mhd wrote: post #34

Earlier quoted context omitted.

That was Java all over again. - you've got dependencies on some basic Unix commands (cp, rm etc.) in your tasks, so better rewrite that all to use your cross-platform language's facilities. - XML, erm, no, JSON, shall be your only file format.

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers. Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local…

> Linux/Unix was barely known to most developers.

As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly?

But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.

Re: Make for hipsters

#163

Post by agentgt »

snuxoll wrote: post #159
agentgt wrote: post #99

Earlier quoted context omitted.

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers. Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local…

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, p…

I pretty much agree entirely but have been too ashamed to say it :)

The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages.

As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).

Re: Make for hipsters

#164

Post by khedoros »

snuxoll wrote: post #157
khedoros wrote: post #141

Earlier quoted context omitted.

I like SysV-style init systems. I also don't mind RPM .spec files. They've always let me get the job done.

I hated SysV init, because writing init scripts is a chore - especially since you have little to no choice but to implement the detach/fork strategy to get a daemon to work properly without resorting to things like supervisord, etc. As much flak as systemd gets for trying to do too many tasks, I really find it a much better solution to `init`. With that said, I agree about rpmspec's. They're simple to read and easy t…

I certainly can't disagree about the SysV boilerplate, but I also haven't written more than 5 or 6 of those init scripts in the last decade, so it's never seemed bad enough to me to ditch it for something completely different.

In my current day-to-day, between work machines and my personal machines at home, I've only got to deal with init stuff occasionally, so picking up the Systemd way of doing things will take me a while.

Re: Make for hipsters

#165

Post by coldtea »

nailer wrote: post #161
coldtea wrote: post #156

Earlier quoted context omitted.

> It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it. The first part of this is a guess -- and it's wrong. I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying ut…

> and it's wrong. Fair enough. Just saying that's the impression I get. > even those focused on specific high level tasks tend to depend on tons of lower level modules Yes. Good libraries do that. Smaller bits are made from bigger bits. > living them open to things like the "leftpad" fiasco I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpub…

>Yes. Good libraries do that. Smaller bits are made from bigger bits.

I think there's a marginal returns (or worse negative returns) border with this approach, where the overhead, over-generalization, and, finally, bloat, maintenance and management issues stemming from having too many small parts from disparate sources justify writing a specialized solution.

Leftpad would be an extreme case in point -- I'd put the bar even higher than that.

>Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.

The "unpublish" thing just made the issue instantly apparent, but the core issue would still be there even if nobody could ever unpublish anything.

E.g. such small modules could get abandoned and neglected with bugs or security issues, could have extra bloat the parent library doesn't need (this might not hold with leftpad but would be true for anything a little larger that covers 10 things when you only need 2 and could code them yourself and be done with it), is now a dependency that has to be tracked and updated, it's not optimized for the particular use case it is used in, etc.

Re: Make for hipsters

#166

Post by gerbilly »

snuxoll wrote: post #159
agentgt wrote: post #99

Earlier quoted context omitted.

Well in fairness Java does have the excuse that the cloud, and virtual images didn't exist and it was basically a Windows world. Linux/Unix was barely known to most developers. Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local…

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, p…

I too think maven (from 2.0 onwards anyways) is awesome.

It's also declarative, BTW, which is a big improvement over Ant.

Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?

Re: Make for hipsters

#167

Post by snuxoll »

agentgt wrote: post #163
snuxoll wrote: post #159

Earlier quoted context omitted.

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, p…

I pretty much agree entirely but have been too ashamed to say it :) The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages. As a tech decision maker I would love to build future projects with Rust or OCam…

> I pretty much agree entirely but have been too ashamed to say it :)

I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days.

Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands.

> As a tech decision maker I would love to build future projects with Rust or OCaml

I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(

Re: Make for hipsters

#168

Post by nailer »

coldtea wrote: post #165
nailer wrote: post #161

Earlier quoted context omitted.

> and it's wrong. Fair enough. Just saying that's the impression I get. > even those focused on specific high level tasks tend to depend on tons of lower level modules Yes. Good libraries do that. Smaller bits are made from bigger bits. > living them open to things like the "leftpad" fiasco I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpub…

> Yes. Good libraries do that. Smaller bits are made from bigger bits. I think there's a marginal returns (or worse negative returns) border with this approach, where the overhead, over-generalization, and, finally, bloat, maintenance and management issues stemming from having too many small parts from disparate sources justify writing a specialized solution. Leftpad would be an extreme case in point -- I'd put the b…

> E.g. such small modules could get abandoned and neglected with bugs or security issues

How well do you think a module with 1000 users is likely to be maintained, vs a create-your-own-wheel equivalent?

Do you think writing the latter is an adequate use of your time?

Do you think you'll discover all the edge cases?

How does writing your own wheel module rank when compared to working on features your customers want?

Re: Make for hipsters

#169

Post by JdeBP »

wbl wrote: post #135
LukeShu wrote: post #126

Earlier quoted context omitted.

What do you mean by "dependencies in the form of variables"?

Let's say I need to build the library again with a different set of options. Make clean and rebuild is only solution, even if not needed.

At this point in the chain of thinking, you should read http://cr.yp.to/redo/honest-script.html

Re: Make for hipsters

#170

Post by snuxoll »

gerbilly wrote: post #166
snuxoll wrote: post #159

Earlier quoted context omitted.

> Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, p…

I too think maven (from 2.0 onwards anyways) is awesome. It's also declarative, BTW, which is a big improvement over Ant. Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?

> It's also declarative, BTW, which is a big improvement over Ant.

It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome.

I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it!

> Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?

A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.

Post reply on HN