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

Autoconf makes me think we stopped evolving too soon

rachelbythebay.com

Post reply on HN
Print view View original

141–150 of 169 posts

Re: Autoconf makes me think we stopped evolving too soon

#141

Post by chubot »

phoe-krk wrote: post #139
chubot wrote: post #131

Earlier quoted context omitted.

Yeah the way I frame it is that Lisp is about "interior" composition (functions and data), not "exterior" (processes andf iles) Narrow Waists Can Be Interior or Exterior: PyObject vs. Unix Files https://www.oilshell.org/blog/2023/06/narrow-waist.html However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? Well I guess Clojure/EDN is that, but nobody has produced a POLYGL…

> However the "exterior" extension seems obvious to me -- why hasn't anyone produced a distributed Lisp? How about Lisp Flavored Erlang?

How does Lisp Flavored Erlang talk to Common Lisp? Probably with a byte stream. The VMs are different.

I've noticed Erlang/Elixir also favor interior composition! Parsing is not idiomatic there -- they're actually BAD languages for parsing text. (Though they do have good affordances for parsing bytes)

They prefer to pass around Erlang terms, which are copied inside the VM.

I get that -- it's more convenient. But it's also a reason why "the rest of the world" has more code reuse -- e.g. Go talks to JavaScript talks to Python.

Most projects have multiple languages. Monoglot projects become polyglot projects when they grow bigger.

---

So I say

- Lisp prefers its own (interior) narrow waist

- Erlang prefers its own (interior) narrow waist -- even the Lisp one is second class!

- The rest of the world uses the (exterior) byte stream narrow waist, but they complain about it a lot :)

Re: Autoconf makes me think we stopped evolving too soon

#142

Post by lamontcg »

nindalf wrote: post #102
chubot wrote: post #55

Earlier quoted context omitted.

Shells have some of the absolutely bonkersly dumb parsers and interpreters Oils fixes all this, it's a from-scratch reimplementation of shell with an upgrade path from OSH (compatible) to YSH (new). --- aliases that can override keywords and change the parsing of shell script You can control this with shopt -u expand_aliases in bash, and YSH turns it off by default. Oils is statically parsed: How To Parse Shell Like…

I hope this can become the new standard shell. https://xkcd.com/927/

It wont. And stuff like Solaris and AIX still lives on and uses /bin/sh and has been incredibly slow to embrace even bash, and configure scripts still need to support them. Plus any change you make today won't be remotely universal until 10 years has passed.

And back in 2005-ish I thought for sure that we'd have standardized on perl as a replacement for bash scripting by now.

Re: Autoconf makes me think we stopped evolving too soon

#143

Post by lamontcg »

The problem is that a configure script takes a look at the system, right now, as configured by the end user, even with their home directory and whatever they've shoved into env variables like LD_LIBRARY_PATH and then builds the software.

At a minimum you need to have /etc, /usr/local/etc and ~/etc databases of "union mounted" layered configuration information, along with the ability to add and subtract arbitrary other locations where software might get installed. And it all needs to get updated with every new change to packages in those locations.

As someone else pointed out in a comment, this is sort of the very unrealized promise of pkg-config.

You can't do with just a static file/directory in /etc that defines the distro, that isn't even half the problem once you start installing stuff in /usr/local that you want to link against.

This is a pretty good example of a Chesterton's Fence. You have to first fully understand why the fence is there before you knock it down.

Re: Autoconf makes me think we stopped evolving too soon

#144

Post by chubot »

lamontcg wrote: post #142
nindalf wrote: post #102

Earlier quoted context omitted.

I hope this can become the new standard shell. https://xkcd.com/927/

It wont. And stuff like Solaris and AIX still lives on and uses /bin/sh and has been incredibly slow to embrace even bash, and configure scripts still need to support them. Plus any change you make today won't be remotely universal until 10 years has passed. And back in 2005-ish I thought for sure that we'd have standardized on perl as a replacement for bash scripting by now.

What's different about Oils is that it's compatible with both /bin/sh and bash.

https://www.oilshell.org/blog/2021/01/why-a-new-shell.html

https://www.oilshell.org/blog/2023/03/faq.html

OSH should be trivial to use on Solaris/AIX -- all you need is a C++ compiler and /bin/sh, no make tool even.

https://www.oilshell.org/blog/2023/12/screencasts.html#appen...

But if everyone on Linux and BSD uses bash/OSH, and Solaris AIX use /bin/sh, it will be a success. The latter platforms do not influence the rest of computing very much -- they lag behind.

---

The busybox shell and the FreeBSD shell have been gaining bash features lately -- which means they are gaining OSH features.

Because OSH is the most bash-compatible shell, by a mile. There's no other project like it.

---

I agree with the logic -- it is very hard to change languages.

It's like changing English to Esperanto. The inertia is incredible.

So you need to provide an upgrade path, and that's what Oils does. OSH is compatible, and YSH is a new design.

Re: Autoconf makes me think we stopped evolving too soon

#145

Post by db48x »

smackeyacky wrote: post #77
cpeterso wrote: post #53

Earlier quoted context omitted.

It always seemed to me that most of these differences and macros could be defined in a static header file that has a million #ifdefs for different OS and compiler versions. That seems simpler and more reliable, and usable for cross compiling, than running dynamic checks with autoconf.

