Is C++ getting too complex for today's technology?

As most humans do, we think in an object-oriented mind. Due to today's complexity, usually .NET/Java would fit in this area. Like ASM had to switch to C, C had to switch to C++ due to complexity later. Is C++ about ready to be too complex today?

After noticing the amount of productivity I get for using these languages, I look back at C++ and wonder why it's so obscure to do even the simplest of things. For instance, in DirectX, you're looking at 200-400 lines of code just for a video on the screen. Managed DirectX is around 4 lines. Knowing in 10 years, C++ is going to be too complex for our increasing technology. For some education, C++ did develop Java and .NET from the core, usually in it's compiler & VM. Due to this, we can use Java/.NET to acheive greater power. Due to today's complexity, I'm glad they built these tools. Companies even see a need for these languages to decrease debugging time, and focus more on getting a product done less than the time they thought.

Graphics are always improving, new techniques can be done, and we're reaching the stage of mobile & web technologies. Just think of programming windows with C++. It's a nightmare! Now think of using C++ for every major cell phone. It's too complex, and developing compilers for each one takes time and money. So, for starters with C++'s complexity, is Microsoft/Sun doing us a favor?

I'm a general programmer, so I don't care about taking sides, nor care to start one now. As I've said before in many development forums, programming is not politics. I find a concern here, and I wish to listen to your helpful insight. With that being said, thanks!

dxfoo

I disagree with this. C has been around since the early 70's, and it's still quite popular. Reducing code size drastically probably means you're losing performance, capabilities, or both. Assembly still has it's place, like in a game engine where assembly is often used to give a performance boost. C++ is the same way. It will always have its place despite languages which are less complex.

the key are libraries, not the language itselft in my opinion.

you need a language to actually "talk" with the pc in the most direct, to print a bitmap for example, thus we will always need a low level language.

C++ can act as both low and high level. You can make libraries with C++, now you got nice libraries, you got da PoWa of high level C++ :)

assembly, C and C++ are all still alive and quite well, than you very much. Just because the hardware may be getting more complex does not mean the demise of those languages any time soon -- probably not in my lifetime anyway. MS-Windows is difficult to learn, and X11/Motief for *nix is even more difficult. But after you are over the learning curve (about a year or so of intensive training) its not really that bad.

You use the programming tools for the job you want to do. I wouldn't think of writing a web application with assembly, c or c++. HTML (and variants) for browser clients. I don't know C# so can't comment. Nor would I use HTML or java to write PC business applications, c++ does the job nicely.

Reducing complexity--in this case :)--is all about the level of abstraction. Java, .NET, and the various scripting languages have a higher level of abstraction than C++, so they're simpler to the end programmer. As Dark-MX implied, a library that handles something at a very high abstraction will make a solution in C++ seem simple. The difference is in hiding the complexity behind an easy to use interface. If you take apart Java or .NET, you'll find a lot of complexity that was previously hidden from you by the abstractions.

So is C++ getting too complex for today's technology? I think a better question is "Can C++ adapt to today's more complex problems?" From past experiences, I think so because C++ has been very good at changing to meet the needs of us programmers. There's no reason why we can't step up to the plate and make C++ a better language for todays technology.

Thanks for the great replies. I agree about C++ being alive and well. In fact, it's interesting that even Java can do native calls on C++ code if needed. I'm sure .NET has a way for this, as well.

Personally, I had to think about what my weak areas are. I tend to have a harder time learning a language. It's complexity in DirectX is enough for me to fall dead. I assume I have a simpler mind - not really able to deal with algorithms that take complex code. My mind thinks OO, and maybe I'd benefit myself more of using C# and all the tools it can apply with (MDX, ASP.NET, GDI+, BlueTooth, etc.). I also enjoy platform languages. I have a variety of solutions that can be done with the same language. Something like that excites me. C++ is C++, and indeed, it has thousands of tools.

My C++ teacher told me that his company switched from C++ to VB.NET because easier development time. I notice a ton of application developers are using .NET these days. A friend of mine even uses C# for ASP.NET these days, and hasn't touched C++ for a few years. I see a shift in the next language generation, but of course, C++ code will always exist. Heck, there's enough of it to maintain and upgrade for several of years, even C code. But since my mind works at a slower pace, maybe I should stick to C#. I can already tell that C++ is fine to learn, but the tools used for it is too complex already for me. Maybe I should switch, but I'll continue to read your input. I guess this is more about me than C++, but I know that software companies are switching to it for some obvious reason.

Quote:

---

Originally Posted by dxfoo

TIt's complexity in DirectX is enough for me to fall dead.

---

:D :D I know that feeling very well. Don't think the complexity of DirectX is common throughout all c++ programming! I looked at it, very briefly, then quickily and intentially completly forgot about it. :D

As for game programming -- there are tools out there that let you write complex games without programming even one line of code!

Where's the fun in that? :) I can at least remember what I did in Managed DirectX. I can remember myself saying I can be productive finally and get products out. I think that's worth going for in C#. From ASM to C, even C was abstract to what ASM was doing, and programmers liked it :) I feel the same from C++ to C#. I don't really like the portability constraints, but it's enough using Windows as a platform for income.

Edit: I thought this was an interesting blog entry. It cleared my mind by just knowing that each language is useful in their own way. He quotes, "In summary, C++ and C# are both great languages that fulfill different needs, and the success of one need not come at the expense of the other."

http://blogs.msdn.com/texblog/archiv...02/424588.aspx

You sound in dire need of reading http://www.paulgraham.com/power.html

Quote:

---

Originally Posted by dxfoo

Thanks for the great replies. I agree about C++ being alive and well. In fact, it's interesting that even Java can do native calls on C++ code if needed. I'm sure .NET has a way for this, as well.

