Live data from Hacker News

The C3 Programming Language

c3-lang.org

231–240 of 270 posts

Re: The C3 Programming Language

#231
post #35

Just browsed the doc to get the answers to two burning questions, which I will dump here in case it saves some time to others: - uses LLVM (so: as portable as LLVM) - sadly, does not support tagged enums Apart from that it adds a few very desirable things, such as introspection and macros.

IMHO the downsides of tagged unions (e.g. what Rust confusingly calls "enums") are big enough that they should only be used rarely if at all in a systems programming language since they're shoehoerning a dynamic type system concept back into an otherwise statically typed language. A tagged union always needs at least as much memory as the biggest type, but even worse, they nudge the programmer towards 'any-types', wh…

Tagged enums != any type (i.e. runtime casting)

Tagged enums are everywhere. I am writing a micro kernel in C and how I wish I had tagged enums instead of writing the same boilerplate of

  enum foo_type {
    FOO_POINTER,
    FOO_INT,
    FOO_FLOAT,
  };

  struct foo {
    enum foo_type type;
    union {
      void *val_pointer;
      int val_int;
      float val_float;
    };
  };

Re: The C3 Programming Language

#232

It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still. I suppose it has less of the ability to blow your foot off and so isn't a very dangerous way to code, therefore not cool. If any of you younger folk haven't looked at it, I'd suggest having a look, there is Delphi - a cross…

Both Pascal and C (and their offspring) are wonderful gifts for us to receive from their designers, and I enjoy writing code in both.

> It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.

Here's Brian Kernighan's view on the shortcomings of Pascal resulting from a practical book project idea:

https://www.lysator.liu.se/c/bwk-on-pascal.html

Not sure to what extent the latest Oberon or Ada have addressed all of these, since I've not kept up with Ada news.

Re: The C3 Programming Language

#233

Earlier quoted context omitted.

>On purely recreational grounds, one can get something small off the ground in an afternoon with LLVM. It's very enjoyable and has a low barrier to entry, really. Is there something analogous for those wanting to create language interpreters, not compilers? And preferably for interpreters one wants to develop in Python? Doesn't have to literally just an afternoon, it could be even a few weeks, but something that will…

I am a big fan of Ragel[1]. That is a high performance parser generator. In fact, it can generate different types of parsers, very powerful. Unfortunately, it takes a lot of skill to operate. I wrote a parser generator generator to make it all smooth[2], but after 8 years I still can't call it effortless. A colleague of mine once "broke the internet" with a Ragel bug. So, think twice. Still, for weekend activities I…

The worst part of designing a language is the parsing stage.

Simple enough to do it by hand, but there’s a lot of boilerplate and bureaucracy involved that is painfully time-wasting unless you know exactly what syntax you are going for.

But if you adopt a parser-generator such as Flex/Bison you’ll find yourself learning and debugging and obtuse language that has to be forcefully bent to your needs, and I hope your knowledge of parsing theory is up-to-scratch when you’re facing with shift-reduce conflicts or have to decide whether LR or LALR(1) or whatever is most appropriate to your syntax.

Not even PEG is gonna come to your rescue.

Re: The C3 Programming Language

#234

Earlier quoted context omitted.

Which one specifically does ending a process not clean up the memory?

Any flat memory rtos. Not everything is *nix. For example microcontrollers or aerospace systems.

RTOSes I'm aware of call them tasks rather than processes, specifically because they don't provide the sort of isolation that a "proper" OS does.

Re: The C3 Programming Language

#235
post #232

It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still. I suppose it has less of the ability to blow your foot off and so isn't a very dangerous way to code, therefore not cool. If any of you younger folk haven't looked at it, I'd suggest having a look, there is Delphi - a cross…

Both Pascal and C (and their offspring) are wonderful gifts for us to receive from their designers, and I enjoy writing code in both. > It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still. Here's Brian Kernighan's view on the shortcomings of Pascal resulting from a practical b…

Isn't that interesting, I do vaguely recall this from many years ago. These complaints have mostly been addressed a long time ago, the solutions were mostly stolen from C where applicable, I refer to Delphi, but I think Lazarus is the same. These are the dot points from the summary:

- Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.

There's a TArray type now, it uses generics and can be declared if you like, also lots of other structured types - lists, stacks etc, though the original array type is still available for backwards compatibility. There was also an array of without size to pass as a parameter but TArray is mostly used now.

- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.

Statics are now a thing

- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.

This can be an issue still, though the one pass is why the compiler is fast.

- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.

Not an issue any more, it has packages and libraries

- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.

Not an issue any more it uses the C method

- The 'case' statement is emasculated because there is no default clause.

Does now, though a case with string alternatives still doesn't exist in Delphi, Lazarus has it.

- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.

Many different sorts of file access - random, binary etc

- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.

