Re: Future of C++
Pavel wrote:
kwikius wrote:
On Aug 6, 5:09 pm, Matthias Buelow <m...@incubus.de> wrote:
ebony.s...@gmail.com wrote:
To increase in emphasis on statically verifiable type safety. If
you want type safety, you should be expressive. I believe being
less expressive lead us to script programming.
I don't quite understand that statement. What do you mean? Static
typing and expressiveness in a language are two distinct
concepts. C++ is in some ways more expressive than C but not as
expressive as Lisp (which is a dynamically typed language).
What's got one to do with the other?
Wel heres my take on it.
If you have strong typing you can be more expressive in comfort
because errors in expressions will be caught by the compiler,
whereas dynamic typing postpones errors till runtime and it may
take much testing to try to locate all possible errors.
IOW the dynamic language is "expressive" of many things though some
are potentially incorrect, but the static typed language is
expressive, whilst being (arguably) proved correct prior to
execution.
regards
Andy Little
I am not sure one language is much more expressive than the other --
IMHO it is much more dependent on the style of use than the language
itself. I have seen quite understandable code in different
Assemblers and much more of inscrutable code in all possible
languages even including Python (although it is not too easy to
write something completely misleading in Python -- maybe only on
purpose). But the "cost of complete understanding" of a C++ program
was always among the highest for me -- often, I had to pre-process
a source file to understand with certainty what's coming from
where. Consider this fragment:
int i = 0;
f(i);
myprint(i);
If it is written in Java (or C, for that matter), I can tell with
some certainty that myprint() receives 0 as an argument. But to tell
something about it in C++ I have to know whether f() takes a
reference or a value
Using a better name than f() would help a lot!
Hardly a language problem.
To review C++ code with a reasonable speed (as compared to Java, C
or even PL/SQL code of the same functional complexity -- even
FORTRAN), one would have to put a lot of trust to the people who
wrote it. I personally got burned too many times and I do not trust
anymore so I have to bite the bullet and jump the sources back and
forth like crazy. Which brings us back to the productivity
question.. it should not come at a surprise that in a project of
any considerable size a developer spends more time reading,
researching and understanding the code than changing it. From this
perspective, unexpectedly, C is so much more productive than C++
(plus, an equivalent C program usually compiles 10 times faster
than C++ -- because "smart guys" like inserting templates and
meta-programming wherever they don't need them or at least they
will include a couple of "cool" headers -- so a
change/compile/debug iteration in C is much shorter than in C++).
As usual, "You can write bad programs in any language".
Here is an example of what you can do in C
(http://www.ioccc.org/2004/hoyle.c), hardly 10 times easier to read
than anything else.
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#define _ ;double
#define void x,x
#define case(break,default) break[O]:default[O]:
#define switch(bool) ;for(;x<bool;
#define do(if,else) inIine(else)>int##if?
#define true (--void++)
#define false (++void--)
char*O=" <60>!?\\\n"_ doubIe[010]_ int0,int1 _ Iong=0 _ inIine(int
eIse){int
O1O=!O _ l=!O;for(;O1O<010;++O1O)l+=(O1O[doubIe]*pow(eIse,O1O));return
l;}int
main(int booI,char*eIse[]){int
I=1,x=-*O;if(eIse){for(;I<010+1;I++)I[doubIe-1]
=booI>I?atof(I[eIse]):!O
switch(*O)x++)abs(inIine(x))>Iong&&(Iong=abs(inIine(x
)));int1=Iong;main(-*O>>1,0);}else{if(booI<*O>>1){int0=int1;int1=int0-2*Iong/0
[O]switch(5[O]))putchar(x-*O?(int0>=inIine(x)&&do(1,x)do(0,true)do(0,false)
case(2,1)do(1,true)do(0,false)6[O]case(-3,6)do(0,false)6[O]-3[O]:do(1,false)
case(5,4)x?booI?0:6[O]:7[O])+*O:8[O]),x++;main(++booI,0);}}}
Bo Persson