Martin Sústrik

Coroutines. What a lovely concept! It's a joy to watch all the CppCon videos about C++ coroutines, primarily by Microsoft folks. "Negative-cost abstraction" is such a nice hook phrase.

Friends at Meta mentioned to me a couple years ago that they started using c++ coroutines, which ended up being a big mistake because they had to face compiler implementation bugs, which must have been nasty to track down. At Google, we are eagerly waiting for the brilliant folks that are working on properly integrating them in google3/ to tell us when the time has come to use them.

This article uses Duff's device [1] to motivate structured gotos via macros as an implementation strategy for C coroutines. Duff wanted to loop-unroll this:

do { *to = *from++; } while (--count > 0); which he did in this way (shortened for brevity) :

int n = (count + 3) / 4; switch (count % 4) { case 0: do { *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; } while (--n > 0); } That is to say, he realized that he could use `case` statements (almost) anywhere in a `switch` block. The connection with coroutines is simple: One can wrap the whole function body with a switch statement, use a static variable for holding the location of the latest coroutine return, and label all co-returns with a `case` statement:

#define coBegin static int state = 0; switch (state) { case 0: #define coReturn(x) do { state…

> How is the current "notion of IP for software" not sustainable?

The only reason the "notion of IP for software" is a thing is that our intuitive notions of ownership don't quite work. We can't sell software without sources because nobody wants to allow a stranger to run arbitrary code on their computers. We can't sell software with sources because it's too easy to copy. We can't give away software with sources for free because people gotta eat.

So IP is a hack that slips into a gap just because there’s nothing better. But it's not a great hack.
https://250bpm.com/blog:82 makes a compelling argument that licenses exist only to help CYA companies consume software without risk. All of the software on my computer is owned by others, and yet nobody bears any liability for security holes. It's hard to discuss licenses, because "IANAL". But any time spent looking into licenses quickly uncovers stuff that's only there because nobody has tried to fight it in court yet. Licenses apply to a single snapshot of code, but software has a life cycle and needs a supply chain and governance structure (https://monetize.substack.com/p/a-holistic-vision-of-open-source)

> how is setting up a situation that seems to be asking for a tragedy of the commons more sustainable?

I think a lot about the tragedy of the commons (https://news.ycombinator.com/item?id=4359257#4361596), but it's not clear to me how people putting things made of bits in a digital commons that anybody can use creates any…

Funny you ask that, because I am making a programming language!

(1) Structured concurrency, best explained at [1], [2], [3], and [4]. More on this later.

(2) Extensibility. Most people think that this means macros. It doesn't. However it's done, as curryst said, languages are not perfect, and extending a language is important. See "Growing a Language" by Guy Steele, Jr. [5] More on this later.

(3) Like many other posts, having real-world units like feet, meters, pounds, kilograms, etc., for calculations and type checking, but the default number type should also be a BigRational.

(4) Ranged types, like Ada, allowing programmers to explicitly limit the range a type can be, eliminating errors. For example, a type that is used in the denominator of a division could be restricted to being not zero, and you don't need to worry about divide-by-zero for those divisions.

(5) Consistency, a massively underrated feature. The use of something in the language should be the same everywhere. This simplifies learning and makes it easier to understand features you haven't seen yet.

(6) Design-by-Contract and other formal methods "in the small". It should be possible to use formal methods on little pieces of code. Even if you can't go so far as to prove them correct, it should be easy to increase your confidence that they are.

(7) Conditions and restarts instead of exceptions. Conditions and restarts come from Lisp, and it is one of the greatest ideas in computer science that almost…

>> If you use C or C++ and genuinely don't care about performance you performed a premature optimisation in the choice of these languages. Any JVM language would be suit your needs better in some way.

>That is a surprising statement, especially since you don't necessarily have any idea what my needs are.

Look we've probably exhausted this discussion and are talking past eachother, but I do want to point out that this is a simple misunderstanding.

I meant "you" in the sense of the archaic english "one"
"If one uses C or C++ and one does not care about performance one has performed a premature optimisation." It sounds terribly old-fashioned expressed like this but I guess the meaning is clearer given the way "you" is overloaded to mean you singular (you yourself), you plural (you and your admirers) and you in the sense of 2. here: http://dictionary.reference.com/browse/you "one; anyone; people in general"

I obviously have no knowledge or opinion about choices made specifically by yourself, and we are in total agreement that holding an opinion on such would be ridiculous in the extreme.

You might find this interesting, it highlights the problem I'm talking about with exceptions by a guy who has done it in c++ with amazing success, likes the language and appreciates its defects as well as its strengths:
http://250bpm.com/blog:4

Where you are writing those pieces of code in your program that caused you to rationally choose C or C++ as your language (ie has to perform &…

You can read some excellent material on the subject here: http://250bpm.com/blog:4

I'm far from being a fan of Casey. I find that he makes strong statements based on weak arguments. He's overly hateful of Microsoft and C++, despite him using Visual Studio and a C++ compiler. He tries to be pedantic but makes a fair share of mistakes. Some of his architecture design choices left me with a straight face wtf expression.

C++ has it's flaws, that's widely known and accepted by the community. It's even highlighted in the "Effective C++" books. Unfortunately, the best advice given is "don't do that". I believe a vast majority of C++ users will gladly switch to a new language that offers the same level of abstractions at a comparable speed (maybe Go or Rust). For now, C++ users have to understand the language well enough to avoid its many traps and pitfalls. Moreover, new versions of the standard add to this burden. I know of no project built entirely using C++14. People will always have to deal with legacy code.

OOP is just another programming paradigm C++ supports. You're not required to use it, and you're not even paying for it if you're not using virtual methods. Sure, C++ allows you to do a lot of funky things from overloading operators to implicit conversions but that's another of those things everybody agrees should not be used unless explicitly necessary. OOP facilitates encapsulation and polymorphism which are great tools when designing software systems.

C has its…

Haven't seen, but thanks. Lived and worked while following some of the ideas mentioned.

E.g. at the whole bottom of the page in some comment is a link to:

"Why should I have written ZeroMQ in C, not C++ (part II)"

https://250bpm.com/blog:8/

where the author writes "Let's compare how a C++ programmer would implement a list of objects..." and then "The real reason why any C++ programmer won't design the list in the C way is that the design breaks the encapsulation principle" etc.

I have indeed more than once used intrusive data structures in non-trivial C++ code, and the result was easy to read, and very efficient. There I really didn't care about some "thou shalt not" "breaking the encapsulation principle" because whoever thinks at that level of "verbot" 100% of times is just wrong.

The "encapsulation principle" is an OK principle for some levels of abstraction, but nobody says that one has to hold to it religiously (exactly my point before). I would of course always make an API which would hide what's behind it. But where I implement something ("the guts" of something), I of course have my freedom to use intrusive elements, if that solves the problem better. I have even created some "extremely intrusive" stuff (with a variable number of intrusive links in the structures). It worked perfectly. Insisting on doing anything as "ritual" all the time is just so, so wrong.