On Tuesday, 7 June 2016 at 19:52:47 UTC, Chris wrote:
But we agree that templates are a good idea in general,
regardless of the actual implementation.
Having access to parametric abstractions is a good idea. How to
best use them is not so obvious... in real projects where things
changes. (Except for trivial stuff).
What do you mean by `memory management`? GC/RC built into the
compiler?
Everything related to managing ownership and access, making the
most out of static analysis. Putting things on the stack, or
simply not allocating if not used.
What do you mean? Is it a good or a bad thing that the library
is detached from the core language?
I mean that the standard library features that are closely
related to the core language semantics are more stable than
things like HTTP.
Believe me, features will be requested. Would you have an
example of how such a language, or better still did you have
time to design and test one? A proof of concept.
C++ with just member functions and wrappers around builtins is
pretty close. Yes, I have used minimalistic languages, Beta for
instance. I believe gBeta is closer. I guess dynamic languages
like Self and even Javascript are there too. Probably also some
of the dependently typed languages, but I have never used those.
If you stripped down C++ by taking out everything that can be
expressed using another feature then you would have the
foundation.
Having to write the same for loop with slight variations all
over again is not my definition of efficient programming. One
of D's strengths is that it offers nice abstractions for data
representation.
Hm? You can have templated functions in C++.
Not special but handy. Before Java 8 (?) you had to use
inner/anonymous classes to mimic lambdas. Not very efficient.
Boiler plate, repetition, the whole lot.
Well, that is a matter of implementation. C++ lambdas are exactly
that, function objects, but there is no inherent performance
penalty. A "lambda" is mostly syntactical sugar.
I was not talking about that. Read it again. I said that the D
community actively demands features or improvements and uses
them.
Are you talking about the language or the standard library? I
honestly don't think the latter matter much. Except for memory
management.
It goes without saying that existing features have to be
improved. It's a question of manpower.
No, it is a matter of being willing to improve the semantics.
Many of the improvements that is needed to best C++ are simple,
but slightly breaking, changes.
D could change floats so that interval arithmetics can be
implemented. Which is difficult to do in clang/gcc. That would be
a major selling point. But the basic reasoning is that this is
not needed, because C/C++ fails to comply with the IEEE standard
as well.
If the motivation is to trail C/C++, then there is no way to
surpass C/C++, then there is no real motivation to switch.
There is a learning curve that cannot be made flatter. There
are concepts that have to be grasped and understood. Any
language (cf. Nim) that allows you to do sophisticated and
low-level things is harder to learn than JS or Python.
Not sure what sophisticated things you are referring to.
(JS and Python have complexity issues as well, you just don't
need to learn them to make good use the languages).
Go forces you to repeat yourself. The less features you have,
the more you have to write the same type of code all over
again. Look at all the for loops in a C program.
Loops and writing the same code over is not a major hurdle.
Getting it right is the major hurdle. So having many loops is not
bad, but having a way to express that you want to iterate from 1
to 10 in a less error-prone way matters.
But you can do that in minimalistic languages like Beta that has
only two core entities:
- a pattern (type/function/subclass)
- an instance of a pattern
Just define a pattern that iterates and prefix your body with it,
that is the same as subclassing it.
Pseudo-code (not actual Beta syntax, but Cish syntax for
simplicty).
iterate:{
N:@int;
i: @int;
enter N
do
i = 0
while (i < N)
do
inner; // insert prefixed do-part here
i++
}
10 -> iterate{ do i -> print; }
Or you could just do
repeat10:{
N:<{ n:@int; do 10->n; inner; exit n};
i:@int;
do N -> iterate{ do inner; }
}
repeat99:repeat10{
N:<{ do 99->n; inner; }
}
repeat99{ do i -> print; "bottles of wine" ->print }
etc...