Hmmm. Nope. The file would be near unusable and contain a pile of things you don’t care about where autoconf can cope with the one or two cases you are trying to manage. Despite the description above of the genesis of autoconf, at the time when there were dozens of nearly compatible unices, it was a key enabling technology for free software to be distributed and shouldn’t be discounted just because it’s a little hard…

It was absolutely a boon to all developers who used it. If you didn’t use it you were doing things the hard way. Just don’t look too hard at the implementation, because like I said M4 causes actual brain damage.

Re: Autoconf makes me think we stopped evolving too soon

#146

Post by chubot »

chubot wrote: post #136
drekipus wrote: post #72

Earlier quoted context omitted.

What benefit is this? I mean, I love the look of it, but how can it help me from day dot?

There are many answers, but one situation is 1. you already have a bash script (e.g. in your CI) 2. you want to use an array or dict Bash arrays and dicts have all sorts of warts. You have to remember to use "${array[@]}" (exactly like that - https://www.oilshell.org/blog/2016/11/06.html ) You can upgrade to YSH, and start using our Python/JS like arrays and dicts instead. And then you can write them to JSON and uplo…

Idioms - https://www.oilshell.org/release/latest/doc/idioms.html

Re: Autoconf makes me think we stopped evolving too soon

#147

Post by lamontcg »

chubot wrote: post #144
lamontcg wrote: post #142

Earlier quoted context omitted.

It wont. And stuff like Solaris and AIX still lives on and uses /bin/sh and has been incredibly slow to embrace even bash, and configure scripts still need to support them. Plus any change you make today won't be remotely universal until 10 years has passed. And back in 2005-ish I thought for sure that we'd have standardized on perl as a replacement for bash scripting by now.

What's different about Oils is that it's compatible with both /bin/sh and bash. https://www.oilshell.org/blog/2021/01/why-a-new-shell.html https://www.oilshell.org/blog/2023/03/faq.html OSH should be trivial to use on Solaris/AIX -- all you need is a C++ compiler and /bin/sh, no make tool even. https://www.oilshell.org/blog/2023/12/screencasts.html#appen... But if everyone on Linux and BSD uses bash/OSH, and Solaris…

Sure but the problem is that Solaris/AIX will be very slow to actually install it, so you can't count on it being there, and those distros DO influence things like autoconf and configure scripts. And people who run them pay big money contracts to get those distros supported (one bank contract for support is worth much more than 10,000 linux users who don't pay anyone a dime). The inertia is very real, bigger than you even think, and you can't wave it off by suggesting they don't influence computing.

At any rate, you need to actually accomplish everyone on Linux and BSD having that available and having used it for the past 10 years first. And get the core distros switching over to using it so that the glue code in the distro is all YSH plus probably python and some legacy sh. Actually show me that.

And yeah, I think the analogy of trying to change English to Esperanto is about right. I learned about Esperanto in the mid-80s...

Re: Autoconf makes me think we stopped evolving too soon

#148

Post by forrestthewoods »

lelanthran wrote: post #93
forrestthewoods wrote: post #17

Earlier quoted context omitted.

eww. “Try to compile and see if it fails” is awful. I have never and would never do that. That’s so gross.

Okay, what's the alternative when `accept` has three parameters when using glibc and two parameters when using musl?[1] How else do you determine which one to use other than by compiling against the chosen library and seeing what fails? [1] just an example, musl mighy actually have same amount of parameters as glibc for all I know. But newlib doesn't.

The build system should specify whether it wants glibc or musl and what version. Relying on current system state is one of the reasons that glibc is such a monumental pain in the ass. It should be trivial to target an arbitrary version of glibc. (zig build system achieves this).

The way C projects from the 90s work is you locally run .configure and it generates a whole bunch of headers, if not .c files, with a whole bunch of crap based on local system state. Then you run a build script. "The Right Thing" is for the repo files to contain a superset and for the build system pass the tiny handful of defines necessary to select the target platform. For example glibc, musl, PlayStation4, NintendoSwitch, etc.

It's very, very easy to do. musl does things right. glibc is the only bad citizen stuck in the 90s. The difference between the libc headers across the kajillion target platforms is exceedingly minimal.

Re: Autoconf makes me think we stopped evolving too soon

#149

Post by NoGravitas »

db48x wrote: post #28
thechao wrote: post #13

Earlier quoted context omitted.

I'm be written lots of C code that runs on lots of architectures & platforms: PDPs, x86, ARM; Windows, BSD, Linux, VMS. My projects have spanned them gamut from tiny to gargantuan (millions of lines of code). I've never needed autoconf... what's it even for !?

In decades past, if you were developing software for Unix you would inevitably run across compatibility problems. Even with the POSIX standard, every Unix was trying new things, inventing new things, or just implementing the same thing in slightly different ways. So your programs had to have a bunch of macros to switch between different variations. Some API would have two arguments on Unix A but three on Unix B, so y…

This comment should really be promoted to the top level and pinned. I wanted to write something similar, but if I had, it would have been less detailed than this.

Re: Autoconf makes me think we stopped evolving too soon

#150

Post by NoGravitas »

kazinator wrote: post #134

One of the worst things about Autoconf is the way it is deployed in the GNU Project's own programs. Typically, GNU project programs assume that anyone working on the program (cloning the repo, looking for bugs, making changes, ...) has the Autotools installed. Not just any Autotools but the exact version the program wants. Only the "release tarball" if a GNU program contains the generated ./configure script that can…

Everything you say is technically true, but I can't remember a time when just having the latest autotools from my distribution packages wasn't sufficient to build a GNU package.
Post reply on HN