Weblogs Forum - The Elephant in the Living Room

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Elephant in the Living Room

38 replies on 3 pages. Most recent reply: May 2, 2005 3:11 PM by Terje Slettebø

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 38 replies on 3 pages [ « | 1 2 3 | » ]

indranil banerjee

Posts: 38
Nickname: indranil
Registered: Nov, 2004

Re: The Elephant in the Living Room

Posted: Apr 11, 2005 11:52 AM

There are people doing creative application development in C++. Look at http://code.google.com or http://opensource.adobe.com

There's is plenty more stuff being done by smaller groups and individuals. They just seems to have a much lower profile than many other projects.

I'd love to see more articles about these projects here at artima

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why?

Posted: Apr 12, 2005 3:04 AM

> I asked myself that question years ago when I abandoned
> the language for application development. C++ is a
> horrible language for business apps. I see its use for
> systems programming and libraries and not much else.

This got me thinking. What are the ten most successful applications across the board (most successful OS, office suite app, game, server, email client, IDE, etc.) and what languages are they written in? Better still, what language should they have been written in an why?

V.

Jordan Zimmerman

Posts: 23
Nickname: jordanz
Registered: Jul, 2003

Re: The Elephant in the Living Room

Posted: Apr 12, 2005 12:44 PM

C++ has become a mess. When Stroustrup alone controlled it, it was beautiful. C++ looks like it was designed by committee because it WAS designed by committee.

Open up any one of the headers and try to figure out what functions are available or what the heck it's supposed to do.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room

Posted: Apr 12, 2005 8:11 PM

> C++ has become a mess. When Stroustrup alone controlled
> it, it was beautiful. C++ looks like it was designed by
> committee because it WAS designed by committee.
>
> Open up any one of the headers and try to figure out what
> functions are available or what the heck it's supposed to
> do.

I've been heavily involved with the D programming language - aimed, in part, at addressing some of the flaws of C++ - over the last 3 years, and it's been some initiation into the soul-destroying phenomenon that is DBC. Now I know what people talk about when they whisper "design by committee", and can imagine all those ruined lives. ;)

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: The Elephant in the Living Room

Posted: Apr 13, 2005 11:02 AM

>I think there's agreement that: templates seem to be
>mainly about facilitating efficiency, rather than doing
>what couldn't otherwise be done.

I don't agree on that. Yes, templates also enables efficient code, but that's only one part of it. Another is that it enables generic programming, so, as someone said it, templates has turned out to be perhaps C++'s most important contribution to the field of computing. (Yes, Ada had something like templates before it, but for one thing, they required explicit instantiation). Templates allow you to write generic code (STL being one example), where the components are decoupled from each other, in a way you can't do with OO. An example:

template<class T>
T some_operation(const T &value) {...}

