Slashdot Mirror

Use sprintf(3), surely?

I always get a kick out of new C++ programmers starting with Visual C++; using MFC classes like CFile or CTime without realizing that the stdlib provides the same functionality without cripling portability.

I do not, however, feel that using Visual Studio "rots the brain"; it merely stunts a coder's growth, in the same way MFC does.

Take a graduate mechatronic Engineer, a mechanical Engineer, a civil Engineer and an aerospace Engineer. Give them each problems from the other's field and appropriate references. They will struggle with unfamiliarity but they WILL be able to competently solve the problem, why?? they are all trained in the same basic principles. Hand a computer "engineer" a fluid dynamics problem and they will almost certainly NOT be able to solve it.

I agree with you fully, however (and I am just as subjective, but with much less experience):

- The "Computer Engineering" field is highly chaotic. As an example, take a look at some online programming contests, such as UVA, SPOJ, TopCoder, etc.: you will find that each problem is wildly different. In particular, SPOJ's problem SBSTR1 requires doing a simple task, but only in one of three programming languages (a converter from one language to C is currently found here.) While any engineer could do this, giving reference materials beyond the basics would effectivly be solving the problem for that engineer (and thus defeat the purpose of that problem.) Only computer engineering does (or should) train students to solve these kinds of problems, where new algorithms get invented.
- The same could apply to practical aspects as well. Thankfully, most practical aspects are considered simple, such as creating a database - however, there are some cases where things may become difficult.
- The traditional engineering fields are normally based around known algorithms and solutions (unless you are doing research, but that's more like science rather than engineering). Computer Engineering is also based around known problems and solutions. This seems similar, but Computer Engineering has much more focus on communication and art than traditional engineering - it is generally used to solve business problems as opposed to physical problems.
- Compter engineering allows for rapid development, where a product is rushed in hopes that it can be fixed later (or when requirements keep changing: using traditional engineering as an equivalent, it's no different than changing the size of the bridge mid-way through). This is very rarely an option with traditional engineering. Whether software engineering should permit this is another story.
- On a day to day basis, computer engineering has to deal with users, while traditional engineering has an interceding organization as a middle-man. Some of these users think that their Operating system is Netscape, that their web browser is Microsoft Word for Windows, and that their word processor is MacOX 9. That's right, they mince words in addition to what platform they think they are running.

Given the diversity of hardware just on one architecture, computer engineering is more concerned about trying to fit square pegs into holes of various shapes and sizes. Sometimes, the peg is too small, othertimes, the peg is too large.

Anyway, not trying to belittle computer "engineers", but I think their training has to step up several levels in rigor and broaden its scope to truly be considered an Engineering discipline before you start laying the burden of personal liability on their shoulders.

I agree here as well. I only discovered (too late) that a software engineering diploma/degree is useless by itself - the only reason I took that field in particular (as opposed to a straight computer programming diploma or one that focuses on electronics) was because it simply looked like a better course on a fast glance.

Computer "engineering" is really a much different field than traditional engineering - but it really could have a lot more content in the academic aspect to get things up to speed. Computers have been around for at least 50 years - which is long enough to state that it should be converted into an engineering dicipline as oppo

Take a graduate mechatronic Engineer, a mechanical Engineer, a civil Engineer and an aerospace Engineer. Give them each problems from the other's field and appropriate references. They will struggle with unfamiliarity but they WILL be able to competently solve the problem, why?? they are all trained in the same basic principles. Hand a computer "engineer" a fluid dynamics problem and they will almost certainly NOT be able to solve it.

I agree with you fully, however (and I am just as subjective, but with much less experience):

- The "Computer Engineering" field is highly chaotic. As an example, take a look at some online programming contests, such as UVA, SPOJ, TopCoder, etc.: you will find that each problem is wildly different. In particular, SPOJ's problem SBSTR1 requires doing a simple task, but only in one of three programming languages (a converter from one language to C is currently found here.) While any engineer could do this, giving reference materials beyond the basics would effectivly be solving the problem for that engineer (and thus defeat the purpose of that problem.) Only computer engineering does (or should) train students to solve these kinds of problems, where new algorithms get invented.
- The same could apply to practical aspects as well. Thankfully, most practical aspects are considered simple, such as creating a database - however, there are some cases where things may become difficult.
- The traditional engineering fields are normally based around known algorithms and solutions (unless you are doing research, but that's more like science rather than engineering). Computer Engineering is also based around known problems and solutions. This seems similar, but Computer Engineering has much more focus on communication and art than traditional engineering - it is generally used to solve business problems as opposed to physical problems.
- Compter engineering allows for rapid development, where a product is rushed in hopes that it can be fixed later (or when requirements keep changing: using traditional engineering as an equivalent, it's no different than changing the size of the bridge mid-way through). This is very rarely an option with traditional engineering. Whether software engineering should permit this is another story.
- On a day to day basis, computer engineering has to deal with users, while traditional engineering has an interceding organization as a middle-man. Some of these users think that their Operating system is Netscape, that their web browser is Microsoft Word for Windows, and that their word processor is MacOX 9. That's right, they mince words in addition to what platform they think they are running.

Given the diversity of hardware just on one architecture, computer engineering is more concerned about trying to fit square pegs into holes of various shapes and sizes. Sometimes, the peg is too small, othertimes, the peg is too large.

Anyway, not trying to belittle computer "engineers", but I think their training has to step up several levels in rigor and broaden its scope to truly be considered an Engineering discipline before you start laying the burden of personal liability on their shoulders.

I agree here as well. I only discovered (too late) that a software engineering diploma/degree is useless by itself - the only reason I took that field in particular (as opposed to a straight computer programming diploma or one that focuses on electronics) was because it simply looked like a better course on a fast glance.

Computer "engineering" is really a much different field than traditional engineering - but it really could have a lot more content in the academic aspect to get things up to speed. Computers have been around for at least 50 years - which is long enough to state that it should be converted into an engineering dicipline as oppo

The SPOJ project from Poland has a bunch of algorithmic problems to which you can submit answers which are verified automatically. For most of the problems, you can use pretty much any language, although some of the problems restrict you to one language.

I prefer competitions that involve short problems.

Top Coder is a very large event, with thousands of participants. They have weekly-ish small competitions, and multiple times per year they have cash prizes ranging from $1000 to $100000.

Sphere Online Judge is another great competition, although far smaller and with no real time limit. No prizes, but much more varied and fun problems, with a HUGE selection of programming languages and completely automated judging.

I recently found a cross-platform (Win, Mac and Linux) editor called MoonEdit which seems to do SEE's live-collaboration thing okay, although I don't think it uses Zeroconf to do so. I wouldn't recommend it as a code editor, as it has a number of interface conventions that... well... let's just say that the thing feels aptly named. But for joint note-taking or the kind of fiction described here, I bet it'd work fine.

I've been looking for a few months now for a cross-platform alternative to SubEthaEdit. There exists a plugin for jEdit, but that's implemented on top of IRC and is a bit of work to set up

Just recently discovered MoonEdit which is a little more like what I need. The collaboration works very well, but it's a bit light on other features..

A port of SubEthaEdit would be so nice...*dreams*

I clicked on that link. Saw a source comment with 'Ken S.' on it.

Sure enough, Ken Silverman (of Duke3D/Build fame) wrote it.

Collaborative text editors were a hot research topic about 8-10 years ago, and it turns out to be quite hard to get them right.

The only mostly-finished one I could find that runs on Windows (and Linux!) is MoonEdit. Anyone want to put a server up and try it?

Nice quote, but (in all seriousness):

Multiplayer notepad is Moon Edit (Windows & Linux) or SubEthaEdit (OS X).