The Blow programming language

The developer of Braid has streamed two talks so far (with more to come) on his pain points in language design. He's uploaded the recordings here:

https://www.youtube.com/watch?v=TH9VCN6UkyQ
https://www.youtube.com/watch?v=5Nc68IdNKdg

It seems to me that what he actually wants is more or less Rust, but he doesn't realize it because he's hung up on design decisions that strike him as opinionated, when really they're the natural outcome of the overall design constraints ("no GC, no run-time type checking if we can help it," and so on) or represent planned features that merely have yet to be implemented. Then again, the D community is saying something similar, and I don't know D as well as Rust so I'm not sure what to think.

/jewtube/

Talks and videos suck. Won't waste my time on anything but text.

>>3
I'm sure there's a transcript somewhere of his specific complaints. But off the top of my head, without rewatching the entire thing:

- The C-style header + preprocessor model needs to die (I think all of us can agree with this)
- Inheritance hierarchies are snake oil, and maybe method syntax is bad too (he's not sure)
- RAII is no substitute for having decent memory management techniques baked into the language, but GC is the wrong solution. A better plan would be to have owned vs. weak/borrowed pointers, and only the current owner decides whether a pointer gets freed
- Nullability should be reined in, but this has to be done using a special language feature like in C#, not a general purpose data structure feature like the Maybe type in Haskell (because of his syntax gripes below)
- Generally, memory should not be regarded as a general purpose "resource" like a file handle, because (e.g.) your program is guaranteed to allocate memory somehow, but might not open files or whatever
- Memory safety is a tooling problem, not a compiler problem, so the language only needs just enough safety features to enable better tooling
- Syntax should aid as much as possible in refactoring, meaning that any change by the programmer which has a small impact on the behavior of the code should also have a small impact on what the syntax looks like
- Type syntax, for example, should be very up-front about what kind of data a var actually contains, and use small sigils in consistent ways to indicate that a var is any of the different types of pointers, an array, refcounted, nullable, etc.
- Declaration syntax should be more regular: foo : int to declare a var with its type, foo = 5 to perform assignments, and foo : int = 5 (or foo := 5 if you have type inference) to declare and initialize in the same statement
- Function, lambda, and local scope block syntax should be unified as much as possible, so that you can quickly rewrite one to another just by adding an argument list or whatever
- C++-style closure capture whitelists should be available on all of the above, even regular scope blocks and top-level functions, for fine-grained control over exactly how "pure" a block of code is (ie. what outside state it reads or modifies)

He also ranted a bit about stuff like public/private modifiers, which I guess means he wants the language not to assume you're writing a library, because who writes those anyway?

>>4

- The C-style header + preprocessor model needs to die (I think all of us can agree with this)

No, it works perfectly. Go back to your modules, Javashit kid.

foo : int = 5

on what fucked up world is this supposed to be a good thing

>>4

The C-style header + preprocessor model needs to die (I think all of us can agree with this)

You obviously have no idea what a linker does.

Yeesh. He wants Rust, he just doesn't understand Rust. It's cute how he says he's not trying to anger the Rust crowd, then goes on to describe Rust.

The thing about memory safety is stupid: he really just wants opt-in safety, but he has to phrase it like someone else is wrong about something. Opt-in safety just doesn't exist in a meaningful way and probably never will.

>>6
Pascal tried that, look where it went.

Memory safety is a tooling problem, not a compiler problem

Memory safety is a programmer problem, not a computer problem.

>>9

Memory safety is a programmer problem, not a computer problem.

gonna need some wasabi over here

>>9
>2014
>Pascal

Go back to /g/, hipster faggot.

>>6,9
How the FUCK do you consider name : type = value to be stranger than C's star's here, base type and name here, array brackets here, and we can all be arbitrarily nested such that you literally need to apply something called ``the spiral rule'' to read type declarations = value;

>>12
I only apply the spiral rule figuratively.

>>12
The spiral rule is wrong, see what Linus says:
https://plus.google.com/111049168280159033135/posts/1ZhdNwbjcYF

And I suppose you find maths hard too? Reading declarations is like reading expressions. Just as like anyone older than 12 who has a brain knows ( ) is read before * and / and before + and - , every C programmer knows [ ] and ( ) are read before *.

>>14
The English language is pretty fucked up too, yet most of us learned to be fluent in it. That doesn't mean that complaints about how arbitrary its spelling and grammar rules are aren't valid.

There's a difference between things that are simple because they are simple, and things that you think are simple because you already know them.

>>4

- RAII is no substitute for having decent memory management techniques baked into the language, but GC is the wrong solution. A better plan would be to have owned vs. weak/borrowed pointers, and only the current owner decides whether a pointer gets freed

The best solution is the compile-time GC but it's too hard for these hipsters.

>>12
I agree with him.

foo : int
foo = 5

is much better.

For one thing, it allows

foo, bar, baz : OneType

For another, it allows the code editor to cleanly hide and show type declarations. E.g.

foo : [Char] -> [[Char]]
foo = words >>> reverse

bar : [Char] -> Int
bar = length >>> (*(-1))

can be displayed as

foo = words >>> reverse

bar = length >>> (*(-1))

You can hide/show typedecls without lines squeezing and swelling weirdly.

For one thing, it allows
foo, bar, baz : OneType

OneType foo, bar, baz;

>>12
Yeah, even Ritchie considered C's type declaration syntax to be fucked up.
In some interview with the question "knowing what you know know, would you go back and change something if you could redesign C again?" he mentioned the declaration syntax is one of those things.

>>19
Type-name-first is NOT the problem with C syntax. The problem is everything after that, the crazy way array/pointer/function types are spelled, and the way those interact with each other giving you some blue nonsense you can't read. Type-name-first is consistent with how keywords work, a keyword and then what the keyword operates on, divided by a space. Because it is consistent, it is more natural, and it was always the right way to do it.

>>16

I don't understand how compile-time GC is even possible. Isn't determining run-time reachability at compile-time equivalent in difficulty to the halting problem?

>>17
fuck off haskell fagstorm

>>11
I hope you're being ironic, nigger. Fuck off with your > memes.

>>21

Isn't determining run-time reachability at compile-time equivalent in difficulty to the halting problem?

In the general case, yes, that's probably true. In practice, escape analysis techniques will cover the vast majority of what a programmer wants to write, and for the rest, you can use either manual annotations (like Rust's lifetimes) or fall back on runtime memory management. The only "new thing" about Rust is that all this infrastructure is exposed to the programmer, instead of just being an implementation detail that happens behind the scenes (which is how Java does it).

>>18
Then how would data constructors look like?

foo, bar, baz : Type

is better because it is not visually confusable with data construction.

>>25

data constructors

They're called templates, and you don't need them in a serious language.

>>26
SML is not a serious language? Nigger, please.