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

From: Maxime Coste <frrrwww_AT_gmail.com>
Date: Wed, 17 Sep 2014 19:42:47 +0100

On Wed, Sep 17, 2014 at 06:29:01AM +0200, Christoph Lohmann wrote:
> On Wed, 17 Sep 2014 06:29:01 +0200 Maxime Coste <frrrwww_AT_gmail.com> wrote:
> > On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote:
> > > This is programming and not your playground. Avoid fancy code.
> >
> > I guess that is a matter of taste, I just know m1 + m2 calls operator+(Matrix, Matrix).
>
> Which is, like in other answers stated, not obvious. You have to look up
> the definition to read the source. Hint: Here complexity in the system
> can be avoided completely.

In what exactly is that different from seing mat_add(m1, m2, &m3) ? you see
m3 = m1 + m2, you know a + b is syntactic sugar for operator+(a, b). That is
all.

It seems to me that you are saying 'to someone used only to C, C++ operator
overloading is confusing', on that I can only answer yes, as pointer arithmetic
is confusing for people not used to C or C++.

> > What is your strategy in C when you need to apply the same logic on different types ?
>
> That doesn’t happen that often to justify overloading. Hint: Avoided
> complexity in the system *beforehand*.

That goes back to the linked list/array thing, you dont have generics, so you use the
easy thing without generics: linked lists, which are almost always a poor choice.

>
> > > > 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.
> >
> > The best you can do is store your linked list in an array, and sort it at certain
> > point so that elements end up linearly in memory. But when you've done that you
> > already have a dynamic array implementation.
>
> No, the best is to apply whichever data structure you need at the mo‐
> ment. Discussing which array to use makes no sense without the actual
> problem defined.

As I said, in practice you almost always have better performances with dynamic arrays
than lists, hence it should be your default list structure. But as it is a pain
to implement in C, because you cannot implement it generically, linked lists stay
the default implementation.

> You are too young, if you think .NET is the problem. The problem arose
> before that with C++ in the Windows world and X11 in Unix. Let’s see
> which wrong logic answer you will apply to the last argument.

Yay, X11 is a well known C++ program. Seriously, there are a lot of bad design
decision in Windows, as there a are a lot in modern linux userland, and
they do not seems to stem from the implementation language. the 90s where the
time of OOP everywhere, and we learned a lot since them. But rejecting the
tools because they were overused makes no sense. the C for construct can be
overused as well, we now have guidelines on that, and they are not 'for
loops are evil'.
 
> Conclusion: You try to force your work experience into the suckless phi‐
> losophy, which does not work due to different basic principles. Next you
> are fail to accept that reading source code in Open Source is more im‐
> portant than your abstraction of reusing code between hating and oppor‐
> tunity‐seeking programmer groups in corporate lifes. Please come down
> from your throne.

I'm merely trying to defend the fact that I would like to post about a C++
project on the suckless mailing list and have it judged on its own merits
rather than on dogmatic ideas about its implementation language.

Cheers,

Maxime.
Received on Wed Sep 17 2014 - 20:42:47 CEST