The Artima Developer Community
Sponsored Link

C++ Community News Forum
The Problem with Programming

212 replies on 15 pages. Most recent reply: Dec 8, 2006 6:12 AM by James Watson

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 212 replies on 15 pages [ « | 1 2 3 4 5 6 7 ... 15  | » ]
Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 5:29 AM
Reply to this message Reply
Advertisement
Normally I would say many things about BS and C++, but my disappointment is so high I do not think I can spare my energy on that.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: The Problem with Programming Posted: Nov 29, 2006 5:51 AM
Reply to this message Reply
Alex -

> In fact, it is Java crowd that often forgets to
> acknowledge the giant's shoulders on which it stands and
> Stroustrup points it out in the interview.

I don't know who "Java crowd" is, but likely many of them never programmed in C++, just like many C++ programmers never used C. By golly, it pisses me off that C++ programmers talk about BS but give no love offerings to K&R.

As for Java, it kept almost the entire C++ syntax. The English language would have a much easier time disclaiming its Romantic and Germanic roots.

> In the light of
> recent push back to functional programming roots it is
> clear that Java architects have failed in that realm. Neal
> Gafter's blog at
> http://gafter.blogspot.com/2006/11/reified-generics-for-ja
> va.html
> shows where Java architects have gone wrong with respect
> t to generic programming.

This is an untenable line of argument.

The idea that any one language can be all things to all people is a pipe dream. Java is not a functional programming language, so it's going to be sub-par (at best) for functional programming problems, and in this case it is an atrocious fit in the cases that I have seen.

> Because of the language
> shortcomings, the Java "productivity" argument is a bogus
> one. A seasoned C++ programmer actually more productive
> than his Java peer because his tool is much more powerful
> and versatile.

Having heard the same arguments about C being more productive than C++, I have to point out again that this is a completely untenable line of argument.

C++ would likely be -- by your definition -- less productive than C which in turn would be less productive than assembly which would in turn be less productive than machine code.

Having coded extensively in all of the above (hex, asm, C, C++ and Java), I can tell you that each progression has been a huge leap forward in my own productivity, in return for a wholesale jettisoning of raw capability (except for the hex->asm transition).

Of course, I would prefer to believe it attributable to my own skills improving over time, but unfortunately I have witnessed the same jumps in productivity in almost every other programmer that I have seen making the same transitions. The only exceptions were all specialized areas of programming that required capabilities that Java attempted to extinguish from the language, such as direct memory access and pointer arithmetic.

> Admittedly, to learn how to properly use
> the tool is much harder in C++ case, but there are no
> shortcuts to any place worth going to.

Your statement is a thinly-veiled attempt to rationalize your cummulative investment in your C++ skill-set. I have some very sobering news for you about how quickly our industry evolves, and how rapidly and steeply such investments devalue.

I am already seeing the leading edge of the Java continent crumbling into the onrushing sea, so I hope to figure out what comes next so I can stave off my own inevitable obsolescence.

And if not, come back to this forum in five years and find me complaining bitterly about how the language X crowd does not pay adequate homage to its Java lineage. ;-)

Peace,

Cameron Purdy
http://www.tangosol.com/

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 6:32 AM
Reply to this message Reply
> I am already seeing the leading edge of the Java continent
> crumbling into the onrushing sea, so I hope to figure out
> what comes next

Out of curiosity, what are your thoughts on this, if any?

> so I can stave off my own inevitable
> obsolescence.

I appreciate the humility and all but give me a break. You clearly have skills that are much more long-lasting than knowing how to use language X, as I hope I also do. These skills are more rare and valuable and are what a programming language should attempt to harness most efficiently. It's clear to me that C++ fails miserably in this regard. Java, while a good step forward is also falling into glued together crustiness lately.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: The Problem with Programming Posted: Nov 29, 2006 7:10 AM
Reply to this message Reply
> As for Java, it kept almost the entire C++ syntax.

Java syntax is fine with me. I even happen to like it. It is the language restrictions that I find troubling. I really, really do not like when someone gives me a quarter of a language and tells me it is for my own good. Please, let me be the judge of that.

> C++ would likely be -- by your definition -- less
> productive than C which in turn would be less productive
> than assembly which would in turn be less productive than
> machine code.

There is an old saying "in medio stat virtus", and C++ is right there - providing low-level access and performance alongside the high-level software design abstractions with very low (sometimes even zero) price to pay. Nothing is panacea, and interview points it straight out. C++ is like the western-style democracy - not perfect at all (and it shows all the time), but the best thing human kind has been able to come up with so far. Attacks from both sides (C and Java) only confirm this.

