The Artima Developer Community
Sponsored Link

Weblogs Forum
Why? Language Archaeology ... and Metaprogramming

89 replies on 6 pages. Most recent reply: Sep 14, 2009 4:31 PM by Andy Dent

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 89 replies on 6 pages [ « | 1 ... 2 3 4 5 6 | » ]
david david

Posts: 16
Nickname: david21001
Registered: Mar, 2007

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 26, 2009 12:33 PM
Reply to this message Reply
Advertisement
> > > C++ does not have flaws because of compatibility with
> > C.
> > > C++ has flaws because it was not thought out well.
> >
> > This is precisely what I'm arguing against. If you had
> > been there as I was, you would have seen very smart
> people
> > excruciatingly going over each decision, discovering
> all
> > the problems before adding features. It was thought out
> > *extremely* well, and the reason the language is
> difficult
> > is precisely because of C compatibility.
> >
> > Oh. Wait. You're trolling, aren't you. You got me. Good
> > for you.
>
> No, I am not trolling at all. Having worked with C++ for
> the last 11 years, and having used every feature of the
> language, I know that there are alternatives that could
> have been chosen that could have made the language much
> better.
>
> Some examples:
>
> 1) the distinction between classes and non-classes types.
> All types could have been classes, even primitives.

you are referencing another language's paradigm: types=classes=primatives is just not the paradigm used in C++ -- deal with it!


>
> 2) uninitialized variables. Variables should always have
> been initialized to their default value. If there was a
> performance issue, then the programmer should have a
> keyword in his disposal telling the compiler to allocate
> memory for the variable but not initialize it.

again, just not the way it's done in C/C++ for whatever reason, so what? languages shouldn't be designed around a software engineer's laziness or ignorance of the programming language. you should know a little bit more about what goes on "under the hood" when you code in any programming language, and not just C/C++. For example, in Java and the .Net languages, do you know how the virtual machines handle deallocation of memory, their threading model, etc; do you think you should?



>
> 3) default values for parameters only at the end of the
> parameter list. A function could have default values in
> any of its parameters, not only in the parameters of the
> left side of the parameter list.

the use of default parameters is a convenience to the programming language; and i am sure it presents some headaches to compilers and interpreters.
>
> 4) lack of pass-by-name parameters. Why C++ doesn't have
> it? there is nothing that has to do with C combatibility.


pass-by-name? C/C++ have function pointers which can be a very powerful tool in one's software engineering toolbag.


>
> 5) the choice of angle brackets for template parameters.
> This was a mistake that made the grammar a lot more
> ambiguous than what it was.

aren't we being a little picky here when it comes to symbology and language syntax friend? there is only one or two gotchas when it comes to template programming that i am aware of... and for the most part you don't need to use templates, if you don't wish to...

>
> 6) the choice of syntax '= 0' for abstract methods,
> because of fear of introducing another keyword. Nothing to
> do with compatibility with C.

that's just an easy way to identify the difference between pure virtual and virtual... most students easily understand the concept and easily recognize its use. the other's end up taking business courses or something less challenging. i never saw that as a flaw or a shortcoming in the language.




>
> 7) lack of anonymous functions. They could be very simple,
> i.e. not be closures, not capture the environment. They
> could be localized parametrized pieces of code that refer
> to hardcoded addresses (so there is no need for the extra
> data pointer). Again, nothing to do with C compatibility.

this is more of a convenience in other languages, and I never see the need when i code in C or C++.
>
> 8) lack of tail call optimization. Again, nothing to do
> with C compatibility.

really not needed for most applications; choose the language that best suits your needs... maybe python is more applicable?



>
> 9) lack of compile-time introspection of classes
> properties (class names, class members, class member
> types, class member names, etc). Again, nothing to do with
> C, but it would greatly simplify a lot of code.

IMHO, introspection violates the core principals of OO programming encapsulation, polymorphism, inheritance, etc... objects don't need to know type/RTTI information... properties violate encapsulation and data hiding...there shouldn't be a need to access attributes directly... if so, why not write your code in C or some other procedural language?



>
> 10) initializer lists. They could have been part of the
> constructor code.

why? is it necessary or just a convenience? should "convenience" functionality be included in any language? or is that what user defined libraries are for?

>
> 11) lack of static initialization of class members as a
> separate function. The same code must be repeated over and
> over in each constructor.

have to explain this one in more detail, provide an example.


>
> 12) uniform construction syntax. Again, nothing to do with
> C. C(a) and C = a should have been equal. C++0x solves
> this with C{}.

object creation and assignment are different.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 29, 2009 7:35 AM
Reply to this message Reply
> > C++ does not have flaws because of compatibility with
> C.
> > C++ has flaws because it was not thought out well.
>
> easy for you to say now 20 years late and based upon your
> knowledge of the state of current technology.
>
> don't be ignorant and insult dr. stroustrup.