Not true any more, it has packages and include files (though limited), and the macro facility is very limited, nothing like C's but its not really needed, you can have inline functions for the performance boost macros would give you (stolen from C++)

- There is no escape.

This refers to the type system, you can use casts just like C now

Just as a counterpoint C still doesn't have a standard string type. Delphi has generics now like C++, and many of the things that are external libraries in C/C++ are just included. If you really need high performance then C is still better, but what I've done in the past is just rewrite bits in C, though the need for this is very infrequent. If you look at comparable things for Delphi in C++ like Qt's slots and signals for example, the Delphi solution is so much more elegant, and Qt is perhaps the only comparable commercial cross platform library to Delphi's Firemonkey. It's really worth a look, times have changed. There's a reason MS hired away Anders Hejlsberg to architect C# and then typescript.

Re: The C3 Programming Language

#236
post #231

Earlier quoted context omitted.

IMHO the downsides of tagged unions (e.g. what Rust confusingly calls "enums") are big enough that they should only be used rarely if at all in a systems programming language since they're shoehoerning a dynamic type system concept back into an otherwise statically typed language. A tagged union always needs at least as much memory as the biggest type, but even worse, they nudge the programmer towards 'any-types', wh…

Tagged enums != any type (i.e. runtime casting) Tagged enums are everywhere. I am writing a micro kernel in C and how I wish I had tagged enums instead of writing the same boilerplate of enum foo_type { FOO_POINTER, FOO_INT, FOO_FLOAT, }; struct foo { enum foo_type type; union { void *val_pointer; int val_int; float val_float; }; };

> ...runtime casting...

...what else is a select on a tagged union than 'runtime casting' though. You have a single 'sum type' which you don't know what concrete type it actually is at runtime until you look at the tag and 'cast' to the concrete type associated with the tag. The fact that some languages have syntax sugar for the selection doesn't make the runtime overhead magically disappear.

Re: The C3 Programming Language

#237

It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still. I suppose it has less of the ability to blow your foot off and so isn't a very dangerous way to code, therefore not cool. If any of you younger folk haven't looked at it, I'd suggest having a look, there is Delphi - a cross…

I would argue that Go is the closest spiritual descendant of Wirth's languages. If you changed braces into BEGIN/END and so on, it would look a ton like Oberon or Modula 2/3.

It adds features (goroutines, channels, slices), changes some (modules become packages), the generics are a little different, and it eschews some of Wirth's pragmatic type safety ideas (like range types). It even has ":=" for assignment.

The general spirt is the same, I think: Small language, simple compiler (compared to many other languages), "dumb" type system, GC, engineering-focused rather than-type theory-focused.

Re: The C3 Programming Language

#238

Earlier quoted context omitted.

Check it out on the comparisons page: https://c3-lang.org/faq/compare-languages/#d I think they're aware of and like D :)

It was very nice of the C3 crowd to write that comparison. Thanks for pointing it out to me! I agree that D has gotten a bit complex. We're introducing the notion of "editions" in order dispose of obsolete and unnecessary features.

What old features would you like to dispose of in a modern redesign of D? What would this new edition look like?

Re: The C3 Programming Language

#239
post #116

Earlier quoted context omitted.

Zig feels too much in flux, has some incredible ideas, but I really don't like it syntactically wise, and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors which I believe it's the worst thing to ever have been invented and drives me up the wall. Documentation was still pretty bad last I checked, and that's the bare minimum before I can seriously adopt a new language. C3 feel…

> and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors FWIW, they also have a goal to emit as much output as possible, even in the face of compilation errors. They have stated that even syntax errors should have the compiler exit with a non-zero exit code, but still produce an executable that will give you a syntax error at runtime. The point of this being to allow you to it…

The Eclipse Java Compiler is similar to this, and Haskell can defer type errors to runtime. You wouldn't make production builds that way, but it's otherwise a perfectly valid mode for a compiler to operate in.

Re: The C3 Programming Language

#240
post #230

Earlier quoted context omitted.

virtual memory requires pages and this sucker doesn’t have them. Only a heap that you can use with heap_x.c Everything is manual. I get you people are trying to be cheeky and point out all modern OS’s don’t have this problem but C runs on a crap ton of other systems. Some of these “OS” are really nothing more than a coroutine from pid 0. I have 30 years experience in this field.

Yeah I think I get your problem. I am prototyping a message-passing actor platform running in a flat address space, and virtual memory is the only way I can do cleanup after a process ends (by keeping track of which pages were allocated to a process and freeing them when it terminates) Without virtual memory, I would either need to force the use of a garbage collector (which is an interesting challenge in itself to d…

Not anything I can share. I’m trying to modernize these systems but man oh man was the early 80s tech brutal. Rust is something we looked into heavily and are trying to champion but bureaucracy prevents us. Flight Sims have to integrate with it in order to read/write data and it’s 1000x worse than SimConnect from MSFS.

The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.

Post reply on HN