---

hmm.. I thought .NET had at least as good support for C++ as it does for C#.

However, I know little about it. I do know though, that anything that looks simple just has a whole lot of complexity hidden underneath it. Take a wheel for instance; the thing only works because it's made of an extremely large number of atoms and things, all working together to hold it in one piece, and for that matter, you wouldn't even *need* a wheel if it weren't for all the friction and gravity getting in your way. It looks simple.. you can use it without knowing how complicated it really is... but it's a lot more complicated than programming is.

You're thoughts seem to me to be a bit too narrow. Certainly, GUI programming in C++ is challenging and time-consuming. It is doable in C++, but in many cases (not all), there are much better tools available to do the job -- as you said, why write 400 lines when you could write 4? But, you have to consider that applications for mobile devices and the web are perhaps the most visible, but by far not the only applications. I'd (usually) much rather write a scientific simulation in C++ which has the capabilities of abstraction to make development and maintenance more tractable than something like FORTRAN or C, while still maintaining rather reasonable speed and resource management.

Cheers

At the beginning, I thought C++ would "fade out" due to newer technologies and the user's increasing expectation of GUIs. However, out of this dicussion, I found that C++ will always have its stay in where it excels in.

I'm going to choose C# because I wish to persue the client end of GUI design, mobiles, the web, and side in game programming. Since I can admit that I'm rather a simple-minded programmer, I'd probably excel more in C# than C++. I want to build simple games up to RPG's that have a Runescape feel (www.runescape.com). Much like this screenshot I found...

http://farm.tucows.com/2004/08/etern...ds/screen3.jpg

C# can handle this. I don't expect it to handle Everquest 3, nor will I "think" I can do it, because I won't, and I can't. I know .NET's limits, and I'm proud enough to say that I can do what I need to do. And I'd love to use .NET for a software position after college. I think at the end, we use what we're most comfortable in. For me, that has to be C#. Thanks for the discussion. I see that you have a C# section! I'll be around there if I have any questions.

I think an old fashioned tecnique would work well to solidfy your knowledge of C++.

Write the code on paper first (pseudo). Proofread, create flow charts for your functions and use UML for OO stuff.

Try not to use refrences unless you are stuck.

This advice I need to do myself. Call me a noob hipocoder.

Btw, I'm not very worried about the level of abstraction that C# gives. But who knows: in three years, C# may be so "advanced", it'd be like this!

using system.awesomegameheaderfromc#;
C#main
AwesomeGame();

I'd be a little worried at this point. Anyway, thanks for the discussion. Time to read some more :)

I agree with above statements, it's the calls and libraries that make something easy to use, even in ol' C there is nothing stopping you from making a very easy to use set of calls for gui stuff. It wouldn't be overly difficult to package the DirectX setup code to two or three calls, or a set of calls for window stuff (GLUT for example).

I don't actually see a lot of special language constructs C# offers that C++ doesn't, it does offer much protection for those inexperienced in or hating memory manipulation; it also simplifies a few things such as headers, dereferencing, etc. but that isn't a radical difference. If I am missing something (I'm not a C# programmer) please point it out, I'm always interested to learn.

Different languages are different.

Someone has to write all those C and C++ libraries that are easy to use. My take on this is that C and C++ will still be alive and kicking for a long time. The question now is: what programming work do you want to do? Creating libraries that are easy for others to use? Or, use libraries created by others as building blocks for your system? ;)

Definitely writing new libraries in C++ is a plus for the langugage.

I have a background in many languages (.NET, VS 6.0, ASP, PHP to name a few).

If a company has switched from c++ to VB.NET then (perhaps) it's because they shouldn't have been writing in C++ to begin. VB, in any form, is great for building window and database driven programs. C++, while it can be done, isn't best for everyday applications that are database-driven and heavy into user interaction. Think data-entry apps or an invoicing system.

I'm learning c++ and using my new knowledge to write a windows service. However, for the front-end user interface which would only be used to rarely make a few options changes and wouldn't be running all the time, I'm writing it in VB. I have a few other reasons for the split but suffice it to say, programmers need to know a few languages and know how to use them together. I have a VB program that uses PHP. Why? Because that was the only way to solve a problem.

C++ will always (can I say that?) be around as long as new libraries are written. If I recall correctly, that's a lot of .NET advantages - new standard libraries that use to be coded with a ton of code now done to a few lines. So for that reason, learn it if you can.

Every programmer has a choice in life...do I become a good (C++, java, .NET, etc) programmer and specialize in one language OR do I become a good programmer who has enough knowledge to provide a solution by using whatever technologies it takes to make it happen? I've found being the latter is much more rewarding. The question of "Can this be done?" shouldn't be based on a limited programming technology but by feasibility.

Why have I said all this? Too much coffee.

I agree with everything above. Managed and unmanaged code can work together, so investing time in C# and C++ can only mean more power at the end, and I'll continue to learn each. I guess right now I don't really require every ounce of speed and power, so C# seems more benefitial for my own project ideas. I wish to persue client applications, web services, mobile programming, and a side in game programming. I think anyone would say C# is a better gear for what I want to do, but still, I agree that any programmer must know C++ efficiently because sooner or later, you'll have to maintain these products in much of the world, including upgrading, debugging, etc. I don't think any programmer can afford to ignore 90% of what the world runs on.

Interesting thread on using multiple languages in a project:
http://www.erlang.org/ml-archive/erl.../msg00357.html

Essay on why one should use a language of more power rather than politically accepted languages:
http://www.paulgraham.com/icad.html

Postscript file outlining introduction of erlang and the benefits it provided over using Java/C++:
http://ortdotlove.net/docs/erlang/bits.ps