This provides an operation for any type T (where it compiles; I'll come to that). So with _one_ such function template, you save writing an unbounded number of function definitions, each for a specific type. Also, it'll work for types not even existing, when the function template was first written.

This is something you just can't get, with anything else, in C++. And it's only the tip of the iceberg, of what you can do with templates.

However, one problem is the incomprehensible error messages you may get, if you try to use the above function template for a type it doesn't work with. The C++ community (and the standards committee in particular) are currently looking into ways of solving this problem, by including support for "generic concepts" in the language (papers can be found here, search for "concept": http://www.open-std.org/JTC1/SC22/WG21/docs/papers/)

>I think the template end of C++ also currently appears
>harder because it's rather divergent from usual
>languages/programming, and despite the syntax the
>programmer doesn't really have finished material to work
>with.

As with most things, you need to learn it to understand it. That goes for other "paradigms", like OO, as well. However, there are issues even for experienced programmers, as mentioned above.

>Even after the standard is printed, the language is not
>finished. Because (from Wittgenstein) "language is a form
>of life" -- it is not a self-contained logical structure,
>but a reflection of what humans are and do.

That's right. I'm pleased that the interest in improving C++ is as high as ever (see for example this "wish list" of the committee: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1598.html).

>In a reduced
>sense its probably similar in programming. What we do with
>the language, is the language. And the community hasn't
>used templates enough to define their culture.

Quite a number of people has (like the Boost crowd).

>If lack of culture is an impediment, then such things as
>other languages must be a good source of ideas for
>template patterns...

Maybe. Can you think of some of this?

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Why?

Posted: Apr 13, 2005 11:17 AM

>Why are smart people attracted to C++? I concluded that
>its because C++ itself is just the damndest puzzle. Like
>chess, the number of permutations is astronomical.

Personally, I'm attracted to it for not at least the powerful abstractions it gives you, and the resulting size of the design space. In comparison, most other languages seems either rather simple (so your code has to be complex, instead, or having huge libraries), or "one size fits all"-abstractions ("everything is and object", "everything is a function", etc.). I like that C++ doesn't enforce a particular programming style or paradigm on you, and offers several, as they are useful for different purposes.

>In order to understand any single line of a C++ program,
>you must understand the entire program. You must know what
>operators are overloaded, what type conversions might be
>performed, what all of the single argument constructors
>are that are not marked explicit, any operator type
>methods, which things are passed by value vs reference,
>etc.

I've heard this complaint from many C++ critics. You may approach it from the "wrong" angle: If you approach a C++ program with the mindset that you want to know every detail of what's going on there, then you're probably better off with something like C, which provides a much closer one-to-one mapping between source code and generated code. However, one point with abstractions is that you don't _have_ to know every little detail (even though you can find out, if you want to), to understand the code, and in fact, if you had all the zillion details on the same level of abstraction, it could be very hard to see what the code - in total - actually did.

Take this line:

std::cout << "Test";

This writes the line "Test" to the console. Is that hard to understand? Do you need to know that the "<<"-operator is overloaded, and that "std::cout" is an object, to write the above? Not really. Thus, you can concentrate on what you want to accomplish, rather than how it is implemented. And C++ is great for building abstractions.

>The addition of a single method can radically change the
>behavior of the entire program. Thus, I concluded, C++
>does not scale to large projects well.

People with very large systems in C++ will likely disagree with you... Take applications like Microsoft Office, for example.

Have you found a language that you found to be better for this, in your opinion?

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: The Elephant in the Living Room

Posted: Apr 13, 2005 11:26 AM

>C++ has become a mess. When Stroustrup alone controlled
>it, it was beautiful. C++ looks like it was designed by
>committee because it WAS designed by committee.

Some of it is probably because it was "designed by committee" (although much of the language, as it is today, was done before a committee was set up); even committee members agree on that. std::string is one example, with a large interface. However, std::string works quite well in general.

However, much of the "mess" in C++ s there for historical or compatibility-reasons (with C, and itself). For example, if compatibility with C (and millions of lines of existing C++ code...) wasn't important, you could have tightened up the type system quite a bit more, for example. However, such backwards compatibility _is_ important. Successful languages tend to become big and complex: look at how Java and its libraries have become: it's not a small language, anymore.

Regards,

Terje

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 2:27 AM

> ...look at how Java and its libraries have become:
> it's not a small language, anymore.

Interestingly, if you open the Python cupboard, you'll hear talk (see http://www.artima.com/weblogs/viewpost.jsp?thread=98196) of actually removing long standing features, in order to simplify the language.

Vince.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 7:11 AM

"Templates allow you to write generic code (STL being one example), where the components are decoupled from each other, in a way you can't do with OO. An example:

"template<class T> T some_operation(const T &value) {...}

"This provides an operation for any type T (where it compiles;"

You can do generic code in Smalltalk, Python, Ruby, etc., without special syntax, without having to have a common base class, and without having to recompile. You can do generic code in Objective-C with the limitation of using only objects.... the equivalent of the above, for example, in Objective C is:

id some_operation( id value ) {...}

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 8:12 AM

> You can do generic code in Smalltalk, Python, Ruby, etc.,
> without special syntax, without having to have a common
> base class, and without having to recompile. You can do
> generic code in Objective-C with the limitation of using
> only objects.... the equivalent of the above, for
> example, in Objective C is:
>
> id some_operation( id value ) {...}

Could you clarify this? I don't see how it works. The body of the template function would have stuff like this:

template<class T> T some_operation(const T &value)
{
   value.doThis();
   value.doThat();
   SomeThing something("else");
   value.doAnotherThingWithThisThing( something );
   value.etc();
   return value;
}

What would your "id" code look like?

Jordan Zimmerman

Posts: 23
Nickname: jordanz
Registered: Jul, 2003

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 9:58 AM

>std::string is one example, with a large interface

std::string is a perfect example. Before the committee, it was great. You could open the header file and actually understand what it was doing and what the available functions where. Then STL and the committee came along and look at that header now. You need a magnifying glass.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Templates vs Dynamic Typing

Posted: Apr 14, 2005 12:17 PM

Templates are kind of a code generation hack to simulate dynamic typing.

template <class T> const T& max(const T& t1, const T& t2)
{
return t1 > t2 ? t1 : t2;
}
class A { int _x; public: A(int x) : _x(x){} };
max(3,5) - works
max(2.2,4.1) - works
max(A(2),A(3)) - won't work

why? Because A doesn't respond to protocol for > comparison. Templates give you a mechanism to code to the protocol of a receiver rather than its inheritance hierarchy like you have to with non-template code.

Dynamically typed languages like Smalltalk work entirely on protocol rather than inheritance hierarchy. So template programming has much more in common with Smalltalk than with pre-template C++. Which I suspect is why C++ developers find it so useful. Its the best illustration of why C++'s original strongly checked type model based on inheritance was a mistake.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Why?

Posted: Apr 14, 2005 12:19 PM

"I like that C++ doesn't enforce a particular programming style or paradigm on you, and offers several, as they are useful for different purposes."

Yes, but its not particularly good at any of them. I prefer a nice scalpel for surgery over a swiss army knife.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 7:40 PM

// "id" is the generic objective-c object type...
// Translating the C++ example into objective-c syntax...

// in header file:
id some_operation( id value );

// in source file:
id some_operation( id value )
{
[ value doThis ];
[ value doThat ];
[ SomeThing * something = [[SomeThing alloc] init: "else" ];
[ value doAnotherThingWithThisThing: something ];
[ value etc ];
[ something release ];
return value;
}

Now, this code will work with any object whose class implements methods named "doThis", "doThat", "doAnotherThingWithThisThing", and "etc", regardless of that class's inheritance... no common base class is required.

If you have defined a common base class, then you can of course, use that type like so:

// in header file:
CommonBase* some_operation( CommonBase* value );

// in source file:
CommonBase* some_operation( CommonBase* value )
{
[ value doThis ];
[ value doThat ];
[ SomeThing * something = [[SomeThing alloc] init: "else" ];
[ value doAnotherThingWithThisThing: something ];
[ value etc ];
[ something release ];
return value;
}

... and get the same behavior.

Bruce Eckel has a nice essay somewhat related to this, using Python. Check it out: http://www.mindview.net/WebLog/log-0025

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room

Posted: Apr 14, 2005 9:14 PM

Using shims (described in http://www.cuj.com/documents/s=8681/cuj0308wilson/ and in Chapter 20 of Imperfect C++) it's possible to achieve a similar generalised, non-template, behaviour, based on the conformance of syntax.

It's not widely applicable in the sense of constructing a multi-faceted function such as is seen in some_operation(), but it is a very powerful technique, as uses of the STLSoft libraries will be aware.

Using the c-string shims c_str_ptr(), c_str_len(), c_str_data() one can implement classes that use 'strings' to work seamlessly and efficiently with _any_ type that has a useful (and defined) conversion to string form, whether that be a char const *, ::std::basic_string<>, ACE_Time_Value, HWND, etc. etc.

Indeed, I've written logging infrastructures - working on one right now, in fact - which uses these shims to make generic logging interfaces that address shortcomings of Xprintf() (type-safety) and iostreams (lack of atomicity of statement output) without any compromise of robustness, simplicity or efficiency.

Flat View: This topic has 38 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic