Luis Espinal

Leandro Coutinho wrote:

Angus Comber wrote:In what way is C++ simpler than C?

Luis Espinal wrote:How is it simpler?

The logic of a program written in C++ is simpler than in C, and therefore easier to get right.

A concrete example or two would be in order. Otherwise, a statement of the form "X is easier than Y" without substantiating, qualitative or quantitative evidence or samples is not a convincing argument, in particular in technical matters such as this.

Leandro Coutinho wrote:"C++'s better support of libraries, better notational support, and better type checking are decisive against a "C first" approach." Bjarne Stroustrup

"My favorite approach is to start teaching the basic language concepts such as variables, declarations, loops, etc. together with a good library. The library is essential to enable students to concentrate on programming rather than the intricacies of, say C-style strings." Bjarne Stroustrup

http://www2.research.att.com/~bs/new_learning.pdf

Quoting Stroustrup (much respect to his work) does not necessarily translate his words into facts. After all, Stroustrup is the father of C++, and obviously he's going to have that opinion. This is similar to Gosling's ideas regarding exclusion of operator overloading and any mechanisms of multiple implementation inheritance, and, above all, checked exceptions. Specially the later is one of the worst ideas ever and Java will forever be damned by the inevitable boilerplate code that comes with checked exceptions.

Those were terrible ideas that sounded great in paper, but did not deliver in practice. Same with a lot of things about C++, or with Stroustrup's position on C++ (in great part the result of what was known at the time about compiler and language design.) There are some interesting and, at the time, revolutionary ideas in C++, like const functions and references, but thing of the convolution involved in making const functions be actually "const" (in particular when the same method is overloaded for const-ness and non-const-ness.)

In C, I don't have to worry about the semantics of const-ness, or throw declarations (which really never worked as intended), or whether I need to inherit as public, protected or private, whether I inherit virtual, whether my default and copy constructors and assignment operators are done right, that I'm not calling copy constructors accidentally. And so on and so on.

Yes, I have to put a lot more elbow grease in C to get many of the benefits of C++, but that's manual labor over very clear semantics. Your only gotchas are your pointers, and that's it.

C++ provides superior mechanisms over C for handling large bodies of code compared to C, but the body of knowledge required to learn and use C++ well is not trivial at all. It is far larger than C's.

Any attempt to teach some stripped-down, C-like "lite" C++ version is a terrible disservice to anyone trying to learn that powerful and complex language. And that is why, IMO, a student needs to have more programming elbow grease, more programming credit/hours under his/her belt to really tackle the language. I would also make the same argument against Java as a first-language, or against introducing OOP without having some practice in procedural programming from a purely algorithmic/modular point of view.

Leandro Coutinho wrote:

Luis Espinal wrote:Notice that I mentioned C as a first-language candidate. For all the low-level gotchas in it, it is much simpler than C++, to the point of having a bare-bones elegance to it.

C++ has more features, but it is simpler than C.

How is it simpler? I work with both (and Java), and I cannot imagine how C++ is simpler, even if you stick to its most simpler features. C++ introduces subtleties in how structs, unions and classes are initialized, for instance, things that you do not have to worry in C. You have to ponder whether to use iostreams or the old printf-like functions for input and output. You have to wonder whether to use C-like strings (which is an anachronism onto itself), or create a custom String class (a good pedagogical exercise, but still an anachronism), or introduce the std::String. And if you do the later now you have consider whether to explain what the STL is, what '::' is, and whether to explain that std::String is a typedef of basic_string<char>... and now you have to consider how and when to introduce template meta-programing... and so forth and so forth.

Leandro Coutinho wrote:You don't need to teach all C++ stuff from the start, and you can do almost anything in a C style.

I used to believe in that, but quickly forego of the idea as I've had to update my C++ knowledge to meet current demands. Teaching C++ with a C style - akin to the old 'C with Classes style' of the early 80's - doesn't do students any favors. Even if one uses a stripped-down form of C++ typically used in embedded systems, the modern style is so far removed from the old C-like style that it defeats the entire pedagogical purpose of teaching the language.

