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

191–200 of 219 posts

Re: A better build system for OCaml

#191

Post by vasco »

Capricorn2481 wrote: post #178
vasco wrote: post #93

Earlier quoted context omitted.

Is the problem with the system or with the minds? The minds that want to scroll are the same as the ones that make money on the scrolling, that made the scrolling itself, and that made the system we're in. Why is it that defeatist comments always focus on the capitalism part and not on anything else? I don't think it's perfect like we aren't perfect but unless you have some particular suggestion this type of comment…

> Why is it that defeatist comments always focus on the capitalism part and not on anything else Because endless growth is the only reason these once fun spaces have been hyper focused to be as addictive and stressful as possible to the "whales" of scrolling. That's why, when their own internal reports say "people spend unhealthy time on our platform and it's making them unhappy," it gets passed up the chain of comma…

> No? Where are you getting this? I don't think the people guiding these companies want to spend 6 hours scrolling TikTok. This is not the way most people live their lives.

I meant they are all humans. We're all sort of the same. If you disagree just think of your opinion of any other species, or about a group of people a thousand years ago, and you see what I meant.

Re: A better build system for OCaml

#192

Post by troad »

lmm wrote: post #83
troad wrote: post #54

Earlier quoted context omitted.

>> Complexity has to live somewhere . If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity…

I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental. And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically m…

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

Re: A better build system for OCaml

#193

Post by n4r9 »

kqr wrote: post #189
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.

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.

Re: A better build system for OCaml

#194

Post by lmm »

troad wrote: post #192
lmm wrote: post #83

Earlier quoted context omitted.

I think that's true up to a point, but it misses the distinction between accidental and essential complexity. Essential complexity has to go somewhere, accidental complexity doesn't, and most complexity in software is accidental. And even when the complexity is essential, IMO it's better off not in the build system. I'll gladly accept more complex code for the sake of a simpler build (even though that theoretically m…

> 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 code, and IME that's not true.

Re: A better build system for OCaml

#195

Post by Maxatar »

dumah wrote: post #160
coder543 wrote: post #60

Earlier quoted context omitted.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".

Java https://github.com/openjdk/jdk/blob/master/Makefile Rust https://github.com/rust-lang/rust/blob/master/tests/run-make... Go https://github.com/golang/go/blob/master/src/runtime/Makefil... NodeJS https://github.com/nodejs/node/blob/main/Makefile OCaml https://github.com/ocaml/ocaml/blob/trunk/Makefile Python https://github.com/python/cpython/blob/main/Makefile.pre.in Haskell https://github.com/ghc/ghc/blob/master…

In case you're not trolling (and it's really hard to tell), those makefiles are for building projects whose source code is written using C or C++. The projects they are building are things like the Java runtime, Go runtime, or the Rust compiler, but they are not building projects whose source code is written in Java, or Rust, or Go etc...

What people are claiming is that make is used as a build system for projects whose source code is written in C or C++.

Re: A better build system for OCaml

#196

Post by deepsun »

hereonout2 wrote: post #95
deepsun wrote: post #90

Earlier quoted context omitted.

Some fraction of young minds, not all. I was happy to work at a small aerospace company with extreme concentration of brightest minds. Only because they loved the domain, and didn't mind a salary cut. What a joy and relief it was for me after FAANG!

Possibly you didn't mind the salary because you'd already worked at FAANG?

No, I eventually left because money, I needed to save for a house. Most of the staff were locals, so already had own/inherited property to live in. After FAANG it was new to work with mostly locals, way more stories about the surroundings.

Re: A better build system for OCaml

#197

Post by rank0 »

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.

Absurd statement. Use your big brain CS mind for a second. This is you:

> Inefficient market spreads and network latency is not worth remediating.

Re: A better build system for OCaml

#198

Post by yen223 »

IshKebab wrote: post #156
tombert wrote: post #4

I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love. I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.

I dunno if anyone really doubted HM, functional programming could work. I've written a bit of OCaml and apart from the bad syntax (code very easily becomes a word soup) it's not especially different to other programming languages, just more convenient sometimes. I think it's purity that actually is a big difference, but OCaml isn't pure.

My humble opinion is that the every-function-must-be-pure aspect of Haskell is the reason why Haskell won't receive mainstream success, not that that's what they're after.

It complicates things that are simple to express in an imperative language

Re: A better build system for OCaml

#199

Post by IshKebab »

yen223 wrote: post #198
IshKebab wrote: post #156

Earlier quoted context omitted.

I dunno if anyone really doubted HM, functional programming could work. I've written a bit of OCaml and apart from the bad syntax (code very easily becomes a word soup) it's not especially different to other programming languages, just more convenient sometimes. I think it's purity that actually is a big difference, but OCaml isn't pure.

My humble opinion is that the every-function-must-be-pure aspect of Haskell is the reason why Haskell won't receive mainstream success, not that that's what they're after. It complicates things that are simple to express in an imperative language

I agree. It definitely has benefits but the downsides are just too big for most people.

Re: A better build system for OCaml

#200

Post by rat87 »

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…

That doesn't scale though beyond the most popular open source apps especially those in c/c++

Less popular apps or closed source apps don't work. Things with old dependencies won't work. Other language with package manager which depend on dependencies and dependency versions that may not be in distro packages may have trouble.

For the core the distro model might work. For the rest maybe something like flatpack from the devs might scale

Post reply on HN