www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Memory Safety

Walter Bright:
 Here's Bartosz' article on the subject:

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
Mar 22 2008