> I am already seeing the leading edge of the Java continent
> crumbling into the onrushing sea, so I hope to figure out
> what comes next so I can stave off my own inevitable
> obsolescence.

I wish you good luck in your quest for the-next-big-thing. If I were you, I'd rather check recent market demand figures for programming skills.

As it currently stands, C/C++ beats the heck out of everyone else:

http://media.corporate-ir.net/media_files/priv/pr_130608/DiceAug06.pdf
http://media.corporate-ir.net/media_files/priv/pr_130608/DiceNov06.pdf


> And if not, come back to this forum in five years and find
> me complaining bitterly about how the language X crowd
> does not pay adequate homage to its Java lineage. ;-)

Your way is the way of the corporation-of-the-day-language follower. My way is the best-of-breed-language follower. Once I encounter a language better suited to solve the problems I am dealing with and not aimed to lock me into a corporate technology cage, I'll switch. However, you may rest assured that it will not be because a corporate marketing machine told me so. "Success" of Java (if there is such thing) is hardly a surprise given the marketing machines backing it up - after all, as A. Stepanov rightfully pointed out in one of his interviews: MS DOS was successful, too.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 7:24 AM
Reply to this message Reply
> As it currently stands, C/C++ beats the heck out of
> everyone else:
>
> http://media.corporate-ir.net/media_files/priv/pr_130608/Di
> ceAug06.pdf
> http://media.corporate-ir.net/media_files/priv/pr_130608/Di
> ceNov06.pdf

Since we are at it. Has anyone an explanation for the growth of interest in VB? After all there seems to be a silent majority that seems not to affected by the discussions of frustrated, mostly idealist programmers.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 7:40 AM
Reply to this message Reply
> As it currently stands, C/C++ beats the heck out of
> everyone else:

Interesting, but far from convincing. Firstly, it combines two languages (.Net isn't even a language per se). Secondly, I've seen this on many job postings where the employer doesn't actually use C or C++. I believe this is because someone who knows C or C++ will have no trouble with the syntax of Java or C#. The report would be a lot more interesting if it had more than two listings.

I would wager that the most common language in business today is COBOL. That doesn't mean COBOL is a great language. There's just a lot of code to maintain. Once a business has invested a lot of money developing code in a specific language, it's rarely cost effective to rewrite the whole thing in another language. Even if a company is moving away from C++, they will need C++ developers. I worked on a team that used PowerBuilder. No one on my team wanted to use it and we started using Java for new development. Suddenly we needed more PowerBuilder developers.

A more interesting (and more relevant) study would focus on what languages are used for new development.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 7:44 AM
Reply to this message Reply
> Since we are at it. Has anyone an explanation for the
> growth of interest in VB? After all there seems to be a
> silent majority that seems not to affected by the
> discussions of frustrated, mostly idealist programmers.

Honestly, even though I detest VB as a general programming platform, it's really a productive tool for writing guis. Now that it is under the .NET umbrella, it could used to create a front-end around a C# core, for example.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 7:55 AM
Reply to this message Reply
> There is an old saying "in medio stat virtus", and C++ is
> right there - providing low-level access and performance
> alongside the high-level software design abstractions with
> very low (sometimes even zero) price to pay.

The price that you are ignoring is how much time and effort it takes to master C++. Knowing all the ins-and-outs of the language is like memorizing a dictionary. You are also ignoring that the constant march forward of compiler optimization is erasing these performance benefits rapidly. For example there is convincing evidence that Java's heap management allows for faster Object creation than C++. Future enhancements will allow for transparent stack allocation of objects and other runtime optimizations in Java.

I'm not saying that there isn't a place for a language with the features of C++. I'd say that perhaps it's time to create a new language that fills this niche and jettisons the baggage of the history of C and C++. There's just too many overlapping syntaxes and abstractions and features that just aren't really needed and necessary features that are jury-rigged.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The Problem with Programming Posted: Nov 29, 2006 8:02 AM
Reply to this message Reply
> Has anyone an explanation for the
> growth of interest in VB?

For front end stuff...

It's simple. It works. It can be used by people without a degree in computer science and twenty years expeience. And, unlike Java, it is possible to produce usable GUIs on projects that aren't IDEs underwritten by Sun or IBM.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: The Problem with Programming Posted: Nov 29, 2006 8:05 AM
Reply to this message Reply
> Interesting, but far from convincing. Firstly, it
> combines two languages (.Net isn't even a language per
> se).

C/C++ are not two languages. Although not strictly true, for all practical purposes C++ is a superset of C. So you can use C++ as "better C" if you refuse to use classes and templates. If you want the reason why would anyone do that, take C++ sort as an example - it's quicker than the C one.
And then, you're right, .NET is not one language and C++ is included in the package.

> Secondly, I've seen this on many job postings where the
> employer doesn't actually use C or C++. I believe this is
> because someone who knows C or C++ will have no trouble
> with the syntax of Java or C#.

If it's true that C++ knowledge is the reason to include it in ads for C# or Java programmers (which I doubt is majority of it), it speaks for itself about merits of C++ knowledge and the reason is definitely much deeper than mere syntax familiarity.

> A more interesting (and more relevant) study would focus
> on what languages are used for new development.

I have no hard facts, but IMO the statistics most likely have to do with recent embedded development growth and/or the tendency from pure ANSI C to C++ in that arena.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: The Problem with Programming Posted: Nov 29, 2006 8:16 AM
Reply to this message Reply
> I'm not saying that there isn't a place for a language
> with the features of C++.

Obviously, there's a place for any language there is because someone somewhere is using it. The point is, taken everything (I mean *everything*, not just one particular theoretical or practical argument) into account, I have yet to hear a convincing argument for the existence of a better general-purpose language. But, that's just me.

> I'd say that perhaps it's time
> to create a new language that fills this niche and
> jettisons the baggage of the history of C and C++.
> There's just too many overlapping syntaxes and
> d abstractions and features that just aren't really needed
> and necessary features that are jury-rigged.

One can argue the same for human languages and English in particular. Esperanto anyone?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 8:27 AM
Reply to this message Reply
> > Interesting, but far from convincing. Firstly, it
> > combines two languages (.Net isn't even a language per
> > se).
>
> C/C++ are not two languages. Although not strictly true,
> for all practical purposes C++ is a superset of C. So you
> can use C++ as "better C" if you refuse to use classes and
> templates. If you want the reason why would anyone do
> that, take C++ sort as an example - it's quicker than the
> C one.

Just to be clear, I've written a fair amount of code in C++. It was a good while ago but I used it for most of my university projects and was required to use it in many CS classes. One of the main things I learned about C++ was a a collection of features to avoid using.

If these aren't separate languages, then why not list just C++? If a team is just using C++, I find it unlikely that someone who knows only C is going to be adequate, unless they expect to train them. The big problem with these features is that job postings rarely list one language.

> If it's true that C++ knowledge is the reason to include
> it in ads for C# or Java programmers (which I doubt is
> majority of it), it speaks for itself about merits of C++
> knowledge and the reason is definitely much deeper than
> mere syntax familiarity.