Leandro Coutinho wrote: Also, you cannot put a language where string is not a basic type as a first-candidate!

Why not? It has been done before, and it is being done now at many universities with varied degrees of success. Besides, a string is just an array of characters with a null-terminating flag, a basic concept that any freshman should be able to handle right of the bat (yes, he/she should, we are not talking about arrays to pointers to functions or anything like that.) And the treatment of string functions in C is in many ways parallel to what one would do in classical BASIC - in both languages you call functions on strings for comparison, length calculation, etc (as opposed to calling equivalent methods in String objects.)

The only thing that is difficult with C strings is that you cannot do dynamic concatenation... at least not without *thinking* before hand. And that is one hell of an advantage (or hurdle depending on how you see it.) So you have an earlier intro to memory management, great! And I'd argue that string formatting a-la printf is extremely versatile and easy (like BASIC's PRINT USING statement).

Leandro Coutinho wrote:

Luis Espinal wrote:... or Java, not so much. These two are languages for work, not for teaching, and a person learning them should have enough man-hours doing programming (both procedural and object-oriented) to better understand and utilize these beasts.

Maybe with Java 7 and 8, it will become a beast. But now Java is not a beast at all.

No. I'm not referring to the functionality being added to the language when I refer to it as a 'beast'. I'm referring to more innate, basal syntactic characteristics present since Java 1.0. Also, I would argue that Java 5 introduced a great deal of functionality of a bestial size. Great functionality mind you (java.util.concurrent, generics, auto boxing, etc) but nothing that actually has to be dealt with on an early intro to the language. Similarly with whatever being introduced Java 7 or 8 (with the exceptions of lambdas and strings in switch statements.) But that's a different argument altogether...

Again, I'm referring to the signal-to-noise ratio one must deal with when teaching the most basic concepts. Consider the following. Compare the effort I need to do to write the following BASIC program

PRINT "hello world"

into equivalent Ruby, Python or even C or Pascal, and the compare that to the same effort involved with Java. If I go the Java route, I would have to teach

