[TUHS] Any UNIX With No C In Userland?

segaloco via TUHS tuhs at tuhs.org
Mon Mar 3 03:54:01 AEST 2025


On Sunday, March 2nd, 2025 at 9:29 AM, Bakul Shah via TUHS <tuhs at tuhs.org> wrote:

> On Mar 1, 2025, at 7:16 PM, Larry McVoy lm at mcvoy.com wrote:
> 
> > > Anyway, my main point was that please do something innovative and
> > > interesting if you must use a new HLL for an OS!
> > 
> > So little-lang wasn't for OS stuff, it was for userland, but I feel it was
> > plenty innovative. It fit into C syntax but added a bunch of useful stuff.
> > string type that managed the memory in the language, no more malloc/free
> > crap. Case statements that could take variables, regexp as switches.
> > Perl like I/O with regex built in. It was just a pile of pleasant
> > enhancements to C.
> 
> 
> My comment was about innovation in the OS, not about any HLL.
> 
> > And it could be an OS language, I don't see why not.
> 
> 
> Sure.
> 
> > If I had enough money, I'd fund a gcc --lang=Little syntax and the world
> > would be a better place. In. My. Opinion. Not everyone elses but I
> > really believe if gcc had that dialect a lot of C people would move to it.
> > 
> > I'm not pushing my pet language, I'm holding it up as an example of how
> > you could make a new programming language. Take what works, extend it
> > with what works. Preserve people's knowledge rather than force them to
> > learn a new syntax that does the same thing. Extend rather than replace.
> 
> 
> C's Achilles' heel is its type system. No extension can paper over
> that. Once you fix that it is no longer C. Newer languages can in
> fact be seen as fixing/adding things like proper strings, default
> read/write rules, memory allocation rules, modules/packages,
> object/closures, etc. over C. This is why I said they are not
> particularly outstanding. A lot of it seems rather adhoc.

For me though that speaks to the fact that C leaves a lot to the imagination.  You've got the building blocks of a number of higher level concepts, but implementation thereof is left to the user.  Of course you have these various extensions pop up, but the base language does not define the "one true way" to do it, rather, each case can be engineered with context in mind.

I personally wouldn't see a one size fits all "upgrade" of the language gaining steam in this regard, partially because it wouldn't need to.  C is great at what it is for, keeping it simple ensures a solid foundation on which more complex systems can be built without painting any given concern into a corner.  But you know what they say, with great power comes great responsibility.  If folks don't need that power or don't want that responsibility, there are a glut of other languages, both general and focused, for whatever need they may have that C cannot meet.

To spin another quote ask not what your language of choice can do for you, ask what you can do for your language of choice.  In other words, the growth of new features in a language doesn't always need to be an addition to the specification, it instead can be novel use that is then shared with others to the benefit of all that language's adherents.

- Matt G.


More information about the TUHS mailing list