Mohtalim

http://www.stsc.hill.af.mil/CrossTalk/2 ... nberg.html

Even when it is not the language of instruction in programming courses, it is the language chosen to teach courses in software engineering.

Is that true?

I think they meant THEY choose to use ADA to teach THEIR software engineering classes. I don't think most of us has touched ADA other than George, but I could be wrong.

Ada is pretty much dead outside legacy government systems. Those will be enough to keep Ada alive, much like Cobol and Fortran have been kept alive by the finance and scientific computation worlds. But I wouldn't waste time teaching anyone any of those languages. There's an aging crop of Ada, Cobol, and Fortran-skilled developers out there now that should die off at about the same rate as the hardware.

Yeah, those guys are full of crap. They say claim lack of a useful standard library is a strength! I hate Java, but I respect the library. Besides, having a library doesn't mean you can't learn to implement things from primitives. It just means that when you go to do real work, you don't have to.

Man, and whining about not finding new hires that know Ada? Anyone who knows any structured language can pick up Ada in a month and write as well as the Ada "experts" I knew.

I don't think I've used anything I learned from ML. Ever. In any language.

I have cross pollinated lessons in C, Visual Basic, C++, C#, Python, Tcl/Tk, Matlab, Java, and probably a few others. However, ML, Ada, Fortran, and Pascal were all completely useless as far as carrying any lessons forward. I needed to know them, but only for artificial reasons (the class was taught in it, or the legacy code was written in it). They didn't make me any better at writing any other language.

Oh, and I've seen C written by an Ada programmer. I guess it was marginally better than C written by a Java programmer.

I've only come across Ada in one article in our readings and it was used in a government project that required a lot of formalism. They chose it so they could essentially generate their code from specifications because the rework due to changed requirements would've otherwise killed the project schedule. How that worked, I have no clue, because I've never bothered to look at Ada further. If there were another article or two that mentioned Ada, I might have bothered. That article was also from like 1998 or something, which is a bit old. George's estimation seems pretty consistent with the lack of literature.

If you're teaching software engineering ONLY with Ada, then you have no idea what software engineering is. I should note that the trend towards less and less formalism is a bit disturbing from an engineering perspective. This was also specifically mentioned in a panel discussion I saw this past weekend. I don't want to extrapolate a trend from just two data points, but it is definitely something to keep an ear out for more info. However, the solution proposed was not Ada, but an evolution towards Language Oriented Programming, where you come up with your own language to suit the problem. I've seen people use Ruby's flexible syntax to start to do just this. Heck, rails is a bit of an example of this concept.

There are other practices in software engineering that can get you many of the benefits of using Ada without having to use or even think in an Ada way. I think the current MOTD is very apropos.

Mohtalim MOTD wrote:when the only tool you have is a condom, all your problems start to look like things you can have safe sex with

Ada is the condom and programming is sex. You may think you can solve all your problems with Ada, but it could be really tedious to do so. For instance, test-driven (or test-first) development is a common practice in agile methods and is a great way to make sure your code behaves how you expect it will. To extend the metaphor, TDD is like your partner using the pill instead of you using a condom and pleasure of the act is not dampened. There are still some risks, but a big one has been greatly reduced. On a side note, the tests can even be used as a sort of documentation of functionality. Some agilists go so far as to say that if there isn't a test for a feature, then it doesn't exist.

This was Joel's response to reading this article. I don't quite agree with what he says here, but it's an interesting idea.

I personally think this article is complete crap. The authors are just as bad as the regular media in attempting to spin numbers to evangelize their point of view and livelihood.

I think all of you will agree that computer science is hard and you're going to get good programmers and you're going to get bad programmers. The core concepts and how you teach them is more important than the vehicle. You can still teach almost every cs concept in Java (except maybe pointers) so the language really doesn't matter. How difficult your first classes are and the kinds of assignments given matter much more.

Jason wrote:This was Joel's response to reading this article. I don't quite agree with what he says here, but it's an interesting idea.

I personally think this article is complete crap. The authors are just as bad as the regular media in attempting to spin numbers to evangelize their point of view and livelihood.

I think all of you will agree that computer science is hard and you're going to get good programmers and you're going to get bad programmers. The core concepts and how you teach them is more important than the vehicle. You can still teach almost every cs concept in Java (except maybe pointers) so the language really doesn't matter. How difficult your first classes are and the kinds of assignments given matter much more.

