Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

The blogged wandering of Robert W. Anderson

Things I miss in C++

I have been working on the Attention recorder for IE 6/7 for the AttentionTrust in my “spare” time. I’m using C++/ATL for this.

I am enjoying working in C++ again (most of my development these days is in C#), but it has brought out to me my personal likes / dislikes about the two languages. I know this post is about 3 or 4 years late, but I wasn’t blogging back when I started with C#.

Things I miss in C++

  • Const pointers: The ability to declare that the data referenced by a pointer will be accessed read-only is quite useful. I never liked that this isn’t supported by .NET; though, I understand why it was.
  • Macros: This one still gets me. The macro support in C# is nearly non-existent. Why would you want macros? Doesn’t this violate the strong-typedness of the language? Yes, but stringizing and token-pasting is very useful to build maintainable code. I really wish C# supported this.
  • copy constructors: Having a default implementation of the copy constructor is quite useful.

What I don’t miss in C++

  • Header files: When I used to work in C++ I remember enjoying the distinction between the declaration and the implementation of classes and methods; however, now I just feel like it is an annoyance. The C# approach of leaving this up to the tools is much easier.
  • NULL: Back when true and false were added to C++ as language elements, I wished that null had been added too.
  • global scope: At first I didn’t like that C# has no global scope (outside of classes), but now I look at C++ and don’t like that I have to put methods that are clearly associated with a class implementation, but static, outside of the definition of the class. Certainly this can be handled with namespaces, but that doesn’t quite do it.

Of course, I much prefer the richness of the .NET Framework to the hodge-podge of class libraries required in C++ to do anything modern: ATL / MFC or WTL / MSXML, etc, . . . I also prefer the overall environment of garbage collection and pointer-safety delivered by a managed environment.

Tags: , , , ,

Perils of poor Computer Science Education — Part II

In Perils of a poor Computer Science Education — Part I, I said that I basically agree with Joel Spolsky in his post, The Perils of Java Schools. I do, but I can’t give the impression that this is the only path to being a great developer.

At UC Berkeley, the classes used Scheme, assembly, other languages, and primarily C. The very first course was nearly all functional programming using Scheme. I think using Scheme had three main purposes: to teach recursion (duh), to expand the students view into other programming models, and take the hot-shots down a peg — it leveled the playing field (a little). Most of the rest of the program was C. Here we used C for nearly everything including, of course, the complex data structures. Yes, lots of pointers.

So were the Scheme, C, and pointers necessary to help me become a developer of production-quality code? How often have I written a hash table for production? Rarely, but I’m way better at what I do because I know how to implement a hash table, and heinous balancing trees that I can’t even remember the names of, and how to debug at the machine level, and what a functional language is, etc.

That said, managed or scripted code is the way to go for 90% of the applications written today. Pointers aren’t so important and the data structures are covered by the frameworks. Clearly this kind of coding doesn’t demand the old-school Computer Science graduate. Merely great C#, Java, PHP, etc. developers run the gamut from important role-players, team members, to team leaders, etc.

I think the most important thing you can learn as a developer is to be flexible. Think outside of the constraints of the languages and tools that you use. If it helps you to learn a different language to enable this, do so. If it helps to go deeper into the runtime environment (e.g., deeper into the CLR or the Java runtime or the compiler / assembler, etc), do so.

Flexibility that is the practical lesson of the Computer Science program.

Tags: , , ,

Perils of a poor Computer Science Education — Part I

Joel Spolsky recently wrote about what he calls The Perils of Java Schools.

His main point is that Computer Science departments have dumbed-down their curriculum to increase their enrollment and graduation rates. One way this has been done, he argues, is by replacing the teaching of multiple languages with Java. Instead of teaching functional languages (think Lisp) and using a low-level languages (like C or C++), the student does all coursework in a managed object-oriented language. Not only does this mean that students aren’t as well educated, but that is harder to interview new graduates to find the really good ones.

Some people have bridled at the article because they see it as slamming Java. Others suggest that he should update his interviewing style because he says it is harder to evaluate people. These comments miss the point of his article.

I agree with him fundamentally that learning with a high-level language is just not enough. Kang Su Gatlin has a post about this as well: What Should Change in Comp Sci Education. I agree with him too (though would like to hear more from him regarding MapReduce).

I went to UC Berkeley when Computer Science departments were primarily interested in training Computer Scientists. No language courses were included as a part of the required curriculum — it was expected that we would learn the required languages on our own time (note: I’m sure the teachers-assistants must of helped students with languages and environments, but I either skipped those sections or have blocked it out because it was no help to me). In our classes, we used Scheme (to learn functional programming), assembly, and primarily C.

One of Mr. Spolsky’s main points is that routinely using a low-level language (like C) provides the student with critical experience. C is closer to the machine than Java or C# and forces the programmer to work harder. C forces the programmer to use pointers. Programming and debugging pointer-based programs develop and hone debugging skills. The experience of using these over my years in school was quite beneficial. Better to learn that at school than in industry.

So without fully condemning nor claiming to even grok what is motivating the universities to this end, I will say this:

I have heard from many people over my life that “pointers are hard.” If you have a Computer Science degree and you think pointers are hard then one thing is for sure: your Computer Science program failed you.

Tags: , , ,

« Previous entries