In my personnel opinion, the reason we still have so much C/C++ code kicking around is, in a large part, due to legacy code and secondly ignorant people. Legacy code is difficult to deal with, in most situations it is probably going to cost more money to rewrite it then to maintain it (up until a point), and the people which control the budget arn't thinking that far ahead. As for the second point, in a commercial environment the people which will decide how much money to spend, who to hire, and how to advertise their product are not software engineers. This means that they generaly know very little about the tools used to create a product not to mention the technical issues involved in deploying it. Managers are often swayed easily by politics (when it comes to languages). A easy example: Java, Objet orientated, and XML are lovely buzzwords that most managers enjoy hearing, saying, and advertising. If they havn't heard of the language/technology then it means it's not good or worth using. A lot of programmers are fairly ignorant too. Many have come to the unfortunate conclusion that C and C like languages are the answer to all questions. For some reason many of them have come to the conclusion C is the first language (after assembly) chronologically and the most accepted, thus producing the best products. Often they are shocked to hear that Lisp has been compiled long before C. Also, many confuse speed with being A) an attribute of the language B) important to their particular application C) unobtainable by any other programming language.

A) Languages don't have speed, implementations do. Various implementations vary. We can compare solutions to problems in implementations of different languages, but this even does not yield useful results generally.

B) Most languages are I/O bound. An IRC client is waiting on input 99% of it's run time. Anything it does is probably calling hooks and passing data over a wire. Networking in generally is I/O bound and most decent language implementations are quite fast enough so that even in an interpreted implementation the I/O is still going to be the bottle neck.

C) Most scientific applications I've seen don't use C or C++ as the frontend language. They might write some of the implementations of functions in C or C++, which is different. Look at languages like J, K, and SML. J and K are made for high performance mathematical processing. SML is fairly mathematically orientated. The design of the language lends itself to being fairly easy to optimize. J, K, and SML have all shown capable of reaching C-like speeds with generally less work to obtain it and (generally) more readable and portable code.

Don't confuse any of my statements with saying C and C++ are never the answer. There are particular situations where such a language has implementations written for them that can do things other languages can't. However, one should not think this is an aspect of the language. But rather the amount of work that has been put into their implemenations. Given C and C++'s popularity *a lot* of work has been put into them so, of course, their are implementations for them that can do quite a bit.

In regards to the threads topic, C++ has a massive language. It is quite difficult to write a large complex C++ application without a reference. Not to mention, once you start throwing template meta programming into the mix things quickly become even more confusing. Debugging a boost::spirit error message takes a degree in science.

Finally, it seems that many people consider C# an upward motion, it seems (to me obviously), that is more of a lateral move. C# seems to mostly provide aesthetic improvments and security improvments. The constructs of the language really havn't changed much. The expressivness hasn't been increased very much. Am I wrong here?

There's nothing to disagree about here. I think 90% of applications don't really require performance as the #1 key, so productivity seems to be the complement of performance. Either you need something that needs every ounce of speed (and there's very few programs in this area), or use some wrapper (basically MFC#) with benefits such as greater security, architecture-neutral, mixed-language programming, modern memory management, and component-oriented. Obviously, a large amount of software can use this without just worrying specifically about performance. I see games always using C++, but I'm sure with today's technology, it's becoming a headache. But of course, game companies are known to have built their own wrappers and COM files over the years, so it's really up in the air.

excellent points, orbitz.

Orbitz, the post on multiple languages highlights a good example of a bad design.

In the cases of mixing languages, I wasn't speaking of compartmentalizing parts such as that. I was thinking more of using a second language where either one cannot perform a task or could be done more easily - i.e. GUI creation to modify a parm file.

I must ask, though:

Can C++ use .NET extensions, which would return all the managed benefits? I tried /clr:oldSyntax, and was able to use __property, __sealed, etc. This is cool!

I'm thinking about focusing on both languages equally because I find something that all other languages lack: control. If C++ can create .NET and Java down to their core, isn't that worth taking pride for? Isn't that worth the lengthy study? Isn't that worth fighting for?! :)

dxfoo:
Yes, it is called Managed C++. It allows usage of a garbage collector and the various .NET classes.

Quote:

---

If C++ can create .NET and Java down to their core, isn't that worth taking pride for?

---

In my opinion? Not really. Neither .NET or Java are all that novel or innovative. They have their uses but I can't think of a situation where I would choose to use either of them for a new project. So C++ was used to write their VM's. So what? You could use just about any langauge to write another languages VM, I don't see how the programmers choosing to use C++ makes C++ any more interesting.

Quote:

---

I find something that all other languages lack: control.

---

What does this mean exactly? What is control? How do other languages lack it?

FoodDude:
Indeed, I wouldn't say that that part of the paste is directed exactly at you. However, programs written in multiple languages is becoming more common. For instance Python allows you to interface with C and C++ fairly seemlessly which is quite nice for doing those things that require a tight loop. Erlang provides a similar mechanism that is quite simple. Just about any language can also communicate with each other via sockets