It speaks to the merits of the developer, not the language. Of a developer knows C++, they will be able to move to Java or C# easily because they are based on a paired-down syntax with some extensions simplified programming model.

When my grandfather was 8, he used to drive a truck with a planetary transmission which, as I understand it, was quite complicated to operate. This system fell out of favor long ago and has been replaced by the much simpler manual transmission and automatic transmissions we use now. I'm sure making the transition to the simplified system was easy for him but that doesn't make the more complicated system superior, in fact I argue the opposite.

> > A more interesting (and more relevant) study would
> focus
> > on what languages are used for new development.
>
> I have no hard facts, but IMO the statistics most likely
> have to do with recent embedded development growth and/or
> the tendency from pure ANSI C to C++ in that arena.

Well, in a decade or so, expect to see a huge growth in the demand for COBOL developers and also growth in their salaries. I don't think you'll argue this means that COBOL is the way of the future.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming Posted: Nov 29, 2006 8:30 AM
Reply to this message Reply
> One can argue the same for human languages and English in
> particular. Esperanto anyone?

The spoken languages we use are not 'designed', programming languages are. Well, perl could be an exception.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: The Problem with Programming Posted: Nov 29, 2006 9:08 AM
Reply to this message Reply
> Yes, garbage collection has made many things easier and
> more robust. But Java makes it very hard to write
> libraries and frameworks that provide high level
> abstractions to the user. In my opinion, that's why J2EE
> has become such a monster and Java programmers need so
> many tools to generate, post-process and deploy code.

That's a possible interpretation. Here is mine: J2EE is complex because it solves complex problems.

I have surveyed and even worked on "J2EE-like" solutions written in C++, and trust me, it was not pretty.

Why? Because C++ doesn't have standard libraries for "modern programming" (multithreading, remotability, security, servlets, introspection, dynamic loading, etc...), so you end up reusing non-standard ones or rolling your own. Add this to the intrinsic complexity of the language, its non-portability and still very-buggy compilers, and you'll quickly find out why Java is more productive.

> Dynamic languages provide more facilities for abstraction
> as part of the language, but at a high performance cost

It depends what kind of performance you need. If Java is good enough for the likes of Google, Yahoo and eBay, surely it's good enough for a lot of people...

> and without any kind of compile time checking.

