On Wednesday, 15 November 2017 at 02:05:27 UTC, codephantom wrote:
On Tuesday, 14 November 2017 at 16:38:58 UTC, Ola Fosheim
Grostad wrote:
It [C]is flawed... ESR got that right, not sure how anyone can
disagree.
Well I 'can' disagree ;-)
Right… :-)
Languages are just part of an evolutionary chain.
Right and C is part of this chain BCPL->B->C, the funny thing is
that BCPL was never meant to be used as a language beyond
bootstrapping CPL, but given the limited computers of the day
BCPL and later C became the default system programming language
exactly because it wasn't much of a language and fit rather well
with the CPUs of the day (among other things, you could hold the
whole compiler in main memory ;-).
But C doesn't fit well with the underlying hardware anymore, even
though CPU makers are benchmarking against existing C code and
make provisions for the C model. That argument can be used
against C++, D and Rust too. :-P
So, if the abstraction no longer match the concrete well then it
will make less and less sense to use it. Overall, I think we
over time will see growth in higher level languages designed to
map well onto the hardware at the optimization stage. Current
languages aren't quite there yet though, and frankly, neither are
the CPUs. I think we are in a transition period (wide pipelines
in the CPU + GPU is an indicator).
No part of the chain should be considered flawed - unless it
was actually flawed - in that it didn't meet the demands of the
environment in which it was initially conceived.
Right, but the performance bottle-neck of serial code is now
forcing changes in the environment.
In that circumstance, it must be considered flawed, and
evolutionary forces will quickly take care of that.
Not quickly, you have the whole issue with installed base, center
of gravity… The mindset of people…
But a programming language is not flawed, simply because people
use it an environment where it was not designed to operate.
Ok, fair enough. BCPL was meant to bootstrap CPL and C was a hack
to implement Unix… ;^)
Corporate needs/strategy, skews ones view of the larger
environment, and infects language design. I think it's infected
Go, from the get Go. I am glad D is not being designed by a
corporate, otherwise D would be something very different, and
far less interesting.
I don't think Go is much affected by the corporate… The Go
designers appear to be strong-headed and the language design is
in line with their prior language designs. I believe they also
made the same mistake as D with reallocating buffers "randomly"
when extending slices such that you end up with two arrays
because the other slices aren't updated. Not very reassuring when
a team of people make such correctness blunders. And what about
their "exceptions", a dirty hack only added because they are
hellbent on not having exceptions… All about the mentality of the
designers… put blame where blame is due…
The design of Dart was affected by the corporate requirements
according to the designer who called it a "bland language". I
think he would have preferred something closer to Smalltalk :-).
Dart is probably more important to Google than Go as their
business frontend depends on it. And Dart is now getting static
typing to the dismay of the original designer (who is in the
dynamic camp).
But yeah, it can be interesting to think about how a mix of
personalities and external pressure affect language design.
This is where Eric got it wrong, in my opinion. He's looking
for the language that can best fix the flaws of C.
Seems to me that he is looking for something that is easier to
deal with than C, but where he can retain his C mindset without
having performance issues related to GC. So the bare-bones
semantics of Go combined with a decent runtime and libraries that
are geared towards network programming probably fits his use case
(NTP something?)
In fact C has barely had to evolve (which is not a sign of
something that is flawed), because it works just fine, in
enviroments for which it was designed to work in. And those
enviroments still exist today. They will still exist
tomorrow..and the next day...and the next..and...
They exist in embedded devices/SoCs etc. Not sure if it is
reasonable to say that they exist on the desktop anymore beyond a
mere hygienic backwards-compatibility mentality among CPU
designers.
Ola.
