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

Algebraic Data Types for C99

github.com

Post reply on HN
Print view View original

211–220 of 233 posts

Re: Algebraic Data Types for C99

#211

Post by packetlost »

mst wrote: post #203
packetlost wrote: post #163

Earlier quoted context omitted.

That's because Go is intentionally clunky and awkward in the name of "simplicity". IMO it's charming to some degree, but it's far from perfect and I think you'd need some pretty serious threats to get me to describe it as "elegant" in any way. Rust somehow has more elegance than Go, if only in small parts. Nothing compares to Scheme in the elegance category IMO :)

My view of Go went from being annoyed to "they picked their tradeoffs carefully and consciously and then leaned into them hard to squeeze every ounce of upside out of them" and while it's still not really my preferred aesthetic I now have a lot of respect for the design as a design process. Meanwhile, getting addicted to scheme many years ago is a lot of why I still mostly write perl, I need 'my' (i.e. expression/blo…

Despite what I may have made it seem, I actually quite like Go as a language, I just wouldn't call it elegant or pretty (though certainly not as ugly as some other languages out there), but it's very pragmatic.

It's been a long time since I've written any Perl, but I can say I don't care for it as much as I do Lisps in general.

Re: Algebraic Data Types for C99

#212

Post by Koshkin »

samatman wrote: post #32

Let's say you have a C program to write, and you really want exhaustive pattern matching on the tags of unions (which is what Datatype99 provides: "Put simply, Datatype99 is just a syntax sugar over tagged unions"). Let's say further that you already know Rust exists, and aren't going to use it for reasons that anyone writing a C program already knows. At least consider Zig. Here's a little something I wrote in Zig t…

> At least consider Zig.

Considered the example given. Now my eyes hurt. I think I started appreciating Lisp more.

Re: Algebraic Data Types for C99

#213

Post by eru »

tombert wrote: post #5

Interesting. Algebraic Data Types are almost always one of the things I miss when I use imperative languages. I have to do Java at work, and while I've kind of come around on Java and I don't think it's quite as bad as I have accused it of being, there's been several dozen instances of "man I wish Java had F#'s discriminated unions". Obviously I'm aware that you can spoof it with a variety of techniques, and often en…

> Algebraic Data Types are almost always one of the things I miss when I use imperative languages.

Algebraic data types and pattern matching actually work really well in imperative languages, too. See eg Rust.

Re: Algebraic Data Types for C99

#214

Post by eru »

packetlost wrote: post #163
acchow wrote: post #157

Earlier quoted context omitted.

I’m in the latter camp (from Ocaml) and now using Go. Go feels clunky and awkward.

That's because Go is intentionally clunky and awkward in the name of "simplicity". IMO it's charming to some degree, but it's far from perfect and I think you'd need some pretty serious threats to get me to describe it as "elegant" in any way. Rust somehow has more elegance than Go, if only in small parts. Nothing compares to Scheme in the elegance category IMO :)

Scheme (and by Scheme, I mean Racket, I guess) is nice, but it's not particularly elegant compared to eg Haskell.

Re: Algebraic Data Types for C99

#215

Post by eru »

estebank wrote: post #45
im3w1l wrote: post #39

Earlier quoted context omitted.

I have mainly used them in Rust. They are nice I suppose, but nothing mindblowing. To me it feels very similar to an interface (trait) implemented by a bunch of classes (structs). I have multiple times wondered which of those two approaches would be better in a given situation, often wanting some aspects of both. Being able to exhaustively pattern match is nice. But being able to define my classes in different places…

Enums are closed sets and trait objects are open sets. They are conceptually related concepts, but the language puts syntactic distance between the two, and I don't think it should. There are lots of open design questions for every feature you propose, but all of them have been discussed and have higher or lower chance of making it into the language.

> They are conceptually related concepts, but the language puts syntactic distance between the two, and I don't think it should.

Haskell's type classes are a bit like Rust's traits. Type classes are open by default, but optionally can be closed off.

Re: Algebraic Data Types for C99

#216

Post by [deleted] »

ajross wrote: post #158
bunderbunder wrote: post #131

Earlier quoted context omitted.

You've got to distinguish syntax from semantics, though. I agree, it's easy to turn a big semantic win into a net readability loss if you choose to represent it with an overly terse syntax that promotes code golf.

Compilers are really smart. It's easy enough in the modern world to demand that a "type" field be checked against all enumerants, preserving the "semantic win". A plain old C switch statement with gcc -Wall will do this today, in fact.

[deleted]

Re: Algebraic Data Types for C99

#217

Post by taeric »

naasking wrote: post #182
taeric wrote: post #177

Earlier quoted context omitted.

No. You are confusing the model for the reality. Again, our model may lead to a more impressive reality, but ball players are not doing trig. They are almost certainly simulating things, but that does not require trig. Indeed, it only loosely requires math. Models can be very informal with loose approximations. You seem to think I have to prove your model false to show others don't do that. But I am specifically not…

The ability to build lists requires reasoning. It requires enumeration, inclusion/exclusion conditions, and stop conditions, which necessarily requires logic. This argument is pointless, you go on believing that some people can't use basic logical connectives, I'm sure next you'll say they can't even count.