There has not been any significant change in the last 30 years in programming language and compiler technology. Whatever is known now about programming languages was also known 20 years ago. The state of the art programming languages of today (Smalltalk, Ada) are products of the late 70s. LISP is even older.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 29, 2009 7:45 AM
Reply to this message Reply
> > > > C++ does not have flaws because of compatibility
> with
> > > C.
> > > > C++ has flaws because it was not thought out well.
> > >
> > > This is precisely what I'm arguing against. If you
> had
> > > been there as I was, you would have seen very smart
> > people
> > > excruciatingly going over each decision, discovering
> > all
> > > the problems before adding features. It was thought
> out
> > > *extremely* well, and the reason the language is
> > difficult
> > > is precisely because of C compatibility.
> > >
> > > Oh. Wait. You're trolling, aren't you. You got me.
> Good
> > > for you.
> >
> > No, I am not trolling at all. Having worked with C++
> for
> > the last 11 years, and having used every feature of the
> > language, I know that there are alternatives that could
> > have been chosen that could have made the language much
> > better.
> >
> > Some examples:
> >
> > 1) the distinction between classes and non-classes
> types.
> > All types could have been classes, even primitives.
>
> you are referencing another language's paradigm:
> types=classes=primatives is just not the paradigm used in
> C++ -- deal with it!

Why primitives not be classes? ask yourself. Wouldn't it be beautiful if all types where classes?

>
>
> >
> > 2) uninitialized variables. Variables should always
> have
> > been initialized to their default value. If there was a
> > performance issue, then the programmer should have a
> > keyword in his disposal telling the compiler to
> allocate
> > memory for the variable but not initialize it.
>
> again, just not the way it's done in C/C++ for whatever
> reason, so what? languages shouldn't be designed around a
> software engineer's laziness or ignorance of the
> programming language. you should know a little bit more
> about what goes on "under the hood" when you code in any
> programming language, and not just C/C++. For example, in
> Java and the .Net languages, do you know how the virtual
> machines handle deallocation of memory, their threading
> model, etc; do you think you should?

Have you worked with large teams of programmers in very large programs? it's very easy to forget to initialize a variable, especially in large projects. Programming languages are supposed to help.

There is nothing wrong with automatic initialization. The compiler should have a keyword to disable automatic initialization, but the default should have been to automatically initialize a variable.

>
>
>
> >
> > 3) default values for parameters only at the end of the
> > parameter list. A function could have default values in
> > any of its parameters, not only in the parameters of
> the
> > left side of the parameter list.
>
> the use of default parameters is a convenience to the
> programming language; and i am sure it presents some
> headaches to compilers and interpreters.

No, there is no headache involved.

> >
> > 4) lack of pass-by-name parameters. Why C++ doesn't
> have
> > it? there is nothing that has to do with C
> combatibility.
>
>
> pass-by-name? C/C++ have function pointers which can be a
> very powerful tool in one's software engineering toolbag.

Function pointers are not a substitute for pass-by-name variables. They are unrelated things.

>
>
> >
> > 5) the choice of angle brackets for template
> parameters.
> > This was a mistake that made the grammar a lot more
> > ambiguous than what it was.
>
> aren't we being a little picky here when it comes to
> symbology and language syntax friend? there is only one
> or two gotchas when it comes to template programming that
> i am aware of... and for the most part you don't need to
> use templates, if you don't wish to...

Stroustrup himself said so. The presence of angle brackets makes the language grammar ambiguous, and this makes things like intellisense or refactoring very difficult to create.

>
> >
> > 6) the choice of syntax '= 0' for abstract methods,
> > because of fear of introducing another keyword. Nothing
> to
> > do with compatibility with C.
>
> that's just an easy way to identify the difference between
> pure virtual and virtual... most students easily
> understand the concept and easily recognize its use. the
> other's end up taking business courses or something less
> challenging. i never saw that as a flaw or a shortcoming
> in the language.

It's not very important, I agree. It was just an example of something not being affected by C compatibility.

>
>
>
>
> >
> > 7) lack of anonymous functions. They could be very
> simple,
> > i.e. not be closures, not capture the environment. They
> > could be localized parametrized pieces of code that
> refer
> > to hardcoded addresses (so there is no need for the
> extra
> > data pointer). Again, nothing to do with C
> compatibility.
>
> this is more of a convenience in other languages, and I
> never see the need when i code in C or C++.

Lambda functions is the greatest tool for reducing code bloat.

> >
> > 8) lack of tail call optimization. Again, nothing to do
> > with C compatibility.
>
> really not needed for most applications; choose the
> language that best suits your needs... maybe python is
> more applicable?

