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

Learning C3

alloc.dev

Post reply on HN
Print view View original

61–70 of 163 posts

Re: Learning C3

#61

Post by joshring2 »

90s_dev wrote: post #3
Defletter wrote: post #2

C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-check everything, or YOLO it, I would just write Java... and even Java is seeking to fix this: https://openjdk.org/jeps/8303099

I'm on the fence about function contracts like this. I've seen them for a decade in other languages, but never really used them, so I can't say how I feel about them. But having them be inside comments is just weird.

It is different yes, having read a good amount of it by now I find it work's pretty well in practice. It means you can incrementally adopt them if you like and code with or without them looks quite similar assuming you documented your code, the function signatures look the same as well which I appreciate.

Re: Learning C3

#62

Post by rdtsc »

sgt wrote: post #52
rdtsc wrote: post #34

Interestingly there is also C2: http://c2lang.org

There's also C4, but that's either an explosive or a notation language for modeling software architecture.

Hopefully the notation language folks take full advantage of puns associated with explosives.

Re: Learning C3

#63

Post by orthoxerox »

sitkack wrote: post #39
plainOldText wrote: post #37

Earlier quoted context omitted.

Indeed. There’s a port for macOS though. And yet out all these newer C-like languages, it looks like Hare probably takes the crown for simplicity. Among other things, Hare uses QBE[1] as a backend compiler, which is about 10% the complexity of LLVM. [1] https://c9x.me/compile/

QBE is an art project. Read the source.

I tried. It's not at Arthur Whitney's levels of terseness, but compared to the source of, say, Redis it's a pain to read.

Re: Learning C3

#64

Post by pjmlp »

jack_pp wrote: post #54
throwawaymaths wrote: post #44

Earlier quoted context omitted.

the problem with picking C++ is that eventually you onboard someone who uses the warts in their code, and then the warts become like craft glitter.

Maybe instead of building a restricted C++ we should be building parsers that restrict what C++ features we use.

It is called static analysis tool.

Re: Learning C3

#65

Post by munificent »

90s_dev wrote: post #4

> Don't misunderstand me - I love using foreach in other languages; the added syntax better expresses your intent, reducing logic errors. It did jump out at me as "this isn't C" though. Because it's not. The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself. C++ hides logic in abstractions for the sake of convenience. This is a C++ thing. How does it know how to it…

> The whole point of C is that you know exactly what's going on and it's relatively clear in the code itself.

Given the widespread undefined behavior and the ways that compilers aggressively rely on that to reorganize and optimize your code, that hasn't been the case for many many years.

Sure, if you're using dmr's compiler on a PDP-11, then C is a pretty transparent layer over assembly, which is itself a fairly thin layer over the CPU. But today, C is an ambiguous high level communication language for a highly optimizing compiler which in turn produces output consumed by deep pipeline CPUs that freely reschedule the generated instructions.

Re: Learning C3

#66

Post by pjmlp »

throwawaymaths wrote: post #44
SuperV1234 wrote: post #41

Most of these features have been used by countless C++ developers for the past decades -- I really don't see the point in adopting a language that's mostly C++ but without some of the warts. Either pick C++ or something like Rust.

the problem with picking C++ is that eventually you onboard someone who uses the warts in their code, and then the warts become like craft glitter.

A matter of code review and static analysis configuration.

Unfortunately adhering to modern tooling is always a quixotic battle, even when they come for free on modern FOSS compilers.

Re: Learning C3

#67

Post by wavemode »

aidenn0 wrote: post #32
lerno wrote: post #6

Earlier quoted context omitted.

It's an interesting problem. Originally I experimented with both having ` ` and `&` syntax, so `int&` being a ref (non null) and `int ` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as we…

> Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. I don't see that as a problem; don't separate declaration from assignment and it will never be unassigned. Then a ZII non-null pointer is always…

> don't separate declaration from assignment and it will never be unassigned

That's tricky when you want to write algorithms where you can start with an uninitialized object and are guaranteed to have initialized the object by the time the algorithm completes. (Simplest example - create an array B which contains the elements of array A in reverse order.)

You can either allow declaring B uninitialized (which can be a safety hazard) or force B to be given initial values for every element (which can be a big waste of time for large arrays).

Re: Learning C3

#68

Post by lerno »

lerno wrote: post #6
Defletter wrote: post #2

C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-check everything, or YOLO it, I would just write Java... and even Java is seeking to fix this: https://openjdk.org/jeps/8303099

It's an interesting problem. Originally I experimented with both having ` ` and `&` syntax, so `int&` being a ref (non null) and `int ` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as we…

I'm unable to edit this now... that should teach me not to comment and then go to kendo practice... It should say '*' and '&' and 'int&' and 'int*'

Re: Learning C3

#69

Post by lerno »

aidenn0 wrote: post #32
lerno wrote: post #6

Earlier quoted context omitted.

It's an interesting problem. Originally I experimented with both having ` ` and `&` syntax, so `int&` being a ref (non null) and `int ` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as we…

> Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as well. What you end up with is some period of time where a value is quasi valid - since non-null types need to be assigned and it's in a broken state before it's initially assigned. I don't see that as a problem; don't separate declaration from assignment and it will never be unassigned. Then a ZII non-null pointer is always…

I don't quite see what you mean. As an example, let's say you use ZII and allocate 100 objects in a single allocation. These are now zero initialized and so either invalid (which should not happen) or do not hold non-null types. Can you explain how you intend this scenario to be resolved in your case?

Otherwise it's quite straightforward that they have an uninitialized state (zero) and are then wired up when used. Trying to prevent null pointers here is something that the program to do. However, making the compiler guarantee without requiring constructors it is a challenge I don't know how to tackle.

Re: Learning C3

#70

Post by lerno »

bryanlarsen wrote: post #35
lerno wrote: post #6

Earlier quoted context omitted.

It's an interesting problem. Originally I experimented with both having ` ` and `&` syntax, so `int&` being a ref (non null) and `int ` being a pointer. The thing you notice then are two things: 1. You want almost all pointer parameters non null. 2. Non-null variables is very hard to fit in a language without constructors. Approaches to avoid constructors/destructors such as ZII play very poorly with ref values as we…

the hacker news markdown parser seems to have swallowed your asterisks, which are essential to understanding your comment.

Yes, and I was too slow to getting back and trying to edit it. Sorry about that.
Post reply on HN