Re: [dev] [RFC] Design of a vim like text editor

From: Ralph Eastwood <>
Date: Wed, 17 Sep 2014 07:39:55 +0100

Maxime Coste wrote:
> That last one is by far the most interesting, Bartos being very familliar with
> C++. Note that its not C that is advocated, but haskell...

I would advocate functional languages (not necessarily Haskell) over C++ any day
 - although implementations of functional languages have this far
disappointed me slightly.
I'm hoping a good multi paradigm language will appear some day.

On 17 September 2014 06:57, Markus Teich <> wrote:
> Maxime Coste wrote:
>> That is the complaint I mostly hear about Go, the lack of Generic. That and
>> garbage collection.
> Why would I want to apply the same algorithm to semantically different
> arguments? Appart from different kinds of number representations no useful
> example comes to mind.

That is a good point; I think the current purpose of generics in other
languages is to
enforce type checking and provide implicit pointer conversion (for
example in C if you
had a data structure/algorithm that took in a generic type argument as
a pointer).
These are conveniences, and not necessities.

However, there is one more valid use in the case of a generic
algorithm/data structure.
Imagine you have subroutines/functions that relate to your data
structure and you want
to add an item. Generics allow you to write one piece of code to deal
with all types and
let you pass the items *by value* rather than *by reference*. This
would be useful when
your item data type is small so it can be optimised by the compiler.
It's not like this can't be done in C, you can use X-Macros [1] to do this
(I realised after writing this example). I guess, it's arguably less elegant.
For more syntactic sugar, _Generic from C11 would work, but is not necessary.

On a more constructive note, I think a list of C++ paradigms that are commonly
used could be compared with their C counterparts... That would make it a useful
reference for suckless programmers.

What are people's views on literate programming for maths heavy code?
Like Maxime, operator overloading in C++ for maths code offloads the
brain so you can
focus more on the algorithmic detail and remember what you have done
when you return
to the code after a long time (or if someone else has to read it).
I think, however, literate programming using LaTeX would allow the
same degree of
expression and probably be even better for readability.
I realise suckless code doesn't tend to make use of literate
programming often, particularly
because the code is relatively simple, memory management patterns
which C programmers
would have seen countless times over, but for complicated and novel algorithms,
different thought patterns are necessary.

C++ provides error-checking facilities that C does not possess.
However, I think these are
rather limited in scope. I would rather go for verification proofs [2].

Although C is good enough for most of us, I can't help but wonder if ideas from
Forth, Haskell, Lisp, Alef (and so on) could somehow provide a clean systems
language without feature bloat. For instance in C (yes C), I can
immediately think of
6 different recursive mechanisms/keywords... is that many necessary???



Tai Chi Minh Ralph Eastwood
Received on Wed Sep 17 2014 - 08:39:55 CEST

This archive was generated by hypermail 2.3.0 : Wed Sep 17 2014 - 08:48:06 CEST