You know how to kill my joy. :(

For control, I meant speed you can depend on to carry out compilers for today's new technology.

I'm using C++ using managed extensions. I guess that's called Managed C++? There's a language called C++.NET. I'm guessing you're not talking about that.

Well, thanks guys. I guess a simple answer is "no" to the OP question. C++ continues to amaze me. Someone here is going to tell me I can use GDI+ for C++ too.

This is worth going for. Coming to think of it, I'm already pretty good with .NET. I'm always looking for ways to improve int it. This would be a good time to start looking at the lower end of things and finish this reference book.

Quote:

---

Originally Posted by dxfoo

You know how to kill my joy. :(

For control, I meant speed you can depend on to carry out compilers for today's new technology.

I'm using C++ using managed extensions. I guess that's called Managed C++? There's a language called C++.NET. I'm guessing you're not talking about that.

Well, thanks guys. I guess a simple answer is "no" to the OP question. C++ continues to amaze me. Someone here is going to tell me I can use GDI+ for C++ too.

This is worth going for. Coming to think of it, I'm already pretty good with .NET. I'm always looking for ways to improve int it. This would be a good time to start looking at the lower end of things and finish this reference book.

---

Last I heard Managed C++ was another way of saying C#.

The point to consider is that most languages have a niche. Perl is good with text, PHP is pretty decent for web dev, C/C++ has the more unique niche of being very flexible. It might NOT BE THE BEST at any one thing, but it can be implemented in a number of ways. Its much more flexible than anything else that I know of (though if there is something more flexible please share it :) ). I think C/C++, VB, C# etc will stay around for quite a while since each is good in its own area, however I think C/C++ will remain more the choice in many things because of its power and flexibility.

This article was great regarding MC++.

Some highlights:
* The best performance of generated IL code
* Allows a developer to keep performance-critical portions of the code in native code.
* Gives seamless access to all unmanaged libraries, such as DLLs, statically-linked libraries, COM objects, template libraries, and more.
* Leverages existing investments in C++ programming skills and legacy C++ code.
* Porting unmanaged code to .NET: MC++ allows you to take existing unmanaged code and compile it to managed code (with the /clr compiler switch and IJW).
* Provides the easiest way to add .NET support to your existing native C++ Windows applications, by allowing you to bridge the gap between the two environments with as little work on your behalf as possible, and with the lowest performance penalty.

That's no C# :)

"One of the areas that MC++ excels in, and is in fact unique in amongst the .NET languages, is the ability to take an existing unmanaged (C++) application, recompile it with the /clr switch, have it generate MSIL and then run under the CLR, unmanaged. This extraordinary feat is aptly termed "It Just Works (IJW)!" There are some limitations, but for the most part, the application will just run."

What it's good for, I don't know. But it's another C++ goodie to play around with.

Article:
http://www.ondotnet.com/pub/a/dotnet...intromcpp.html

Oh, how I hate the word "leverage".


Anyway. Managed C++ (or C++.Net, they are the same) was developed mainly as an interface between Managed and Unmanaged (native) code. Some of the core .Net classes are implemented in C++, because they need to interface with the CLR, which was written in native C++. MC++ can also be used to provide interfaces to existing C++ libraries for pure .Net languages, or use .Net components from C++.
However, beyond these uses, MC++ has several key disadvantages:
1) It lacks the speed of native code. MC++ is compiled to .Net IL and executed by the CLR.
2) It lacks some of the features that distinguish C++ from similar languages, namely templates and multiple inheritance.
3) It lacks the ease-of-use of C#. There is no auto-boxing, no foreach loop, no proper property support (at least the last time I checked, which was in VS.Net 2002), no proper event support. The syntax is less clear - since everything is a pointer, you have the * for every type. You also need the __value keyword for every Managed struct and the __gc keyword for every Managed class.
4) It lacks the compilation speed of C#, due to its considerably more complex grammar.

So MC++ is not desireable for a complete .Net application.


I was going to post something about languages in general, too, but all important points have been made.

There is another factor that I have not seen anyone mention that is (and should be) a part of deciding on the language. Sure, language A may be the theoretically optimal language for the problem, but if the developer(s) are not proficient in language A -- and have would have negligible additional future benefit from becoming so -- but language B will solve the problem well, and the developer(s) are proficient in it, then there is a strong case for language B. This isn't laziness, it is merely acceptance of the fact that time is not unlimited, deadlines exist, and people have other things to do in their lives.

So, by virtue of the fact that there are so many competent C++, so this presents a strong argument for the language since it is rather general purpose.

Cheers

Quote:

---

So, by virtue of the fact that there are so many competent C++

---

My guess is you havn't dealt with many C++ programmers. Trust me, not many are competent.

Quote:

---

but if the developer(s) are not proficient in language A

---

This is somewhat of a fair comment. However let me do my best to give an argument against it. Let's assume there are two project types. Commercial and Open Source. For commercial we have a project manager who's job is to find programmers, hire them, pay them, yadda yadda. For an open source project we have a bunch of programmers together who have a neat idea and want to implement it.

For the first situation, it's the project managers job to find programmers who are proficient in the needed technology to solve the problem. So in other words, if the developers can't learn the language or don't know it then they shouldn't be working on the project and the project manager has failed at finding the best people for the job. You might counter by saying, "perhaps it's a new project and they don't want to hire completley new developers for the project". Well, ok, use the same developers. For starters, what are you doing hiring one trick pony developers. They only know C++, maybe Java, or C#? Secondly, if you really want to use language A when language B would suit it, go for it. If your competitors are smart they will use language B and soon, if you are lucky, they will be buying you out. Take something like C++ vs Erlang for a telecomm application. Studies have shown the Erlang application is probably going to be developed 4times faster (on average). If your competitor can advance their project 4times faster than you then any neat feature you add will quickly be added and possibly surpassed by your competitor. Alternativly, being able to develope faster means you can hire fewer developeres but get the same results.

For the open source situation. You'll generally have some developers with some neat ideas and want to show the world. In this situation, they should have plenty of time to learn the language and implement their application in it. Afterall, once you know one language it is fairly simple to pick up any other language. They want to express their ideas to the world don't they? Why not do it in the best possible way.

There are a few situations in which usign the less optimal language is acceptable. The most immediate one that comes to mind is client specifications. This comes out of the ignorance statment of my previous post. Some clients want their product in a certain language and won't be told no by anyone.

I hope those arguments seem fair and justified.


dxfroo

Quote:

---

For control, I meant speed you can depend on to carry out compilers for today's new technology.

---

I don't know what this means, care to explain?

Quote:

---

My guess is you havn't dealt with many C++ programmers. Trust me, not many are competent.

---

I've dealt with some very competent people, and seen many incompetent ones. I'll readily concede the point.

You make a good argument, and I don't completely disagree with it, I just think it is too strong of a statement. My assumption is not that you have hired a set of code monkeys, but rather a fairly competent set of computer science types. Part of the time will be making sure that the developers are proficient enough in the language to work with it and the available tools (if available) to deal with the language; part of the time will be spent finding the neccessary libraries and learning them, assuming they exist. For a large and complex enough application, there may be enough separate modules that could each be done in an optimal language that hiring or training enough developers in the specific languages may be too expensive, too time consuming, or those folks may be too rare.

There is an additional factor as well. Say there are many competent developers in C/C++/Java/LISP/Ada/etc available, but few in the 'optimal' language. You're company may not be in a position to hire enough people who know that language at the time, and may have to settle (perhaps only temporarily) for a slightly less than optimal solution.

So, I'm not saying that C++ and its kin are the cure-all. They certainly are not; and there is certainly a lot of code written in those languages for the reasons you mentioned (primarily ignorance). In your example of Erlang, if your company is going to be doing primarily telecomm work, then it'd be foolish to use C++. However, if all you'll ever need is a small telecomm module, and competent C++ programmer may be able to design and develop such a module in C++ that is extensible, maintainable, etc in less time than he'd take to learn the new language.

As for the matter of the open source team, I completely agree. If you're just doing it because you want to show it to the world and you have (essentially) unlimited time, then yes, do it right.

Quote:

---

There are a few situations in which usign the less optimal language is acceptable. The most immediate one that comes to mind is client specifications. This comes out of the ignorance statment of my previous post. Some clients want their product in a certain language and won't be told no by anyone.

---

In summary, I find this too strong of a statement, but not completely unjustified. There are more factors to consider.

Quote:

---

I hope those arguments seem fair and justified.

---

By and large, yes, they do seem that way.

Cheers

I finally know what language to use... both! It came obvious to what I need to do. If I need to do systems level programming, devices, or performance-critical games, I'll let C++ be the choice. If I need to do GUI/Web/Mobile/Simple 2d to The Sims 2 games, I'll let C# be the choice. It makes sense to me... why limit yourself to one language? Learn them all. See where they are useful, then use it accordingly.

Quote:

---

Either you're serious, or I took this the wrong way. Either way, I felt like sharing this thought. Side wars keep coming up when someone mentions .NET in a Java forum, etc. This is getting rediculous.

If you're referring to me, I'm a general programmer - I don't take sides. Many people do on forums, and it's really depressing. For instance, your boss wants you to use .NET for a certain project. Are you going to be prepared, or are you going to say, "Ew! .NET. Yucky." What if one of your programmers starts talking about a philosophy on why MS is the devil when you're trying to get a .NET project done? He'd be fired, and he'd end up at a common forum.

It's true that any programmer prefers a certain language for their personal projects, but it doesn't work like that in the real world, sorry. I enjoy programming, not C++, not .NET., not Java. Just programming :) If you take sides, you're a fool. Programming is not politics.

---

-- dxfoo

Quote:

---

You are a sad, strange little man. You have my pity. Farewell!

---

-- Buzz Lightyear

dxfoo:
Why not learn some languages which are actually 'different'. You have C++ and C Suck Suck. Processors are becoming more concurrent, so why not be one step ahead of the gang and learn a concurrent orientated language?
It's upto you obviously but IMO, expanding a bit past the C-like world would be good and enjoyable. You don't have to becom the best at these other languages, but you should know the basics and some common idioms in them. That way you can decide what language really suits you. For instance, i am quite knowledgable in C, C++, Python and Erlang but i had to dabble in Common Lisp, Assembly x86, Ruby, Perl, Mozart, Scheme, PHP and now SML before I came to these. Although to be fair most of my C and C++ knowledge comes from just not knowing that there was anything out there so had I played with those other languages first I don't think I would have been very interested in learning C and C++.

But whatever your language choice is, just remember that the language you are using sucks according to someone for some reason regardless of how good the reason is.

Again orbitz is too extreme for my opinion (especially since C++ does not suck), but he's essentially right. Your CS study years are the ideal time to get to know as many languages possible. I've played with C, C++, JavaScript, Java, C#, Basic, PHP, Perl, Python, Haskell, Assembly (x86 and Alpha) and various others before deciding that C++, Java, PHP and Haskell are my favourites.

Orbitz, thanks for the tips. I could write a book on what I plan to do, but I'm just going to stick with what I'm most comfortable with. There's many tools that can be applied to one language, so a focus is always necessary for a while. Thanks.

dxfoo

Well as I said, your language of choice sucks a lot according to someone. In my opinion, C++ is a fairly bad language. It is incredibly large, requires knowing a fair amount of it to complete a relativly small problem, and if you subscribe to the Succinctness Is Power argument by Paul Graham (http://www.paulgraham.com/power.html), C++ fails pretty terribly at this. Solutions are generally not succinct at all.

Take a simple thing like parametric polymoprhism.

C++ I get soemthign like:

Code:

---

template <typename A>                                                                                                                                                                                           
A doubleIt(A a) {                                                                                                                                                                                               
  return a + a;                                                                                                                                                                                                 
}

---

In Erlang I get

Code:

---

doubleIt(x) -> x + x.

---

However I suppose this is a losing argument.

EDIT: Why is this post so darn wide???

Your argument makes no sense. The language is bad because you have to have knowledge of it in order to use it? How is that bad? It makes perfect sense to me. How can you program without knowing the language you are using to some degree? It isn't like you need to know how to use templates in order to make a Hello World program.

Haskell:

Code:

---

doubleIt x = x + x

---

I'm aware of the power of functional programming languages and the genericity they often come with. As I said, I've learnt Haskell, and it can do the same. Still, I feel that the functional model is not very well suited to model an application as a whole. But that's a completely different point.

That C++ is verbose compared to functional programming languages is not a particularly strong argument, either. Paul Graham may argue all he want, but this simplistic view of his essay is a) probably not what he intended and b) wrong. The power of a language is defined by the ease with which you can express your ideas. It's a matter of concepts, not syntax.
If a language directly supports the way you want to express your ideas, then succinctness is a result. I believe that Paul Graham is confusing cause and effect in his argument. You do not make a language short in order to make it powerful; you make it powerful in order to make it short. Haskell has, as a feature, the automatic deduction of type. This makes it powerful. This also makes your example possible. The terseness is the effect of the feature, an indicator of its power, not the source.

Does that mean a verbose language is necessarily bad? Graham starts his essay with a statement about Python and infers that Python is a bad language. Now, leaving aside that I strongly dislike Python for its reliance on whitespace (just being on a board like this should show some of the perils of this), does this make Python a bad language compared to similar languages? (That is, object-oriented, weakly typed scripting languages.) No, because Python has the same power - it is equally capable of expressing ideas. Perhaps it takes a little more space to express them, but this rather irrelevant, or even positive if it increases the readability of the language; in other words, the syntax of a language should aim to maximize the speed at which the language can be read by a human, not minimize the number of lines it takes. These goals go hand in hand to a point, because pages and pages of code are hard to take in, but there's a limit.

Quote:

---

It is incredibly large, requires knowing a fair amount of it to complete a relativly small problem

---

I'm not quite sure what you mean here. If you say that you need to know a lot of C++ to solve even small problems, then you are somewhat right - but that's irrelevant, because C++ wasn't made to solve only small problems forever. Sooner or later, you'll come across a large problem, and your knowledge will serve you the same.
The same applies to every other language. The amount of knowledge of a language you have doesn't affect the size of the problem you can solve, merely the efficiency with which you solve it.

I would also argue that the mere concepts of functional languages, and how they can be applied, are harder to learn than most of C++ as a language, including the object-oriented concepts, simply because the object-oriented model is closer to the way humans think.
I don't know how Erlang solves the classical sequential execution problem that every functional language faces, but if you actually want to understand the Monad model of Haskell, you do need a Ph.D. The Pointer model is even harder.

I could probably continue, arguing for example that C++ makes it easier for you to profit from the knowledge of others without having that knowledge yourself, but I think I've said enough for now.

You are confused. I said you have to have to know a fair amount of the language to solve relativly simple problems. For instance, you can solve quite complex problems with only knowing a small amount of Common Lisp. The second program in Paradigms in AI Programming is a General Problem Solver and the book is teaching Common Lisp from scratch.

Take streams in C++ for instance. In order to do much with them one needs to understand references (because they lack a copy constructor). Namespaces, templates (because streams in C++ are templated). operator overloading (How does operator<< work? I thought it was left shift). function overloading (how do you print out a char and an int and get different output even if they rerpesent teh same value). buffering (why does cerr soemtimes print it's output before my cout can). not to mention you have to learn what cout and cin really are. Also the difference between formatted and unformatted input (why does std::getline not work after i use operator>>).
Here is a nice Hello World: http://jcatki.no-ip.org/fncpp/Hello_World
That certinaly is quite a bit just to do some streams.

Does that clear things up?

Also, I would like to note my Erlang vs C++ example is not quite fair. For starters, it is not quite typesafe, for instance if i pass a type which has no + operator defined for it I won't know until runtime where as a C++ compiler must tell me this at compile time. This would be easily caught by a ML compiler though, and still have the succinct syntax.

I understood perfectly well what you said. I just don't think your argument has a real-world application.

My previous post was in response to 7smurfs.

I think this discussion has about reached it's climax. I think we have both presented our arguments reasonably well and soon this will probably just turn into baiting for flames. Feel free to respond to this post however I may or may not respond unless it's something important.

Quote:

---

That C++ is verbose compared to functional programming languages is not a particularly strong argument

---

I'm hardly arguing functional languages are the answer, my response simply used one, python is more succinct than C++ too.

Quote:

---

The power of a language is defined by the ease with which you can express your ideas. It's a matter of concepts, not syntax.

---

A language is it's syntax, so it's syntax directly affects the ease of which you can express your dies. If this wasn't the case wouldn't we all easily be able to express ourselves in C or Assembly just as easily as another language? But this is obviously not the case.

Quote:

---

does this make Python a bad language compared to similar languages? (That is, object-oriented, weakly typed scripting languages.) No, because Python has the same power - it is equally capable of expressing

---

For the record, Python is a dynamically strongly typed language. Automatic type conversions dont' take place, Perl would be weakly typed.
This is the exact point the essay is arguing. Languages are equal in what they are capable of expressing (Turing Equivalent ones atleast). The issue is how well it lets you express it. I think it's fairly obvious some languages let you express some ideas more succinctly than others and the point of the paper is to ask the question "does that make one language more powerful than another".

Quote:

---

If you say that you need to know a lot of C++ to solve even small problems, then you are somewhat right - but that's irrelevant, because C++ wasn't made to solve only small problems forever.

---

I'm unsure of how that is irrelevant. The more complex the problem the more knowledge of C++ one needs, and considering C++ is a rather large language that is hard for most people to keep in their head. If a small problem requires knowing quite a bit then the larger the problem, the more you need to know. I'm sure this plateaus off somewhere, but where?

Quote:

---

I would also argue that the mere concepts of functional languages, and how they can be applied, are harder to learn than most of C++ as a language, including the object-oriented concepts, simply because the object-oriented model is closer to the way humans think.

---

From what you have listed, Haskell seems to be the only functional language you have had experience with. Haskell is a fine language and all, but oen cannot take things from Haskell and generalize them over all functional languages. Haskell tries to be very pure in how it does things functionally. Haskell makes strong attempts to avoid side effects. This is why we have monads. Many other functional languages are not like this and understand we can have side effects. in Erlang we have io:fwrite, in Common Lisp, format and print functions. These languages are quite easy to understand. Erlang in particular was developed with ease of learning in mind.
I am also a bit hesitant to beleive that OOP truly models how we think. Do you have any research papers that show this or is it your intuition? As far as I know, few people are really aware of how we think and are not in a position to provide comparisons to a programmatic concept. If we really do think in an OO style, then I would argue that a language such as C++ or Java model this fairly poorly. Thoughts seem more dynamic and fluid than these languages allow. I do not have a Ph.D. in neuroscience though so I cannot say for sure. In my experience I have found functional programming to be qutie powerful and have been fairly successful with it. Perhaps toying with other functional languages than haskell will alter your opinion of the style.

A paper on functional programming and the real world (I have not read it yet but stumbled over it):
http://www.md.chalmers.se/~rjmh/Papers/whyfp.html

I don't mean this as an attack on you at all orbitz, please don't take offense.

Honestly, if I have a programmer on a team that isn't willing to use language A because it is too difficult for them to use/understand, I would have to question why they are on the team. Programmers solve problems, both mathematical and abstract and documentation is everwhere, a small hill in a language or library should not stop or slow a project. Off course if a language offers a go.now approach you can finish your product faster, but there are some very well wrapped libraries for most languages so you still get quite a bit of abstraction.

You are right, orbitz, the discussion is unlikely to lead far from here, so I'll respond just to a single point:

Quote:

---

A language is it's syntax,

---

I disagree. The syntax is part of a language, but by far not the most important part. The syntax merely dictates how we express the concepts of the language, which are the really important part. For example, C has the concept of structured programming (functions, ifs, fors, ...) as an advantage over Assembly. While you can do these things in Assembly, it's not a language concept. This ties back into syntax, because if a language has a concept, then that means that there's special syntax available to support it. However, this is again a matter of cause and effect.
The effect of pure syntax is stronger between Assembly and C than between, say, C and C#, which are syntactically very similar. Obviously, b = a + c is easier than
mov eax, [a]
mov ebx, [c]
add eax, ebx
mov [b], eax

But that, too, is in my opinion an effect of concepts. In this case, it's the concept of abstraction from the machine, away from registers and towards variables as abstract containers of values.

I don't quite follow what you are saying. The syntax dictates how we express teh concepts of the language? Right, and the point of the language is to be able to express concepts, so why is syntax not so important? If we can express the same concepts in every language then why do we bother to use any language over assembly? As Paul Graham article suggests, isn't it because the other languages provide for succinct ways to express the same concepts because of the different syntax and this is more powerful?
What you are trying to say seems unclear to me. It seems as though you are suggesting the syntax is not very important but then saying it is because we can express things more easily in C over ASM which is why we use C. Is this what you are saying? If so, doesn't that make syntax fairly important? Libraries can't abstract us away from the machine much because they are dependent on the language, so it seems that syntax is what abstracts us from teh machine, which is why we choose various languages often (how well we are abstracted from the machine) which is syntax right?

valis:
Why would I think you are attacking me, you appear to be agreeing with m.

No, orbitz, it seems we simply have a different view of what syntax is. For me, syntax is the difference between saying:

Code:

---

blueprint bird
begin
  begin interface
  end

  begin implementation
    song as soundSequence
    maxSpeed as real
  end
end

---

and:

Code:

---

class bird
{
public:

private:
  soundSequence song;
  float maxSpeed;
};

---

As such, syntax is largely irrelevant. The ability to define a class/blueprint/whatever is what defines the language.

Another point which I don't think has yet been fully addressed is the pointy haired manager. He may be an idiot, he may make completely unfounded claims, but he also supplies you with a constant flow of money. The more knowledgeable one is of multiple languages, the more likely the pointy haired manager will keep that person around because he/she can implement functionality the way the manager wants. Of course with such a large job market, if work is miserable it may be better to just quit the job.
I for one don't particularly like C#, but I've done a bit of study on it anyway simply because
a) it's still a lot of fun, just not as mind rending as I would like
b) I'm sure much of the market will shift towards it as Microsoft continues to force it into the market.

There have been very interesting arguments so far and quite a few articles, for those currently working on a company project, I'm curious about what language is being used.

edit:

Quote:

---

Why would I think you are attacking me, you appear to be agreeing with m.

---

glad to hear it, I've just run across some pretty strange people, and it's always sad to see an interesting debate turn into a flame war.

I did mention managers in a previous post + provide a link to Paul Grahams article o it.

Quote:

---

As such, syntax is largely irrelevant. The ability to define a class/blueprint/whatever is what defines the language.

---

Your example is not quite fair. Defining an object to contain slots for various data is most likely going to be fairly similar in most languages and there isn't really much differences between the end result. It's not like you can really express wanting an object to contain slots A, B, and C more succinctly than simply doing it, which is pretty much how most languages do it. A fairer example would probably involve actually doing something, such as a concurrent web server operating over N distributed nodes. I think you would notice a drastic difference in what syntax of a language can offer you in that situation.

Quote:

---

Your example is not quite fair.

---

My example is perfectly fair. You still don't understand that "syntax" seems to mean something entirely different to me than to you.

Quote:

---

I am also a bit hesitant to beleive that OOP truly models how we think. Do you have any research papers that show this or is it your intuition?

---

orbitz, though I doubt objects are the only way we can think, people have done studies on object recognition, and this ability occurrs at a fairly early age.

Quote:

---

As far as I know, few people are really aware of how we think and are not in a position to provide comparisons to a programmatic concept. If we really do think in an OO style, then I would argue that a language such as C++ or Java model this fairly poorly. Thoughts seem more dynamic and fluid than these languages allow.

---

Agreed but only for the language itself. You can have a farily natural progression from free flowing thoughts to the language.

Quote:

---

As most humans do, we think in an object-oriented mind. Due to today's complexity, usually .NET/Java would fit in this area. Like ASM had to switch to C, C had to switch to C++ due to complexity later. Is C++ about ready to be too complex today?

---

dxfoo, well, I don't think the C++ most people use is really that more complicated than Java or C#.

Quote:

---

After noticing the amount of productivity I get for using these languages, I look back at C++ and wonder why it's so obscure to do even the simplest of things. For instance, in DirectX, you're looking at 200-400 lines of code just for a video on the screen.

---

The amount of code needed to put a video on the screen I would think depends on the library.

Quote:

---

Due to today's complexity, I'm glad they built these tools. Companies even see a need for these languages to decrease debugging time, and focus more on getting a product done less than the time they thought.

---

OK, but I think both the garbage collector and a VM can be used with C++. For some projects, these are needed but for other projects using smart pointers and collection classes is better.

Quote:

---

Now think of using C++ for every major cell phone. It's too complex, and developing compilers for each one takes time and money.

---

In that case, each different cell phone might need a differerent Java VM.

Quote:

---

Originally Posted by orbitz

Your example is not quite fair. Defining an object to contain slots for various data is most likely going to be fairly similar in most languages and there isn't really much differences between the end result. It's not like you can really express wanting an object to contain slots A, B, and C more succinctly than simply doing it, which is pretty much how most languages do it.

---

I agree with you in spirit, but defining an object to contain slots for various data _is_ different in different languages.

For example, in Io, a two dimensional point type would be created with

Code:

---

point := Object clone
point x := 0
point y := 0

---

Then, you might define a method.

Code:

---

point mag := method(((self x ^ 2) + (self y ^ 2)) sqrt)

---

Then you might make a point of your own.

Code:

---

q := point
q x := 7
q y := 5

---

Maybe you want this to be a three-dimensional point.

Code:

---

q z := 12
q mag := method(((self x ^ 2) + (self y ^ 2) + (self z ^ 2)) sqrt)

---

Copy it and you have another.

Code:

---

s := q
s x := 0

---

Print out its magnitude, if you wish.

Code:

---

s mag print

---

(This prints 13)

Defining slots in Io and other prototype-based programming languages is much different than it is for other programming languages, and you're generally right that "most" languages do it one way, but I don't think this difference should be overlooked.

Making q a three-dimensional point certainly is more succinct than it would be in other languages.

http://wagerlabs.com/tech/2005/09/ja...erlang-ii.html

A blog entry attempting to weigh two languages, mostly an attempt to persuade the reader that succinctness is power.

CornedBee:
I have been spending time learning Haskell. From what I understand of monads so far they arn't as complex as you made them out to be. They simply provide artifical data dependenceis to force operations to happen in a given order. Is this correct from what you understand?

That is correct. Understanding the detailed interactions of the more complex monads hurts my brain, though.

How so? Do you have an example?

I'm referring to objects that appear to have state.
OK, the thing that really confused me was during the time I was learning Haskell, this exercise:

Based on a simple binary tree:

Code:

---

data Tree a = Leaf a | Node a (Tree a) (Tree a)
        deriving Show

---

Create a function label:

Code:

---

label :: Tree a -> Tree Integer

---

with this property:

Quote:

---

Takes a binary tree as an argument. Creates a mirroring tree that has as its
node values the infix index of the other tree's nodes.

---

Do this with and without monads.

The non-monadic version is simple enough:

Code:

---

label_helper :: Tree a -> Integer -> (Integer, Tree Integer)
label_helper (Leaf _) i = ((i + 1), Leaf i)
label_helper (Node _ ol or) i = let
        (myi, nl) = label_helper ol i
        (reti, nr) = label_helper or (myi + 1)
        in (reti, Node myi nl nr)


label :: Tree a -> Tree Integer
label t = snd (label_helper t 0)

---

For the monadic version, I wanted to make a monad from the tree that behaves like the list monad, i.e. loops the following code over its elements (in infix order):

Code:

---

instance Monad Tree where
        (Leaf v) >>= k = k v
        (Node vOld leftOld rightOld) >>= k = let
                leftNew = leftOld >>= k
                (Leaf vNew) = k vOld
                rightNew = rightOld >>= k
                in
                (Node vNew leftNew rightNew)
        return x = Leaf x

---

Base on this, it would have been easy to do this:

Code:

---

mlabel t = do
        e <- t;
        return running_counter

---

However, I failed both at implementing and understanding the logic behind implementing such a running counter. I know it's possible. I just don't get it.
My mind at least really doesn't work in a functional way, although I love the idea of functional languages.

Hrm, I havn't learned Monads very well yet beyond the idea, I'll see if I can wrap my head around it later today.