1. that I need to call System.out.println to print it (what is System.out.println? why not println? why does everything has to be within objects, what is an 'object')?
2. that such a statement must be in a static method (what is 'static'?)
3. that it must be encapsulated in a class (what is a 'class'? isn't that the same as an 'object'?)
4. that the class must be public (what is 'public'?)
5. that a public class (whatever that is) must be in its own file, and that the file must match the name of the class.
6. when I execute it, I got to invoke the interpreter just with the class name (but not with the .java or .class extension)... why?
7. oh wait, and let's not get into having to teach about the classpath, which can be obviated if we use an IDE... and then now we have to deal with IDE selection, setup, etc, etc.

Not even C has so much ceremony for such a pitiful trivial pedagogical task. Either I deal with this and teach it, or I wave my hands and claim that is all hocus-pocus that will be explained in due time. Neither is satisfactory. Pascal would be the #2 language with the most ceremonious boilerplate after Java (and with a lot less boilerplate). With C, all I have to explain is that I need to have a main function, and that I need to include <stdio.h> to call printf. With Ruby or Python, the task of teaching is trivial.

And that's what make Java, among other reasons, unsuitable as a first-programming language (let alone as the only programming language as sadly being done in many Java Schools.)

Java, and any language that forces a complete and absolute noun-centric OO paradigm suffers from a problem of tying functionality and characteristics to identity. This was identified as early as 1993 in Harrison and Ossher's paper "Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993, and humorously covered in Steve Yegge's parody of the Kingdom of Nouns (both good reads for anyone serious about working in software.)

This is a problem that has fundamentally plagued Java since its inception (for a pedagogical function, since it is a somewhat decent language to do work as I previously stated.) The amount of collateral information that needs to be introduced to fully explain basic concepts is way too large compared to other languages, even C.

Leandro Coutinho wrote:I think Ruby and Python are better for the job. Their syntax is easier and they have an interactive shell.

The benefit to learn a more low level language first is that it will be much easier to learn the other languages.

I would pick Python or Ruby over C++, but not for the reasons you mentioned. I think C++, and Java, are horrible languages from a pedagogical point of view. Python, Ruby (these two with a focus on procedural programming first), BASIC, Pascal or C would serve better as a first programming language. For me, my freshman/sophomore trajectory was BASIC, Turbo Pascal (with Object Orientation), C, C++ and, then Assembly. I think it was a good trajectory.

Notice that I mentioned C as a first-language candidate. For all the low-level gotchas in it, it is much simpler than C++, to the point of having a bare-bones elegance to it. Pascal is another language I would put next to C. Not nearly as low-level as C, but with enough power to do low-level programming.

Regarding Python and Ruby, I do not believe their simpler syntax is easier (and whether their syntax is easier is debatable), nor having an interactive shell is all that crucial. What is excellent about these languages (like BASIC) is that it lets you program procedurally. That is, unlike Java, it does not force a OO paradigm down your throat. OO is great for solving and modeling problems of a certain scale, but not everything can be modeled from a OO pov.

A student should first learn how to think algorithmically and how to do function decomposition, because everything down to object methods breaks down into sequential procedures. People do not learn to do this correctly if all they know is objects, objects, objects (as in Java.) That is the main problem with Java.

And with C++, the main problem is the complexity of the language. Like Java, a person needs to have a certain amount of programming dexterity to learn how to use it well.

I think it is also a matter of quality of teaching. So assuming a good professor, Python, Ruby, BASIC, Pascal or C would be good choices for a first programming language. C++ or Java, not so much. These two are languages for work, not for teaching, and a person learning them should have enough man-hours doing programming (both procedural and object-oriented) to better understand and utilize these beasts.

Joey Sanchez wrote:It is not enough to learn one language if that programming language supports all you need to do. I mean, if you are focused in web developement, for instance, when are you going to need C++?

I'd start by saying that no single programming language supports all we need to do for app development (in particular for web development.) Then, I'd add the following:

- "The act of trying to learn a new language will make you a better developer." ---- StackOverflow Podcast, episode #42

The path to a successful career in software, or in anything for that matter, is to always, always, always differentiate between your job and your career. Obviously, time constrains will dictate how much leeway one can have in learning stuff that is not directly applicable to one's current job tasks. However, it is important to be acquainted to the intricacies of both systems-level and application-level developer.

Now, this is just my opinion, and as objective as I think it is, it cannot escape the subjectivity of my own pre-conceptions. Ergo, please take this with a grain of salt.

Plus, you never know if web development is all you are going to do for a living. If we limits our knowledge to application development (or systems-level development for those sitting on the other side of that fence), how can we make informed decisions about our career paths.

Putting that aside, just for the sake of constant improvement in one's programming skills, learning a new language (in particular one very different from our bread and butter) is a must that should be done every once in a while. We are not talking about excellency or proficiency (that only comes from doing actual work.) A simple acquaintance suffices.

And IMO, knowing the basics of C or C++ sufficiently to write, compile and debug a not-too trivial toy program (even with the help of google), that should be a desirable trait.

Paul Santa Maria wrote:I don't think there's any question that C++ was a dominant force throughout the MS Windows era of the 1990's and early 2000's.

No. AFAIK from as early as 1994, the dominant languages for application development in Windows at that time was VB, PowerBuilder, VFP, Delphi. C++ was only used for systems-level Windows development then... and now.

Paul Santa Maria wrote:But with Java/J2EE entrenched in the enterprise, so much work being done in C#/.Net instead of C++ for Windows applications, Objective-C and Java dominating the smartphone/tablet space, and Javascript everywhere imaginable...

How would you write an operating system with any of these? Or a compiler? Or a database engine? You are conflating application development (and very high-level application development) with systems development. The enterprise is just but a sector of the software development market. It doesn't even constitute the majority of deployed systems out there.

Paul Santa Maria wrote:... do you think there's any place left for a language for a language where you can inadvertently wreak havoc if you forget to write a copy constructor when you use a list, or forget to create a virtual destructor for a derived class, or a million other subtleties that so many developers don't even have a clue about?

I think that's a loaded question robbed from much of its objectivity. Many of those gotchas have to do with specific features required for both 1) systems development, and 2) interfacing with C libraries.

Secondly, it's not like Java does not have it's gotchas (making the original assertion less objective.) Man, I made a living for quite a while just cleaning up Java code left by *Java* developers who didn't know about them. A garbage collector is the greatest thing for application development, but unfortunately, way too many developers completely forget how to write apps for it, completely oblivious that Java does not have proper destructors (finalizers are useless and downright dangerous), leading this to database connections and sockets being left in GC limbo until they get reclaimed, if at all.

C++ has many subtleties that many developers don't have a clue about. And Java has many subtleties that many developers don't have a clue about either. But that's the fault of the developer, not the language. It always is.

So it does not make any sense to make that kind of language evaluation since it is the developer's job to know about them. Just as there are guidelines for coding in Java (think "Effective Java" and "Java Gotcha" books), the same exist for C++, and any developer worth his salt (be it Java or C++) abide by them.

Paul Santa Maria wrote:Just asking if you think *other* languages, like Objective-C, Javascript or - yes, Java - might be nudging C++ toward irrelevance.

One would hope that people should be aware there is a lot more development going on outside of the enterprise/web arena. Operating systems, file systems, database engines, device drivers... not to mention that the number of embedded systems running in PIC or AVR chips (think thermometers, microwave controllers, car computers, etc) far outnumber the number of enterprise/web deployments. So the answer is no: we don't see a demise of the "C++ era" (or the "C era" for that matter.)

Why people completely forget this is strange to me. Not trying to be derisive, but I think it is extremely detrimental to not be aware of the entire landscape of computing and software engineering. C and C++ have not been used for widespread application development for the last decade or so, and that is true. In fact, it would be crazy to do so since we now have application-level languages that are much better for that type of tasks.

But to extrapolate the relevance (or lack thereof) of C++ from the point of view of (very high-level) application development does not make any sense.

Imagine an embedded developer that has not done anything but C programming in little 8-bit PIC CPUs (which are pretty much the most widespread deployed type of systems in the world) asking whether Java is relevant since he cannot use the later to program the former. It would be absolutely strange, if not non-nonsensical.

Same here.

Jari Timonen wrote:http://java.sun.com/javaee/support/training/

upcoming Java EE 6 seems to have SCJP as pre-requisite to all certifications. ??

No (unless I'm reading the diagram wrong). The SCJP is a pre-requisite for courses (formulated and delivered by Sun) that can help you prepare for the other certs, not necessarily for all the certifications themselves. Probably this is where I was first got the mistaken impression that we needed the SCJP for the SCEA.

Deepak Bala wrote:SCJP was never a pre-requisite. So yes you are on drugs

Oh man, these drugs must suck since they made me think there were more pre-requisites instead of less or none, with butterflies, colors and stuff

Thanks everyone.

- Luis.

Did things changed after Oracle's acquisition of Sun, or I was on drugs?

Unless I'm imagining things, I clearly saw in the pre-Oracle Sun page for the SCEA that having a SCJP was a prerequisite.

Now (at least as of today March/11/2010, 11:13AM EST), when I look at the post-Oracle SCEA link below, I do not see such a requirement anymore.

current SCEA cert link


Mind you that it was almost 10 ago that I last checked the SCEA requirements (after passing the SCJP). Was I imagining things, or did the requirements actually change?

Thanks,

- Luis.

Did things changed after Oracle's acquisition of Sun, or I was on drugs?

Unless I'm imagining things, I clearly saw in the pre-Oracle Sun page for the SCEA that having a SCJP was a prerequisite.

Now (at least as of today March/11/2010, 11:13AM EST), when I look at the post-Oracle SCEA link below, I do not see such a requirement anymore.

current SCEA cert link


Mind you that it was almost 10 ago that I last checked the SCEA requirements (after passing the SCJP). Was I imagining things, or did the requirements actually change?

Thanks,

- Luis.