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

A better build system for OCaml

blog.janestreet.com

Post reply on HN
Print view View original

201–210 of 219 posts

Re: A better build system for OCaml

#201

Post by dgfitz »

kevin_thibedeau wrote: post #71
cmrdporcupine wrote: post #48

Earlier quoted context omitted.

It's hobbled not just by that but by the fact that it's not the thing doing the building. It's a build system for build systems, and suffers from brittleness and confusion as a result.

Make, in all its various implementations, is far more brittle than CMake. Ninja requires a meta-build tool like CMake.

Kevin, I must be missing something.

CMake can generate a makefile, and this is the usual usecase. So a new language generating a makefile is even _more_ brittle than make, if your assertion is correct.

Re: A better build system for OCaml

#202

Post by eru »

patmorgan23 wrote: post #179
lotsofpulp wrote: post #157

Earlier quoted context omitted.

Automation in trading makes all investors wealthier via lower fees. Trading costs basically nothing nowadays, and that is because far fewer people are employed to do it. Obviously, the people who own the automation will want a cut of the rewards, like any other business.

Automation in trading != HFT algorithms Obviously NASDAQ and electronic trading systems are a good innovation. But firms basically doing arbitrage or exploiting uneven network latency are not that economically productive.

And Jane Street isn't a classic HFT either. Speed isn't their differentiating factor (or at least wasn't in the past).

Re: A better build system for OCaml

#203

Post by eru »

n4r9 wrote: post #193
kqr wrote: post #189

Earlier quoted context omitted.

Tighter spreads and higher liquidity is not economically productive? I can see arguments both ways.

For me, it's about whether that higher liquidity is really worth using top engineering and mathematical talent.

Well, that's what we have market price signal for to decide.

Re: A better build system for OCaml

#204

Post by pimeys »

mananaysiempre wrote: post #177
nicoburns wrote: post #29

Earlier quoted context omitted.

As a user of Linux, I wish Linux distributions would abandon their build systems which really only work well for C and maybe C++, and also only work on one platform (not even the whole of linux!) meaning that packaging has to be duplicated for every OS, and stuck to using more familiar language-specific build systems that work everywhere. (this rant more or less equally applies to all os-or-distro-specific build syst…

> [Distro-specific build systems are] probably the biggest barrier to me shipping software on Linux. Don’t[1]. Ship source tarballs (or VCS tags). I’ll grant that most distros’ build systems are antiquated and, in places, silly. (That includes Nixpkgs, first released 2006.) We could really use some fresh ideas there. But they’re also not for you (or me) in your (or my) capacity as a software author. They’re there for…

This is why I'm really looking into SerpentOS and their moss build system. Kind of like a combination of Nix and AUR. Simple syntax, simple to create packages, atomic.

https://serpentos.com/docs/packaging/

Re: A better build system for OCaml

#205

Post by andrepd »

rank0 wrote: post #197
patmorgan23 wrote: post #179

Earlier quoted context omitted.

Automation in trading != HFT algorithms Obviously NASDAQ and electronic trading systems are a good innovation. But firms basically doing arbitrage or exploiting uneven network latency are not that economically productive.

Absurd statement. Use your big brain CS mind for a second. This is you: > Inefficient market spreads and network latency is not worth remediating.

> Inneficient market spreads

Well lowering market spreads is all about increasing the returns for capital, and incenctivising overfinancialisation. It's hardly curing cancer is it?

At worst it's actively harmful if you believe that the current state of turbo-financialised capitalism has its drawbacks.

> Network latency

Not really sure what you're talking about but surely spending billions of dollars to bring rtt latencies to 50 micros or whatever is not really a great use of money and top engineering talent. Again, it's playing an arbitrage game but not really delivering any value.

Re: A better build system for OCaml

#206

Post by andrepd »

SkiFire13 wrote: post #96
shepherdjerred wrote: post #75

Earlier quoted context omitted.

Isn’t borrow checking only compile time?

Yes, but sometimes it forces you to write slightly slower code that can be proven safe.

> forces you

Definitely doesn't, you can just slap unsafe and manipulate raw pointers if that's what you want

Re: A better build system for OCaml

#207

Post by andrepd »

nvarsj wrote: post #140
globular-toast wrote: post #84

Earlier quoted context omitted.

Maybe, but could you live with the fact that you're providing absolutely no value to the world? It always makes me sad when the greatest minds get gobbled up by these companies because they're creaming off the top of an enormously complex system they created.

As someone that used to work in this world I find this opinion of “no value” pretty bizarre. There’s a lot of value in efficient markets with high liquidity and low fees, which companies like JS make possible.

Great, better return for capital and more over-financialisation of the economy. It's hardly curing cancer is it?

Re: A better build system for OCaml

#208

Post by rank0 »

andrepd wrote: post #205
rank0 wrote: post #197

Earlier quoted context omitted.

Absurd statement. Use your big brain CS mind for a second. This is you: > Inefficient market spreads and network latency is not worth remediating.

> Inneficient market spreads Well lowering market spreads is all about increasing the returns for capital, and incenctivising overfinancialisation. It's hardly curing cancer is it? At worst it's actively harmful if you believe that the current state of turbo-financialised capitalism has its drawbacks. > Network latency Not really sure what you're talking about but surely spending billions of dollars to bring rtt late…

We just have fundamentally different values. People like you are closeted dictators.

I want liquidity, low spreads, price discovery. You seem to forget that “not delivering any value” is just like y’know according to you…

Re: A better build system for OCaml

#209

Post by troad »

lmm wrote: post #194
troad wrote: post #192

Earlier quoted context omitted.

> I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Very respectfully, I think you may be missing the author's point. When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity.

> When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity. If that's what they're claiming then I completely disagree. No, that's not the reason, that's got nothing to do with it. If that were true we would expect e.g. projects with more complicated builds to have simpler co…

Again, respectfully, I don't think that follows (or makes much sense). There is not a set amount of complexity for all software that gets apportioned between the build system and the business logic, so that an increase in one necessarily means a reduction in the other.

Instead, each domain space has some degree of inherent complexity, which varies from problem to problem. Failing to account for this inherent domain complexity appropriately will cause it to bubble through at unexpected points throughout the system.

Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.

Re: A better build system for OCaml

#210

Post by lmm »

troad wrote: post #209
lmm wrote: post #194

Earlier quoted context omitted.

> When you fail to make a home for necessary complexity, it rears its head as unintended complexity in unexpected parts of the system. The source of 'accidental' complexity is unaccounted for complexity. If that's what they're claiming then I completely disagree. No, that's not the reason, that's got nothing to do with it. If that were true we would expect e.g. projects with more complicated builds to have simpler co…

Again, respectfully, I don't think that follows (or makes much sense). There is not a set amount of complexity for all software that gets apportioned between the build system and the business logic, so that an increase in one necessarily means a reduction in the other. Instead, each domain space has some degree of inherent complexity, which varies from problem to problem. Failing to account for this inherent domain c…

> Build systems inherently have a very complex job. A good build system grapples with this complexity and tries to harness it; a bad one pretends it isn't there, and becomes a tangled mess once the (inevitably complex) demands made of it exceed its limited assumptions.

I don't think this is true. I think that when looked at in the right way the job of a build system (when used appropriately) is actually fairly simple, and most build system complexity is either accidental complexity (either just straight-up bad design, or misguidedly overengineered flexibility in directions that don't matter) or comes from trying to accommodate things that the build system shouldn't have been doing in the first place. When I've seen overcomplicated builds they've never been because the build system made assumptions that were too limiting.

Post reply on HN