Tail call optimization is not something I need every day, but it would be nice to have. Again, it's something that C compatibility does not affect.

>
>
>
> >
> > 9) lack of compile-time introspection of classes
> > properties (class names, class members, class member
> > types, class member names, etc). Again, nothing to do
> with
> > C, but it would greatly simplify a lot of code.
>
> IMHO, introspection violates the core principals of OO
> programming encapsulation, polymorphism, inheritance,
> etc... objects don't need to know type/RTTI
> information... properties violate encapsulation and data
> hiding...there shouldn't be a need to access attributes
> directly... if so, why not write your code in C or some
> other procedural language?

There is a great need for introspection. Many algorithms are simplified using introspection; for example, a generic object-based I/O framework.

It's very tedious to have to manually program those things that the compiler can easily provide.

>
>
>
> >
> > 10) initializer lists. They could have been part of the
> > constructor code.
>
> why? is it necessary or just a convenience? should
> "convenience" functionality be included in any language?
> or is that what user defined libraries are for?

Most classes have more than one constructor. Initializing code has then to be repeated for each constructor. This creates a major problem when refactoring code.

>
> >
> > 11) lack of static initialization of class members as a
> > separate function. The same code must be repeated over
> and
> > over in each constructor.
>
> have to explain this one in more detail, provide an
> example.


class Foo {
int x;

//implicitly called before constructors
init() {
x = 0;
}
}


>
>
> >
> > 12) uniform construction syntax. Again, nothing to do
> with
> > C. C(a) and C = a should have been equal. C++0x solves
> > this with C{}.
>
> object creation and assignment are different.

Yes, indeed. C a = b is construction, not assignment.

Arman Sahakyan

Posts: 1
Nickname: armans
Registered: May, 2008

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 29, 2009 11:54 PM
Reply to this message Reply
> .. while C++ provided nothing out of the gate that wasn't possible in C.

This is completely an incorrect statement.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 12:50 AM
Reply to this message Reply
>> Why primitives not be classes? ask yourself. Wouldn't it be beautiful if all types where classes?

I'm not sure I see the benefit. I've never found it an inconvenience that I can't inherit from int

What about performance overheads from making these classes?
For our applications, any reduction in efficiency compared to a plain old int would be a disaster.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 3:07 AM
Reply to this message Reply
> >> Why primitives not be classes? ask yourself. Wouldn't
> it be beautiful if all types where classes?
>
> I'm not sure I see the benefit. I've never found it an
> inconvenience that I can't inherit from int

It's not about inheritance, but about consistency. For example, if int was a class, all the constants related to it could be members of the class.

>
> What about performance overheads from making these
> classes?
> For our applications, any reduction in efficiency compared
> to a plain old int would be a disaster.

There is no performance hit in C++ if primitives were classes. They would have no virtual functions and would occupy only the memory occupied by the primitive.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 6:48 AM
Reply to this message Reply
> > .. while C++ provided nothing out of the gate that
> wasn't possible in C.

> This is completely an incorrect statement.

I think cfront logically proves that it is a completely correct statement.

Peace,

Cameron Purdy | Oracle Coherence
http://coherence.oracle.com/

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 8:56 AM
Reply to this message Reply
> There is no performance hit in C++ if primitives were
> classes. They would have no virtual functions and would
> occupy only the memory occupied by the primitive.

There is no performance hit *now* with today's hardware.

Back when this decision was made, the performance hit was clearly determined to be unacceptable.

And actually, even now, new languages still hesitate on the issue (Fan recently reversed its early decision to have primitive types as classes because they did notice the performance hit, which I find a bit unfortunate but I trust the authors of the language to have assessed the data correctly before making this decision). As a result, Fan's primitive types are now similar to Java's (they are not classes).

--
Cedric

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 9:00 AM
Reply to this message Reply
> > > .. while C++ provided nothing out of the gate that
> > wasn't possible in C.
>
> > This is completely an incorrect statement.
>
> I think cfront logically proves that it is a completely
> correct statement.

Well, we're in Turing completeness kingdom here so it's equally valid to say that "C++ provided nothing out of the gate that wasn't possible in assembly language".

Doesn't really advance the discussion, though :-)

The point is that C++ did enable (and made simpler) a lot of OO concepts that were awkward to implement in C.

But I'm not telling you anything you don't already know, am I? :-)

--
Cedric

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 9:59 AM
Reply to this message Reply
> (Fan recently reversed its early decision to
> have primitive types as classes because they did notice
> the performance hit, which I find a bit unfortunate but I
> trust the authors of the language to have assessed the
> data correctly before making this decision).
They should have looked at how C# does it.
C# has value types which are stack based with no virtual functions.

Quote from http://www.codeproject.com/KB/mcpp/value_types.aspx
Value types implicitly inherit from System.ValueType, and their use is encouraged for types that act like primitive data types, types that are small, types that do not inherit from, or are inherited by, other data types, and types that are not frequently passes as parameters (this would cause a lot of memory allocation and copying). Value types can inherit from managed interfaces, and can override virtual methods defined therein.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 30, 2009 2:50 PM
Reply to this message Reply
Cedric,

While I expected such an obvious response, I did not expect it from you ;-) .. I'm not referring to a theoretical application of Turing completeness, and you knew that!

The early cfront did little more than syntax substitution. C++ was arguably nothing more than syntactic sugar on top of C. Alt-E, Find, Replace, "class", "struct", Alt-A.

It was translation, not compilation or emulation or interpretation.

In retrospect, it is little more than the difference between an assembler (C) and a macro-assembler (C++). The macro-assembler bigots were always making fun of stupid C programmers ("hey, high level C programmer, if this stuff is too hard for you, maybe you should go get a business degree" ;-), and always fond of how much better they were than assembly programmers ("hey, look at my IF macro!").

Peace,

Cameron Purdy | Oracle Coherence
http://coherence.oracle.com/

Juancarlo Añez

Posts: 12
Nickname: juanco
Registered: Aug, 2003

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jul 1, 2009 1:45 AM
Reply to this message Reply
No. There *are* design flaws in C++.

The worst one was to keep the code inclusion paradigm module usage, more so when the generics libraries were created.

Still C++ was *the* language that allowed us to learn about OO during the 90's, specially how things should not be done.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jul 1, 2009 6:24 AM
Reply to this message Reply
> C++ was arguably nothing more than syntactic sugar on top
> of C. Alt-E, Find, Replace, "class", "struct", Alt-A.
>

It really bothers me when smart and knowledgable people write things like this without taking effort to do a basic check of the facts. Please read this paper, or at least the chapter on Cfront: http://www.research.att.com/~bs/hopl2.pdf

A paragraph from that paper:
"
The most unusual – for its time – aspect of Cfront was that it generated C code. This has
caused no end of confusion. Cfront generated C because I needed extreme portability for an initial
implementation and I considered C the most portable assembler around. I could easily have
generated some internal back−e nd format or assembler from Cfront, but that was not what my
users needed. No assembler or compiler back−e nd served more than maybe a quarter of my user
community and there was no way that I could produce the, say, six backends needed to serve just
90% of that community. In response to this need, I concluded that using C as a common input
format to a large number of code generators was the only reasonable choice. The strategy of
building a compiler as a C generator has later become quite popular so that languages such as
Ada, CLOS, Eiffel, Modula− 3, and Smalltalk have been implemented that way. I got a high
degree of portability at a modest cost in compile time overhead. Over the years I have measured
this overhead on various systems and found it to be between 25% and 100% of the ‘‘necessary’’
parts of a compilation.
Please note that the C compiler is used as a code generator only. Any error message from the
C compiler reflects an error in the C compiler or in Cfront, but not in the C++ source text. Every
syntactic and semantic error is in principle caught by Cfront, the C++ compiler front−e nd. I stress
this because there has been a long history of confusion about what Cfront was/is. It has been
called a preprocessor because it generates C, and for people in the C community (and elsewhere)
that has been taken as proof that Cfront was a rather simple program – something like a macro
preprocessor. People have thus ‘‘deduced’’ (wrongly) that a line−f or−l ine translation from C++ to
C is possible, that symbolic debugging at the C++ level is impossible when Cfront is used, that
code generated by Cfront must be inferior to code generated by ‘‘real compilers,’’ that C++
wasn’t a ‘‘real language,’’ etc. Naturally, I have found such unfounded claims most annoying –
especially when they were leveled as criticisms of the C++ language. There are now several C++
compilers that use Cfront together with local code generators without going through a C front
end. To the user, the only obvious difference is faster compile times.
"

jens odborg

Posts: 2
Nickname: jho
Registered: Oct, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jul 1, 2009 7:00 AM
Reply to this message Reply
boost.org have a true named parameter passing simulation library (don't remember the exact lib name though)

jens odborg

Posts: 2
Nickname: jho
Registered: Oct, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jul 1, 2009 7:05 AM
Reply to this message Reply
As far as I remember Java allow types, fields and functions of the same name, so 'new' is required to distinct between function and constructor calls.

Flat View: This topic has 89 replies on 6 pages [ « | 2  3  4  5  6 | » ]
Topic: First Steps in Flex: 6 Screencasts Available Previous Topic   Next Topic Topic: A Generic Ostream Iterator

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use