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

The C3 Programming Language

c3-lang.org

Post reply on HN
Print view View original

91–100 of 270 posts

Re: The C3 Programming Language

#91

Post by gku »

cloud-oak wrote: post #80
cwillu wrote: post #73

Earlier quoted context omitted.

“However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated” This implies that a compiler would be permitted to remove precisely that actual code that checks the condition in non-safe mode. Seems like a deliberately introduced footgun.

My understanding of this was that the UB starts only after the value is passed/returned. So if foo() has a contract to only return positive integers, the code within foo can check and ensure this, but if the calling code does it, the compiler might optimize it away.

Unspecified behavior != UB https://en.wikipedia.org/wiki/Unspecified_behavior

Re: The C3 Programming Language

#92

Post by all2 »

riazrizvi wrote: post #62
epage wrote: post #24

I think the switch statement design is a foot gun: defaults to fall-through when empty and break when there is a body. https://c3-lang.org/language-overview/examples/#enum-and-swi...

If I aimed and shot a gun at my foot and a bullet didn’t go through it, I would trash the gun.

To be fair, I would probably toss the gun away if a bullet went through my foot.

Re: The C3 Programming Language

#93

Post by loeg »

fwip wrote: post #48
loeg wrote: post #42

They named Result (or Expected) Optional ? No, no, "optional" means "T or empty." Not "T or E." https://c3-lang.org/language-fundamentals/functions/#functio...

I share your distaste for arbitrarily renaming concepts. However, I think if you only have one of the two in the language, Optional is the clearer name. A result is already the informal name of the outcome or return value of every regular operation or function call, whereas an Optional is clearly not a regular thing. I also think, from a pragmatic systems-design point of view, it might make sense to only support the…

It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing.

(I don't really object to the idea of skipping a real Optional type in a language in favor of just Result.)

Re: The C3 Programming Language

#96

Post by card_zero »

ibuildbots wrote: post #81
edvinbesic wrote: post #23

Earlier quoted context omitted.

You catch more flies with honey than with vinegar

why would I want to attract bugs? Vinegar keeps them away from me

It isn't even true.

https://xkcd.com/357/

"Head over heels" is another weird idiom. I'm so in love, I'm standing in a normal orientation.

Re: The C3 Programming Language

#97

Post by bluecalm »

Fraterkes wrote: post #52

Dumb question about contracts: I was reading the docs ( https://c3-lang.org/language-common/contracts/ ) and this jumped out "Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all. However, violating either pre- or post-conditions is unspecified behav…

I think they are there to help the compiler so the optimizer might (but doesn't have to) assume they are true. It's sometimes very useful to be able to do so. For example if you know that two numbers are always different or that some value is always less than x. In standard C it's impossible to do but major compilers have a way to express it as extensions. GCC for example has:

  if (x)
    __builtin_unreachable();
C3 makes it a language construct. If you want runtime checks for safety you can use assert. The compiler turns those into asserts in safe/debug mode because that help catching bugs in non performance critical builds.

Re: The C3 Programming Language

#98

Post by ajuc »

tialaramex wrote: post #90
Fraterkes wrote: post #52

Dumb question about contracts: I was reading the docs ( https://c3-lang.org/language-common/contracts/ ) and this jumped out "Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all. However, violating either pre- or post-conditions is unspecified behav…

Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…

So the compiler could have debug mode where it checks the invariants and release mode where it assumes they are true and optimizes around that without checking?

Re: The C3 Programming Language

#99

Post by yencabulator »

all2 wrote: post #89
yencabulator wrote: post #14

Earlier quoted context omitted.

You can throw Claude at a completely private Rust code base with very specific niche requirements and conventions that are not otherwise common in Rust and it will demonstrate a remarkably strong ability to explain it and program according to the local idioms. I think your statement is based on liking a popular language, not on evidence..

I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.

I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.

But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.

Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".

Re: The C3 Programming Language

#100

Post by HarHarVeryFunny »

zephen wrote: post #88
HarHarVeryFunny wrote: post #66

Earlier quoted context omitted.

Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy. It also helps code readability to know that a::b is referring to a namespace, without having to go lookup the definition of "a", while a.b is a variable access.

> Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy. That's a perspective. Are we talking about the 'bar' that comes from 'foo' or are we talking about the 'bar' that comes from 'baz'? But another perspective is that 'foo' is important and provides several facilitie…

Right - I just wanted to point out that not everyone is going to conceptualize namespaces and members, the same as structs and members, as both being about "hierarchy".

I'm generally of the camp that code is written once, read many times, and that anything that adds to readability is therefore a win.

Post reply on HN