Yeah, I got the link from Joel on Software.

I think if you lack the math and theory that a proper CS education offers, you'll never be able to architect a difficult design. You're stuck executing on problems that have been solved already, just not in the particular way your customers need.

Some of the /. comments on this link were trying to draw a line between university degrees where a fraction of the graduates might be expected to go on to advance the state of the art in computing and between a technical monkey sort of degree where the graduates are expected to hammer out code all day every day. Like a two year program.

I'm a nonexpert on these matters because the code I write requires so much domain specific knowledge we're all computer engineers with more or less software engineering background and there's no RCGs at all. I come in on the less side.

Dwindlehop wrote:I think if you lack the math and theory that a proper CS education offers, you'll never be able to architect a difficult design. You're stuck executing on problems that have been solved already, just not in the particular way your customers need.

I sorta agree with this, and yet it seems not quite right to me as well. There's a lot of room for innovation in executing on problems that have already been solved, but not for the specific needs of a customer. It's these unique constraints that can force innovation through the rejection of a conventional solution. Maybe this is the point that many projects fail when the person dealing with this situation has not been prepared to solve this new problem? This line of reasoning supports your idea. However, I believe that software is much broader of an undertaking than chip design in that it is often not application independent. There is often a significant undertaking to understand the particular domains in which the software is being written. I'd argue that a successful software architect needs to be able to learn and apply new disciplines very quickly. In this situation, it is less important to be able to come up with novel solutions to a problem, and instead more important to understand the customer's need.

Maybe the problems that software has with relating to people is derived from hardware's unrelenting head down approach to just providing more instruction functionality and throughput. If all I've got is x86, then every problem looks like it can be solved with a Core 2 Duo. Or, if all the hardware guys give software guys to work with are buttons, then everything must be solved by efficiently pushing buttons. In this latter case, you get the horrific way of texting using a numeric keypad on a phone!

Having, only now just read Joel's article, I think his point that universities should focus on things like game development is one that MANY schools are already turning to in order to keep CS enrollment up. I'm not convinced that it should be an art though. There's a lot of engineering process that should still be injected or else you'll get projects that never reach their goals except by chance. Perhaps in a university this is ok, but in business, this is definitely not ok.

heh, "What have the universities given us lately?" That's just wrong.

What's an RCG? Real Code Guru?

Recent College Graduate.

If all you have is the "if all you have is a foo, then all your problems look like bar" metaphor, then all your problems look like mismatched applications of hammers to screws.

What would software people pay for besides MIPS and FLOPS? Power and cost are the other two pillars of our value proposition, but I don't think that's what you mean.

I been here five years (six in June!) and I'm still the youngest perf guy. Damn PhDs.

Dwindlehop wrote:If all you have is the "if all you have is a foo, then all your problems look like bar" metaphor, then all your problems look like mismatched applications of hammers to screws.

Yeah, I'm beating a dead horse. It's a good metaphor though when you're trying to show fine differences between things that might look the same from 1000 feet, but are really very different once you get closer.

Dwindlehop wrote:What would software people pay for besides MIPS and FLOPS? Power and cost are the other two pillars of our value proposition, but I don't think that's what you mean.

There are a lot of similarities between hardware and software, however, hardware is much more constrained since you're bound by hard physical laws. These constraints give hardware some significant advantages because they give you some obvious design targets like Hz (MIPS and FLOPS now), W and $ which are partially dependent on other targets like cm^2 as well. What I was suggesting is that maybe there are some other targets that could be designed for, like usability. Usability may not apply to a single ASIC, but embedded system designers are responsible for making cell phones and the like. I'm sure they've driven some suggestions back down the line to come up with such things as touch screen and the like. Reliability and security are other "non-functional" requirements that are starting to show up in consumer hardware design more and more lately as well.

People who buy business machines will pay for reliability and security. Can't say that consumers seem interested enough to cough up some extra cash.

Problem: Required math classes scare people away from CS.
Solution: Require Latin and art history instead.

Joel's a genius. Given the track record of that curriculum, we can expect most BFA:CS graduates to end up working fast food. The industry will grow desperate and raise salaries, inspiring larger numbers of people to enroll in the real CS programs.

I came across this today in a search for the geek hierarchy picture (which came up in discussion work).

The Programmer Hierarchy

I think the placement of Java and Javascript should be reversed.

asm for the win!

heh, which means computer engineers >= other programmers