The Artima Developer Community
Sponsored Link

Weblogs Forum
Why? Language Archaeology ... and Metaprogramming

89 replies on 6 pages. Most recent reply: Sep 14, 2009 7: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 | » ]
Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 18, 2009 2:27 PM
Reply to this message Reply
Advertisement
>
> I am fairly sure that the reason was a familiar one:
> backward compatibility with C++.

I've always called this hidebound-compatibility. In other words, most people won't jump to a new language if it differs too much from what they're used to. C++'s real compatibility with C added real value, while Java's was strictly marketing to hidebound programmers. Not exactly the optimum criteria for designing a new language.

Jack Diederich

Posts: 6
Nickname: jackdied
Registered: Mar, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 18, 2009 3:14 PM
Reply to this message Reply
Bruce, sorry your PyCon plans were derailed; I would have loved to compare notes. Video of my PyCon talk "Class Decorators: Radically Simple" on class decorators/metaclasses is online (http://blip.tv/file/1949345). There is a link to my slides in the comments.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 5:09 AM
Reply to this message Reply
> > That's not pass-by-name arguments. That's function
> > chaining.
>
> He did say simulated

Sorry, it does not simulate pass-by-name arguments. What it does is to allow you to chain function calls.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 9:10 AM
Reply to this message Reply
Simulating pass-by-name arguments by using chained function calls.

It's called the 'Named Parameter Idiom'

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 9:49 AM
Reply to this message Reply
Java contains "boilerplate" code, which adds to the volume of code "weighs" it down. Victorian engineers (such as Brunel) designed boilers (made from big sheets of heavy boilerplate) for their steam engines.

It's an aliterative metaphor and like all metafors, it falls apart when examine it too closely.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 9:54 AM
Reply to this message Reply
> Simulating pass-by-name arguments by using chained
> function calls.
>
> It's called the 'Named Parameter Idiom'
>
> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18

How come it simulates named parameter passing? simulated named parameter passing would be something like this:


fopen(name = "foo", size = 3456, access = Exclusive);


The function call chaining idiom produces a very different visual result which is not reminiscent of passing parameters:


fopen(FOpen().name("Foo").size(3456).access(Exclusive));


When browsing code, the former sticks out as a function call, the later does not.

Aside from that, in both cases, the work required for the solutions to work is too long and too boring. It's something that the compiler must provide.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 10:28 AM
Reply to this message Reply
> Java contains "boilerplate" code, which adds to the volume
> of code "weighs" it down. Victorian engineers (such as
> Brunel) designed boilers (made from big sheets of heavy
> boilerplate) for their steam engines.
>
> It's an aliterative metaphor and like all metafors, it
> falls apart when examine it too closely.

Ah, OK. I thought you were saying his designs contained unnecessary elements or something (which might be true.) I was reading into it a little too much, I guess. Actually, thanks for the background of 'boilerplate'. I never made that connection before.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 12:12 PM
Reply to this message Reply
> The function call chaining idiom produces a very different visual result
> which is not reminiscent of passing parameters:
> fopen(FOpen().name("Foo").size(3456).access(Exclusive));

It's a different visual result, I'm not so sure about "very".

At any rate, it was deemed close enough by the members of the C++ committee that the proposal to add named parameters was scrapped (even the author of the proposal agreed that this was a pretty good solution and he was happy to withdraw his proposal).

There is a downside to this approach, though, which is much less subjective than "it's boring". I'm surprised you're not pointing it out...

> Aside from that, in both cases, the work required for the solutions
> to work is too long and too boring. It's something that the compiler
> must provide.

Let's just say that a lot of people would disagree with you about this, and that named parameters are a feature that is very, very hardly ever requested from C++ any more. And from a lot of languages, actually.

--
Cedric

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 19, 2009 1:10 PM
Reply to this message Reply
> There is a downside to this approach, though, which is
> much less subjective than "it's boring". I'm surprised
> you're not pointing it out...

Do you mean about side effects and evaluation order?

> Let's just say that a lot of people would disagree with
> you about this, and that named parameters are a feature
> that is very, very hardly ever requested from C++ any
> more. And from a lot of languages, actually.
>

I was not talking about people desiring it, but about how the flaws of C++ do not depend entirely on compatibility with C. The named parameters feature was just an example.

dark mx

Posts: 7
Nickname: darkmx0z
Registered: Mar, 2008

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 20, 2009 2:09 PM
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.

you like to troll sometimes :) but I think this is not the case, your arguments were good

> Some examples:
>
> 1) the distinction between classes and non-classes types.
> All types could have been classes, even primitives.

Agree. Some minor changes could have been done here and there (for example, inheriting from a primitive is something I am sure most C++ programmers have wished at least once, yet we can't do 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.

This is purely C compatibility

> 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.

Agreed. Reusing default keyword could have worked.

f(1, default, 2);

Google doesn't like default parameters for good reasons, but given that we already have them, we could make them more useful.

> 4) lack of pass-by-name parameters. Why C++ doesn't have
> it? there is nothing that has to do with C combatibility.

This is discussed in Stroustrup's Design & Evolution of C++. Headers are the main problem (you are not forced to use the same name for parameters in a declaration and the definition, this could bring maintenance chaos).

> 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.

They look nice, but I agree with you.

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

Irrelevant I think. Its ugly but simple enough.

> 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.

I think I agree.

> 8) lack of tail call optimization. Again, nothing to do
> with C compatibility.

Compilers are better here and any current problems are C's fault (calling scheme and varargs).

> 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.

Agreed but not Stroustrup's fault. Compilers back in 1970 were required to be fast and simple ones. When technology was permitting, a lot of work was already needed to finish the ISO C++98 specification and a lot of work is still being done for C++0x. Since this is obviously useful, I think this is more a matter of manpower and time.

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

Completely agree.

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

Completely agree. Modules (unfortunately not ready for C++0x) will help here, so again its matter of manpower and time (which is sad anyway).

> 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{}.

I don't like C++0x's choice but I agree with everything else.

> There is a lot more of this stuff. The list of things that
> could have been better contain a lot of items.

Completely agree but Stroustrup couldn't predict the future. If he knew what he knows now, several things would be different. You can't hardly innovate without making mistakes (yet any resulting mistakes were analized before the decision was made and they were considered not to be mistakes back then, it was not that easy).

Bruce I loved your article. I hate when some programming language tries to sell itself as "NAME_HERE but done well". It reminds me of Gosling's blog entry "Java is now faster because the VM learned how to use alloca for optimizations which beats the pants of C's malloc!" Obviously Gosling never says "but C always uses alloca, malloc is explict and special-purpose and C doesn't need to allocate quarter a gigabyte upon the program's entry to be fast".

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 22, 2009 11:15 AM
Reply to this message Reply
Jeff -

> I've always called this hidebound-compatibility. In other
> words, most people won't jump to a new language if it
> differs too much from what they're used to. C++'s real
> compatibility with C added real value, while Java's was
> strictly marketing to hidebound programmers. Not exactly
> the optimum criteria for designing a new language.

I think a compelling argument could be made for just the opposite, since Java provided real value out of the gate that wasn't possible in C++, while C++ provided nothing out of the gate that wasn't possible in C.

Ultimately, the demise of C++ will result from its inability to add sufficient value to C without adding even more sufficient entropy.

Peace,

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

Jordan Zimmerman

Posts: 5
Nickname: randgalt
Registered: Dec, 2008

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 22, 2009 4:40 PM
Reply to this message Reply
As an early user of C with Classes I suggest that the problem with C++ was the committee. Design by committee is a terrible way to extend a language. C with Classes was excellent and easy to understand. In my opinion, everything the committee did to C++ made it more obtuse until it finally became unusable (for me).

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 22, 2009 4:48 PM
Reply to this message Reply
I think most of us would agree that C++ has become hard to use today, but given the success of C++ overall, I would argue that it qualifies as an exemplary success story for the concept of Design by Committee...

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 23, 2009 7:36 AM
Reply to this message Reply
> I think most of us would agree that C++ has become hard to
> use today, but given the success of C++ overall, I would
> argue that it qualifies as an exemplary success story for
> the concept of Design by Committee...

Not all successful things are good things. For example, Betamax was better than VHS; or the Mac was better that the IBM PC/XT.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Why? Language Archaeology ... and Metaprogramming Posted: Jun 23, 2009 10:48 AM
Reply to this message Reply
> Not all successful things are good things. For example,
> Betamax was better than VHS;

Considering that BetaMax only allowed for 60 minutes of recording compared to VHS's 3 hours, that's quite a strange thing to say.

As for programming languages, defining success by anything else than popularity is quite odd, to say the least.

You seem to have a thing for underdogs, but you have to realize that the criteria you use to assess technologies don't appear to be shared by a lot of people...

--
Cedric

Flat View: This topic has 89 replies on 6 pages [ « | 1  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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us