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

From: Christoph Lohmann <20h_AT_r-36.net>
Date: Tue, 16 Sep 2014 23:02:40 +0200

Greetings.

On Tue, 16 Sep 2014 23:02:40 +0200 Maxime Coste <frrrwww_AT_gmail.com> wrote:
> On Tue, Sep 16, 2014 at 10:02:54PM +0200, Roberto E. Vargas Caballero wrote:
> > > Well, I still rely a lot on having a proper type system to do checks at
> > > compile time. For example I have separate types for line counts, byte
> >
> > Proper..., good word for saying a pain in the ass. One of the best thing
> > of C (and C++ because they share this part) is automatic conversions
> > that remove this work of the programmer. If you have problems
> > with them maybe you should learn a bit more.
>
> Ok, so what exactly is the sum of 3 lines and 2 bytes ? The whole point
> is to catch at compilation code that is logically invalid, if you have
> f(ByteCount, LineCount), you cannot call it with a (LineCount, ByteCount)
> signature. In C you would be forced to use f(int, int), and long debugging
> sessions to discover this simple mistake.

Then write better and more logic access functions instead of your object
abstraction. It keeps your mind simpler and speeds up your code.

> > > counts and char counts, so I get a compilatin error if I try to add
> > > bytes and char, while still getting the conveniences of using operators,
> > > and with code that compiles down to plain int operations.
> >
> > Operator overloading, one of the worst things of C++ (well, there are
> > so much of them that is only more of them). It only is useful to make
> > obfuscated code.
>
> It just gives you tool so that you can write your code closed to the domain
> language, did you learn linear algebra writing matrix_add(m1, m2, &m3)
> ? or m3 = m1 + m2 ?

This is programming and not your playground. Avoid fancy code.

> > > Another example would be safe_ptr<T>, pointers that compiles to raw pointers
> > > in optimized builds, but that guarantee that the pointed to object is alive
> > > (you get an assert if an object dies when a safe_ptr to them still exists).
> > > It stills behave like a pointer, but allows me to both document, and get
> > > debug checks, that the pointed to object should by design outlive this pointer.
> >
> > I don't need this damaged brain pointers, again if you have this kind
> > of problems you should learn a bit more. Like a friend of mine says,
> > code in C is like sex, you have to know what you are doing.
>
> You probably never worked on complicated enough code bases if you believe every
> program fits entirely in your brain. Putting safe guards in you code asserting
> that what you believe is correct actually is is necessary if you want to keep
> your sanity.

Suckless is about writing simple code bases. When your choice for C++ is
because you want to write complex code bases then you are in the wrong
community and should leave as fast as you can.

By adding constraints on the hidden complexity it is by cause made hard‐
er to write useless abstraction code.

> > > C++ is not the most elegant language, but there is nothing better available
> > > IMHO. C89's minimalism is attractive, but no overloading, no generics, and
> > > weak type system makes it harder than necessary to manage complexity. And
> > > modern C (99 and 11) does have its own ugly quirks (the magically overloaded
> > > tgmath.h functions, 'complex' builtin type...).
> >
> > No generic is a feature. Generic are very stupid idea that only creates
> > blown binaries (this is one of the point I don't like about C11). Also,
> > the compexity of generics in a lenguage with automatic conversions
> > like C (and C++) is too much.
>
> what is silly is rewriting the same function with different arguments again
> and again. Or ending up relying on macros to emulate generics.

Learn to code in C.

> > > A common symptom of C's lacking abstraction facilities is the reliance on
> > > linked lists as the most common list data structure. As it is so easy to
> > > implement you add do it quickly for any struct, when in practice a dynamic
> > > array provides you with much better performance characteristics.
> >
> > Depend. Basically depend of the size and the operations you do in it.
> > I suppose you know that inserting in a dynamic array is O(n^2), and of
> > course, searches in an unordered array is O(n), while inserting
> > in the head of a list is O(k). There is a limit in the size where almost
> > operations in dynamic arrays are slower, and in a lot of times with this
> > small sizes you can use overdimensioned arrays that are far faster
> > than dynamic arrays.
>
> Get your complexity right, inserting in a dynamic array is O(n), the eventual
> need for an allocation is amortized (whereas you always end up doing a malloc
> for your linked lists). Another thing you should look up is modern cpu
> architectures and caches, in practice the much better locality of reference
> of arrays makes them *way* better on operation like insert/erase in the middle
> than lists even though complexity theory says otherwise. (Remember, complexities
> are asymptotic, you need huuuuuge number of elements).

When you work close to the metal much of your theory can be optimized
out. I won’t tell you how.

> > Stop this C++ proselytism because the only thing you are going to
> > get is becoming a troll. If you like maschoshism is your problem, but
> > please don't tell to us.
>
> Can't we have a civilized discussion ?

No, civilisation ended when »C++« was mentioned. Code abstraction and
bad design choices made from idiots relying on OOP are the reason why
your local Windows machine is so slow in loading drivers, opening Win‐
dows, loading the help file in the regular Java NULL pointer exception
or simply loading and displaying text in a webbrowser.
This can only be avoided by changing and restricting the system.


Sincerely,

Christoph Lohmann
Received on Tue Sep 16 2014 - 23:02:40 CEST