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

rwandering.net

The blogged wandering of Robert W. Anderson

Digipede Network 2.0

image The software is done, the press releases out, John and Dan talking about it in New York.  I can’t say I’m the first to announce it, but I may be the most glad that it is finished and released.

 

What is new?  A bunch of stuff, but I am most excited about . . .

  • Many changes have been made to Digipede Control — it is easier to use and looks better
  • The Digipede SDK now has tighter integration with Visual Studio 2005: now it is really easy to debug both sides of your Digipede applications.
  • Integrated Windows security

Of course, there are also improvements to the API, performance improvements, and more. 

Soon I will also be announcing the release of Java and PowerShell support in the form of fully functional samples with binaries (for those of you not interested in the details).

And now with 2.0 out, maybe I can find the time to blog a bit more 😉

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: , , ,