How so? Both languages are equally strongly typed.

> And in that sense, there is no way to
> objectively tell whether one language is more productive
> than the other.

A large number of people will disagree with that assertion...

--
Cedric
http://testng.org

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: The Problem with Programming Posted: Nov 29, 2006 9:15 AM
Reply to this message Reply
> > I am already seeing the leading edge of the Java continent
> > crumbling into the onrushing sea, so I hope to figure out
> > what comes next

> Out of curiosity, what are your thoughts on this, if any?

I have lots of thoughts on it, but I'm not sure how "timeless" they are because they are likely more _reaction_ to those failings that I see in Java and other languages than _vision_ of how things should be. (As but one example, I think C# is an excellent example of a result of myopic "here's how I would have done it" thinking.)

I would suggest some general attributes of languages moving forward, as opposed to concrete predictions; note that I couch these vis-a-vis Java:

* The object-based programming metaphor will likely be retained by the next major language wave, just because it is [relatively] well-understood by the current generation of programmers.

* I would expect that both "AOP" and "inheritance" as separate concepts from composition will disappear. It seems logically obvious to me that "mix-ins" and "inheritance" and "composition" and "aggregation" are all just facets of the same basic concept, and it should be possible to cleanly merge them. Ruby is likely halfway there already.

* Similarly, there will be no fundamental difference between an interface, an abstract class and a concrete class.

* The divide between primitive types and reference types (and related topics such as boxing) will likely disappear, although all the above will obviously still exist at some level (just as a pointer to a pointer to an array of function pointers exists in C++, but we choose to refer to it as an object).

* To eliminate primitive types and be broadly deployable to many platforms while providing efficiency close to current languages / runtimes, the virtual machine will have to define all types as we currently define interfaces, but it will also have to define the behavior of those types as the language defines final classes (such as boxing classes: Integer, String, etc.) in Java. In other words, the programmer will likely treat all types as objects (including intrinsically machine-supported types), yet the runtime will have the choice of "inlining" the functionality (e.g. "native" methods in Java, as well as specific methods that Hotspot has hard-coded awareness of) versus using the "default runtime library" implementation.

* At a low level, the "word" size may be 64-bit, but many platforms (mobile included) will probably stay 32-bit for the next 5 years. That means that the language should largely mask the detail of the word size (including array offsets, etc.) from the programmer. This would imply that an array type (for example) would itself be an interface, with the index operations being parameterized using a more abstract index type (e.g. "number"). Again, the Hotspot type technology is responsible for avoiding Smalltalk-like performance, but the language (VM in this case) needs to be designed explicitly to facilitate that.

* Intrinsic decimal type (IEEE 754r) are a sorely missing feature of Java and other languages. FP (binary and decimal) will need to support at least 32/64/128-bit. Unfortunately, no higher precision standard exists yet (e.g. 256 bit).

* All aspects of the objects will be conceptually virtual invokes, including properties (nee fields), methods and constructors. Obvious minor implications: No more accessor / mutator boiler-plate. No more boiler-plate factories (virtual "new").

* The language run-time needs to be designed for virtualization. Java is a b*tch to virtualize due to a complete lack of modularization within the VM (classloader partially excepted).

* R.I.P. fields, "static", "interface". These are left-over language anachronisms.

* The runtime will itself be completely visible within the runtime. Reflection, introspection, dynamic classes -- these are just the tip of the iceburg. What about variables? They are objects too. Instructions? The stack frame? Almost everything the runtime does should be expressable in terms of the same building blocks that one builds applications from (i.e. object classes).

* Exposing the runtime in detail in terms of the same model as applications employ, and driving toward more virtualization will mean that security can no longer be an after-thought. A closed-loop, archtitected-in, provable security model will be required.

The only question is do we just want an incrementally better Java (which would likely break backwards compatibility), or is it a fundamentally new language / runtime. My guess is that we'll see both.

> > so I can stave off my own inevitable
> > obsolescence.

> I appreciate the humility and all but give me a break.
> You clearly have skills that are much more long-lasting
> g than knowing how to use language X, as I hope I also do.

The problem isn't skills, it's attitude. People get old and [mentally] brittle just as code does, and we get stuck in our old ways. I assume that I am no more immune to that than other people, such as obviously-smart people like BS.

Peace,

Cameron Purdy
http://www.tangosol.com/

Flat View: This topic has 212 replies on 15 pages [ « | 1  2  3  4  5  6  7 | » ]
Topic: Pantheios 1.0.1 full release approaching; beta 17 just released Previous Topic   Next Topic Topic: John Ousterhout on What Limits Software Growth

Sponsored Links



Google
  Web Artima.com   

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