By that reasoning, though, we can claim that the earth counts to 364 as it orbits the sun. Or that women's bodies count roughly to 9 as they make a baby. These are ways that we model those things, but that is not what is happening.

Most people learn to build lists through mimicry. They literally mimic the lists they were taught they need to build to go to the store. With enough experience, many of us learn to build our own lists from other principals, but it almost all starts with mimicry and simulation. Is why "going shopping" is such a fun game for kids. They are learning.

None of which is to say that you can't make your thinking better with logic. You almost certainly can. But you are begging the question with your examples and explanations. Heavily.

Re: Algebraic Data Types for C99

#218

Post by Tainnor »

tombert wrote: post #146
cess11 wrote: post #142

Earlier quoted context omitted.

Absolutely, so you try to seal it in hermetically, only talk to it over a special message bus or something. Sometimes the upgrade path from 6 onwards isn't as nice as it usually is from 8 up, especially if you built with some old undead libraries that require an heroic effort to understand well enough to reimplement. Takes a very special organisation to divert some person-years to pull it off, and as some middle or o…

It makes me sad, but I totally understand why someone would stay with Java 6, for the same reason that there's still COBOL stuff hanging around: the stuff "works" as is, upgrading is expensive, and some business person decided that the cost of the upgrade isn't worth it for the value they'd receive. I do worry that there's "Y2K-esque" bugs hiding in Java 6 programs somewhere. I don't think java.util.date uses 32 bit…

Cryptography is kind of an issue . Certain protocols that by now are expected aren't supported by Java 6.

Re: Algebraic Data Types for C99

#219

Post by samatman »

keybored wrote: post #187
samatman wrote: post #140

Earlier quoted context omitted.

I've been a Nim respecter for many years, it's slept on in general as a language. The difference here is that Nim compiles to C and you can turn the garbage collector off: Zig compiles C and there's no garbage collector. That means the entire standard library is available when generating object code. It's also trivial to opt-in to the C ABI on a fine-grained basis, by defining a function or struct with the extern key…

Let's say further that you already know Zig exists, and aren't going to use it for reasons that anyone writing a C/Rust/D/C++ program already knows. At least give Nim a try.

The difference here is that there aren't C programmers who don't know about Rust, and since they're writing C, they have reasons they aren't using it. The same is not true of Zig. Some of the reasons not to be using Rust may be applicable (no specification comes to mind), others may not be.

I do agree that, on an even playing field, Nim should be considered when any of Rust, D, C++, or Go, are on the table. This is less true of C, and therefore, Zig. There's a difference between something being possible, and something being easy and pleasant.

There are also people using C, who really should be using some other language. Which is, in that case, probably not Zig. When you understand that C is the rational choice for some sorts of programming, you'll understand why Zig is a contender, in a way that the other languages we're discussing are not.

Re: Algebraic Data Types for C99

#220

Post by keybored »

ajross wrote: post #75
different_base wrote: post #3

One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.

> [Algebraic Data Types are] such a basic mental model of how humans think and solve problems I think that's actually wrong for "Sum types". Product types, sure. The idea of storing a bunch of fields in a single thing matches the way we've been organizing information since we started writing things down. But I genuinely don't think I've seen an attempt at a sum/union/enumerant/whatever syntax in a programming languag…

> But I genuinely don't think I've seen an attempt at a sum/union/enumerant/whatever syntax in a programming language that wasn't horrifyingly confusing.

Syntaxes like: `A | B(Int) | C(String)`. That means A, B, or C.

> Where by extension: class-based inheritance is actually pretty simple to understand. The classic "IS-A" relationship isn't as simple as "fields in a struct", but it's not hard to understand

This value is either `A`, an Int (`B(Int)`) or a String (`C(String)`). Or: this knapsack either contains an A, B, or C. Difficult?

> (c.f. all the animal analogies),

Reminds me of the fact that software isn’t typically as static as animal taxonomies.

> and the syntax for expressing it is pretty clean in most languages.

I’m most used to Java where you spread `extends` over N files. (Sealed classes in Java is an exception.)

It’s fine. I don’t understand how it is particularly clean.

> Is it the "best" way to solve a problem? Maybe not. Neither are ADT sum types.

Is this an argument? ’Cause I don’t see it.

> But I think there's a major baby-in-the-bathwater problem

Inheritance is something that needs to have some concrete implementation affordance. Baby in the bathwater? I don’t see how you bolt this onto the struct model in a way that gets out of the way for people who don’t want to use it (the zero-cost-abstraction (in the if you don’t use it sense) is important to some low-level languages).[1]

Maybe the designers of hypothetical language X thinks that algebraic data types is enough. What baby are you missing then?

[1] For algebraic data types: structs are straightforward enough. While the “sum type” can be implemented by leaving enough space for the largest variant. That one-size-fits-all strategy isn’t perfect for all use-cases but it seems to have been good enough for Rust which has a lot, a lot of design discussions over minutiae.

> trying to be different.

With a technology from the ’70s. I also saw your “one oddball new idea is a revolution” snark. You’re clearly being very honest.

Post reply on HN