• bearophile <bearophileHUGS lycos.com> Mar 22 2008

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright:
 Here's Bartosz' article on the subject:
 http://www.digitalmars.com/d/2.0/safed.html


Bartosz Milewski about SafeD:

The pipe dream of programming language designers is to be able to guarantee
that if a program compiles successfully, it will work.<


I think Haskell language is already a bit closer to this goal than most other
languages. But that's a pipe dream only of some programming language designers.
I assure you that other language designers have different purposes. There are
lots of languages (Lisp, Smalltalk, Python, Ruby, Lua, Boo, Perl, etc) that
have success, often a wide success, despite their designers don't have that
purpose.


why anyone would want to switch to a less powerful and less efficient language.<


Note that some languages are "more powerful" than C++. Haskell type system or
Lisp macros allow you to do things in a short space that you will have a hard
time doing in C++. C++ type system is full of holes. Python dynamic typing
allows you to do many things you don't even dream about in your usual C++
programs, etc.


What are the major impediments to productive programming in C++?<


Well, starting from the most important ones:
- Too many corner cases and corner cases of the corner cases, etc
- Too many things to remember and to think about
- Not enough user-friendly
- Bad syntax
- It keeps various design mistakes of C
- Too much unsafe
- Forces you to always focus on too much little details, even in situations
where your code is I/O bound, or user-interface-speed bound, etc, where the
slowest scripting language too may be enough.
- Not dynamic enough for some purposes
- etc


once somebody invested the time and effort to become proficient in C++, why in
the world would they want to abandon it?<


More productivity is one answer, but it's not the whole answer, and even
"productivity" means little if you don't decompose it into its parts.
Programming in other languages is or may be:
- faster
- more fun
- safer (less bugs, etc).
- requires less brain/memory
- etc.

I think that in many situations D is currently more productive than C++, but it
has many problems still, and it can be improved in many ways still.
A higher "productivity" comes from many different things, it doesn't come from
a single thing. D can't be as productive as Python, because their purpose is
different. Python has dynamic typing, it's a huge programming speed boost, but
beside a really good duck (variant) type that can be added in future (example:
it must allow me to nest arrays of duck as much as I want), D will keep being
statically typed (and I like it that way). Python is designed for the
programmer first, to have the best possible syntax, Python designers think that
a better syntax and a better language is more important than running speed. So
it's normal that programming in Python is faster and produces less bugs and it
feels more fun, etc. This is true for Ruby too, usually.

To increase D "productivity" various things may to be fixed/improved:
- I think the single most important thing is to avoid corner cases. D has quite
less corner cases than C++, but I have found many of them still, you can see
some of them in some of my posts. A long-term hunt has to begin, to find them
and to remove as much of them as possible, this is very useful if D wants to
become a safer language. I think a safer language is the first thing that
allows you higher "productivity". At the moment I think this work is more
important than even adding AST macros to D. AST macros are a cool feature, that
surely works as a D advertisement, to attract new people, while "D has 1/100 of
the corner cases of C++ and only 15 times as much as Python" is a much less
sexy advertisement, but I think it will make those new people *keep* using D in
the medium/long run.
- In one of my posts I have shown that the current D module system has various
holes, but it can be fixed. Python 3.0 shows how it can be designed. If copying
Python 3.0 module system is seen as a bad/boring thing, then a totally
different module system can be designed, but it must be sound anyway, unlike
the current one. A fixed module system will avoid some problems and bugs.
- Using integrals in D is a mine field still. Here you can find some pages
about C and C++ that show some of the things a compiler must do to improve the
situation:
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6422581

https://www.securecoding.cert.org/confluence/display/seccode/INT30-C.+Do+not+perform+certain+operations+on+questionably+signed+results

https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+integer+operations+do+not+result+in+an+overflow

Another improvement comes from adding pointer and integer overflow controls,
like in Pascal and Lisp, this lib may be automatically used by the compiler
when the code isn't in release mode:
http://www.cert.org/secure-coding/IntegerLib.zip
[Python is more productive than C++ also because you (usually) can't overflow
Python integers, this avoids a ton of problems, and you don't have to care
about those things, so you can speed up your programming style.]
- Some parts of the syntax can be improved and shortened, like the is() syntax,
lambda syntax, etc.
- D is somewhat C-compatible, but C has various warts/problems. So if D wants
to be better, it can't avoid being different regarding some things. Some of the
things that make numerical computation in C a minefield:
-- negation does not turn negative numbers into positive ones in 2s complement
math
-- C does not define the shift value to be saturating
-- C does not enforce the definition of sign right shifting
-- In the case of (signed int)a % (unsigned int)b, the cast value of a is first
promoted to an unsigned int, then the modulo is computed. This will lead to
unintended results whenever (signed int)a is negative (the result will not be
congruent to (signed int)a modulo (unsigned int)b).
-- etc.
- One last thing: if I use a language that is 30% slower than D (so it has a
better syntax, it's higher level, etc), but it allows me to use both the cores
of the CPU for many parts of my program, then the program may end up running
faster anyway. So D has to focus on parallel programming too.
ParallelPascal/VectorPascal and Fortress show some "simple" ways where D can be
improved in such regard.

This is just a little list of things, but I think it's enough to show that
there's no silver bullet to increase "productivity". Still, D has many ways to
increase it in its future, keeping most of its running speed.

Bye,
bearophile