CAOS Weekly Philosophy: What it means to be a computer scientist?

[Brad Nunnally]

By now a lot of us can eat, sleep, and breathe code. Doesn't matter what language it is in, chances are there is one of us that knows something of it.
However, what does having these skills mean? Is being a computer scientist all about code writing, designing, and general programming? How are these skills going to shape our futures? What will we do with these skills to make a better tomorrow?
The big question here is this, what does it mean to be a computer scientist? We are taught so many different things from program languages and computer design, to software design and computer graphics. How do these help define what a computer scientist is?
There really is no one answer to this since the CS field is so wide and diverse, yet I think it would be helpful if we developed our own definition so we might have something to commit to for our own future.


Brad Ty Nunnally
CAOS Vice-Pres.



"It is a thousand times better to have common sense without education than to have education without common sense."
Robert Green Ingersoll

[Jerry]

While we spend significant amount of class time on techical aspects of computer science like programming, the core concept of computer science is the algorithm.

Being "algorithmic" is what should define a computer scientist. That is being a "problem solver", that goes beyond the use of computers. A well known HCI research once said, "if you assume a computer is part of the solution you have already limited your design".

[William Grim]

I agree with Jerry 100%.

Theoretically, technical aspects such as the computer and language do not matter at all when programming.  All you need is an algorithm that is as efficient as possible and the correct relationships in your data, and you can solve anything humanly possible.

Practically, languages do in fact matter.  Each language and particular computer carries various advantages and limitations.  You have to take these into account when working on your designs.  This is why CS is a kind of hybrid between pure math and engineering; we always want to achieve optimal algorithmic efficiency while remaining practical.

There are obviously other things to consider, such as HCI (this can include APIs, ABIs, and docs) and the given problem domain.  But, in the end, CS really comes down to the algorithm.  Without an algorithm that is efficient enough for what you're trying to do, why even consider aspects such as HCI?

In my personal opinion, the best computer programmers are those that are heavy into math and enjoy creating scalable, maintainable software designs while understanding all the nitty-gritty technical details in CS.

[Tyler]

I find it interesting that I am a Senior in Computer Science and about to graduate with my degree, and this is the first time I've heard this question addressed either inside or outside of the classroom. :shocking:

~tfizzle

[Jerry]

tfizzle wrote:
I find it interesting that I am a Senior in Computer Science and about to graduate with my degree, and this is the first time I've heard this question addressed either inside or outside of the classroom. :shocking:

~tfizzle

Yeah, this is something the faculty struggles with constantly. If you look at the course descriptions, specifically the intro CS classes, you'll see the phrase "problem solving", which is to say "algorithmic problem solving".

The challenge we have is how to teach problem solving. Its easy to teach tools like C/C++, Visual Studio, VB ... . It's difficult to teach more abstract concepts like problem solving.

Some teachers believe that problem solving skills come directly from teaching programming techniques. I'm not one those teachers. I believe that we should be teaching problem solving more directly along with programming.

[William Grim]

I think courses like CS 340, CS 456, and Senior Project taught me the most problem solving techniques.

[Jerry]

grimw wrote:
I think courses like CS 340, CS 456, and Senior Project taught me the most problem solving techniques.

At Vanderbilt the Algorithms course had no programming. Each week we had a homework set (no exams). Each homework was of the form: come up with an algorithm to do something in a specific time, like N or N(log N), and prove that the time is guaranteed.

The faculty member who taught the class would give you a couple of points if you admitted you did not know how to do a particular problem rather that waste his time with complete BS.

As an aside he was also a punk rocker back at Princeton in a band called "The House Plants". At the end of every semester he would offer to sing one of the bands original songs. During the semester I took the class he sang "Born to Be Sonny Bono", which is even funnier if you know him because he has an uncanny resemblance to Sonny.

[Tyler]

I think I did learn problem solving techniques back in CS 140.  I remember I had to sit down sometimes and think how do I translate these thoughts into something that can be programmed.

I used to tutor CS 140, and when someone faced a particular problem, this is what I did.  I would ask them the question and make them give the answer in normal lamens terms, then I would ask how they came up with that answer--what steps their mind went through to come up with it.  That's most of what algorithms are to me--translating our normal (almost) instictual responses into simple processes that can be coded.

~tfizzle

[Jerry]

tfizzle wrote:
  That's most of what algorithms are to me--translating our normal (almost) instictual responses into simple processes that can be coded.

~tfizzle

That's certainly one aspect of problem solving, but there are many others. For example recognizing that two problems are analogous and that a solution for one could be an efficient solution for the other.

A good example is tic-tac-toe and the magic square. For those of you who aren't familiar with a magic square it is a grid of numbers, 1 to 9, in which all horizontal rows, verticle columns, and the two diagnols add up to the same value. It turns out that you can use a magic square to efficiently code a tic-tac-toe game.

Similarly, many planning problems like scheduling are some form of a graph constraint problem.

[Tyler]

Still so much to learn  

[Jerry]

tfizzle wrote:
Still so much to learn  

Always.

There is a classic text on problem solving called "How to Solve It" by Polya. It is a study on problem solving written in 1944, but still relevant.  It is also considered the source for the AI definition of "heuristic".

Here is an excerpt:
http://www.math.utah.edu/~pa/math/polya.html

[William Grim]

Similarly, many planning problems like scheduling are some form of a graph constraint problem.

Don't talk to me about scheduling problems... we had this dynamic programming scheduling problem in 456 that was sooo hard... blah blah blah...

Or maybe I'm just stupid.   :-?  :lol: