Comment by j2kun | Hacker News Reader

Comment by j2kun | Hacker News Reader

Parent Full thread

People in academia simply don't care about the quality of one particular implementation of their ideas. There's no value judgement here, it's just not their job to write and maintain good software. Just as it's not a mathematician's job to maintain a cryptographic protocol or a physicist's job to keep a satellite in orbit. The people who went to schools with strong research programs are trained by people in that mindset.

It's a simple question of motivation. If they're brilliant and they have motivation, then of course they could write great software. They just don't.

Make no mistake, people from schools like Cal Poly SLO (a state school, and my alma mater) who excelled in their CS programs can software engineer circles around most. Why? Because Cal Poly has no research program, three quarters of their faculty come from industry, and their faculty have no job requirements outside of teaching. They literally had us managing five to ten thousand line software projects with teams of students in year two.

While I'm following you ideologically, I'm not sure that this idea bears fruit in evidence. The computer science community still uses large numbers of algorithms (via libraries) that were written by academics, in peer-reviewed journals, in Fortran, in the 1970s.

Even currently, a tremendous amount of the cutting-edge work in optimization and others is done at the university level: METIS for graph partitioning, and convex optimization work being done by Stephen Boyd et al. They care deeply about the implementation because quality and speed of solution are of utmost importance. A number (like Geoffrey Hinton and Sebastian Thrun) have moved into the private sector, but after contributing a lot via academia.

Have you ever seen Hinton's code before? It's all Matlab :) And when you are designing/prototyping algorithms, that is quite good enough.

I thing the problem here is you're comparing apples to oranges - the people writing code in the 70's are not the same type of people teaching students to code now.

In the 70's it would have been physicists, mathematicians or engineers writing code to solve a problem for them and their colleagues. Their code needed to be maintainable so they could share it in their academic community, and get things done with it.

Today, the people teaching computer science view code as the proof of concept. Much of the work is in the idea behind the code, and the code is just proof that it can be implemented in practice - and most importantly, isn't designed to be actually used.

The idea that the code is just the proof of concept then carries over to the students, and the mindset becomes not, "let's build this thing to do X', but "can we build a thing, in way Y to do X".

That last bit sounds amazing and highly valuable. I go to a well regarded top CS school and I regret that we don't have something like that in our curriculum that forces people to write multi-thousand-lines of code with a team and maintain it.

Our EE program has something like that where you choose a team and build something with them over the course of a semester while having an "advisor". At the end you make a report and present it to the advisor and the rest of the committee. It's a requirement for graduation. I think that's awesome and CS definitely needs something akin to that.

Science != engineering.

Engineers take what scientists discover and create and design solutions based on that. Computer science is not about engineering a large software solution. Rather it's about discovering and creating algorithms and techniques that engineers can use to design solutions.

Much of the comments to this article seem to be happy to mix the roles of "technician", "engineer", and "scientist" when they are in fact very, very different.

There are certain aspects of engineering which are definitely science. Science really is just the production of new knowledge with hard facts.

Engineers are Scientists with thumbs was what I was told when I worked for a RnD organization on CIT's campus.

The corollary to that is "but the technician is the one who really understands it :-) "

Your definition of engineering may have been appropriate around the time of the industrial revolution when an engineer was literally one who built steam engines, but modern engineering in the academic sense under discussion here is absolutely a science.

My job as a software engineer involves a mix of all these things. Not a lot of heavy algorithm development, but definitely some.

Engineering utilizes science. But not many engineers need to know as much as Knuth.

Hm that's a fair point.

Wikipedia describes "computer science" as an umbrella term covering everything pertaining to software development and algorithmic thought. Academic computer science programs generally offer courses in both the theoretical and the applied.

Even the very term itself has often been described as a misnomer, not necessarily having anything to do with "computers" or with "science".

I think the reason people mix such things around so much is because what "computer science" is has been ambiguously defined all along.

The truth is, CS is not a "science" like biology or physics.

It is an education in understanding computation and software development.

I'd also argue it is not an engineering discipline either. It's unfortunate the terms "Computer Science" and "Software Engineering" were ever accepted. They're holding us back; we're stuck in an outdated view of the subject.

I kindof disagree. For example while studying UML, it became more and more apparent to me how legitimate it is to have the word "science" in "Computer Science". Being able to create a high-level framework that is general enough to apply pervasively to IT systems is not a trivial matter, and requires considerable academic effort and creativity. The domain may be different from biology or physics, but the methods of obtaining that"understanding" you mention are strikingly similar (which accounts for the reliability of the results that are delivered).

Wait, did you just bring up UML as an example for backing up the claim that CS is science?!

I know UML is not very popular, but as you can see, I thought it was interesting.

In science, understanding is developed through abstract mathematics and empirical experimentation.

Whilst UML is an abstraction language, I would hesitate to compare it to a mathematical calculus. Regardless, we do not subsequently carry out empirical experimentation in the same way as science does. There is no "ground truth" that UML is modelling when developing software (ignoring edge cases) - it's a design tool.

They had to study existing software (empirical), and then find an understanding of what is essential and common to all cases.

The result was that a finite and compact set of concepts could be used to account completely for almost any design architecture, past or future. To me, this is pretty scientific.

Depends on the course.

I studied a bachelors in molecular biology, took a few years out (realised I didn't like the subject much) and studied a one years masters in IT a few years later. It was taught by the Computer Science department (Glasgow University in Scotland), but the focus was on writing good quality software - readable, maintainable, usable code.

There was an optional data structures and algorithms course which I assume is more geared towards traditional comp science. I took it, but in ten years of work, I rarely use this stuff (though its good to have a background so you know which library is a better choice).

One thing they didn't teach us was networkinq, which I am completely self taught. I can get stuff working, but I think having a formal education in things (like I do in OOP) can teach you where to focus to get things done in a professional manner.

Reply on news.ycombinator.com