Could you expand on this? What elements of a CS curriculum do you find irrelevant to software engineering? What elements do you think are missing?
There is very little I learned in my CS degree that I have found to be useless, even if it wasn't immediately obvious how to apply it.
We got over it. While natural selection explains the existance of species such as our own, this doesn't mean it's a value we should hold dear. Survival of the fittest is a cruel doctrine, and one which we should be glad to avoid (or lessen the impact of).
Calling someone a "second rate" human implies some sort of universal criteria to judge them. I don't think such a criteria exists. You can call someone a second-rate guitarist (I am!), but a second-rate human is quite another thing. Are disabled people "second rate"? No.
Does this web-spreadsheet store the information on Google's servers, or is it a client-side application that happens to run in a browser? I don't use spreadsheets very often, but every time I do they usually contain sensitive information (financial data, students' exam marks etc), so letting that data sit on Google's servers would be pretty irresponsible. I'd also be worried about violating data protection legislation in some cases.
One day, someone is going to make something intelligent, and then turn it off, and there will be an outcry. Is anyone doing the thinking on the ethics of making it before making it?
Yes, of course people are thinking about this. Philosophers, cognitive scientists and AI researchers all frequently discuss such subjects. But why would turning an "intelligent" computer off cause an outcry? A truly intelligent agent will likely need a substantial amount of memory. This suggests to me that it will involve a persistent disk-based store. So turning off such an agent wouldn't "kill" it; it'd be much more akin to going to sleep (especially if you used this downtime to perform maintenance and hardware upgrades). Simply turn it back on. You'd have to actually wipe or physically destroy the disks in order to "kill" the agent. In addition, the computational power required will probably mean that the agent is simulated on a cluster of machines, rather than any one machine. Thus turning off any one machine may lead to a performance degredation or loss of specific abilities (much like a stroke), but would be temporary rather than permanent.
"Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM,..."
Comparing that to the description of DHTML itself at w3schools:
"To most people DHTML means a combination of HTML, Style Sheets and JavaScript."
DHTML also seems to involve a fair amount of DOM. So what is new about AJAX? Is it just the addition of XMLHttpRequest? And... didn't Microsoft invent that?
Are you sure that compiles in Java? It looks more like C#, which allows finally blocks without catch.
Even if you somehow get it to compile, if you throw a new Exception there the excecution won't go through the clean up code in the finally block.
It's valid Java. You can specify a finally block with no catch blocks. A finally block will always be run, even if an exception is thrown (the exception will still propagate). For example, I sometimes mark undergraduate concurrency coursework/exams written in Java. try-finally blocks are used there to ensure correct lock management:
If you check out the blog, you'll see that there's a nice goto at the end of the if statement.
Supposedly Google only hires top-coders, so what's up with that?
Lots of C-coders use goto in this situation where you want to exit a function early but need to do some cleanup first. It's often considered an acceptable exception to the no-goto rule, as the alternative is usually even more unreadable. Think of it as a work-around for the lack of a try-catch-finally construct. e.g., where in Java you might use:
// Allocate some resource... ... try { // Do stuff if (someErrorCondition) throw new SomeException; } finally { // Release resource }
This "analog AI research" sounds quite like Braitenberg's "Vehicles". It's interesting stuff, demonstrating that it's much easier to create something that exhibits complex behaviour, than it is to work out how something works by observing its behaviour (complex behaviour may be the result of a complex environment).
"It was fair, though not legal, for Rosa Parks to sit in the front of the bus.
It was fair, though not legal in many states, for gay people ot have intimate relationships.
It's fair, though possibly not legal, for me to play my legaly purchased games from any media I choose on any platform I choose."
Is this a joke? Are you seriously trying to suggest that these are in the same league? Frankly, I find these sorts of thoughtless comparisons rather offensive. People died fighting for civil rights.
Besides, why is it more "fair" to be able to play the same game on any media on any device, while only buying one copy? I can see that it's cheaper, and more convenient, but I'm really not seeing the "fair" here. You bought a game for a specific device, and it plays (presumably) on that specific device. I agree that it would be "better", but I don't think it would be more fair.
"... The fact that I don't have to do this:
JPanel jp = new JPanel();
JComponent jc = ((JComponent)jp);
or Node xmlNode = (Node)xmlElement;
sounds quite good."
I think I get what you are trying to say, but the examples are bad. The first one doesn't require a cast now, as you are casting from a subclass to a superclass:
JPanel jp = new JPanel();
JComponent jc = jp;
works just fine (just tested in 1.4.1). I imagine the same applies to the second one too. Also, if this wasn't the case generics wouldn't help in this code. Generics only remove the need to cast when extracting an object from a container, if I understand things correctly.
In some ways, yes. It's not a perfect solution. Note that you can still use shared libraries in a starkit. There is the problem of how to allow other programs to access useful shared functionality in a starkit. This is possible too, as starkits can be sourced into a VFS-enabled Tcl interpreter (ActiveTcl and TclKit support this).
Starkits aren't a silver bullet, but I think they go a long long way to useful cross-platform deployment with the end-user in mind. Plus, as a bonus, your application gets access to the Metakit embedded database library, which is very useful for storing configuration and application data.
There are more problems to solve, but this is a big step in the right direction, and it works extremely well. A good example of this is the Tcl'ers Wiki. The Wikit starkit contains all the code to run the wiki, and will run as CGI or a standalone Tk application. You can configure it to store all the pages in the starkit, so mirroring is a case of simply copying the file. As all the pages are stored in a Metakit datafile you get efficient searching and retrieval for free. The resulting starkit can be included in another starkit or application without change, for instance to provide a help system.
There are many many more reasons why starkits are cool. It would be nice to see the concept catch on in other languages (starkits are taking the Tcl community by storm, and ActiveState support them in the new TclDevKit releases).
I think more people should take a look at tclkit (http://www.equi4.com/tclkit) and the concept of starkits (http://www.equi4.com/starkit). This is a great concept where an application is delivered as one self-contained file (compressed, with an internal virtual file-system). This gets rid of the problem of "installation" all together.
Firstly you comment on lack of good libraries (perhaps missing Expect and Tk as obvious counter-arguments). There are plenty of libraries for Tcl of very good quality, as a quick trawl of the Tcl'ers Wiki, the Tcl FAQ or the Tcl developer exchange would show you.
Next, you move on to not supporting various programming paradigms. I'm completely lost by this statement. Tcl supports procedural, functional, OO etc styles quite easily. One of Tcl's key advantages is that it is easily adaptable to new paradigms. The fact that Tcl only contains the basic constructs for procedural programming in the core command set maybe where you are getting this from. A bit more in-depth look would show you that Tcl easily allows you to build on these to create whatever language/programming environment fits your problem. It's a very powerful technique.
Life outside the ivory tower seems to use Tcl quite a bit, if you look at places like IBM, AOL and NASA. Tcl is used in misson-critical applications which have run 24/7 for years.
As for syntax, Tcl has used the minimum set to do the job well. If you don't like using whitespace to delimit function parameters, you can define your own function construct which takes parameters separated by commas, or whatever. That's the beauty of Tcl - if you don't like it, you can change it *from within Tcl!* See wiki pages on Radical Language Modification and others for more details.
On top of all this, Tcl has great i18n and asynchronous I/O which most other languages still don't come anywhere near (especially on Windows). Threading is getting very robust. Virtual filesystem support, which enables technology like starkits, is also very cool. Tcl still has a lot to recommend it.
There is no copy-protection on the game, but people with CD keys can download extra stuff.
Is the extra stuff copy-protected, then? Otherwise, when someone decides to put this extra stuff on Kazaa or somewhere, then it's all going to fall apart, surely?
Actually, if you read the blurb at the bottom, the article is based on the original English transcription of the interview, which was later converted to German for the magazine. It is old though. I'm sure I've seen this on/. a long time ago.
As a reasonably active member of the Tcl community, I can say that there are plenty of people using Tcl out there. The wiki grows at a tremendous rate and the newsgroup is very active. Also, NBC are not the only people using Tcl commercially - for instance AOL use it in AOLServer (as was mentioned in the round-up) and IBM use Jacl (the Java implementation of Tcl) for automating WebSphere. Learning a language because it looks good on your CV/Resume is perhaps not the best engineering practice, but I admit it probably gets jobs. However, surely being able to pick the right tools and apply the correct theory is fundamentally more important than excelling in a particular language? I like Tcl. I enjoy working with it, I'm productive, and the end results work well and reliably. Not everyone agrees with me, but that's ok so long as we can each choose what we like best. What annoys me is when people feel the need to slag off a tool based on personal or out-of-date technical reasons. And don't get me started on Perl syntax:-)
Slashdot Mirror
Could you expand on this? What elements of a CS curriculum do you find irrelevant to software engineering? What elements do you think are missing? There is very little I learned in my CS degree that I have found to be useless, even if it wasn't immediately obvious how to apply it.
We got over it. While natural selection explains the existance of species such as our own, this doesn't mean it's a value we should hold dear. Survival of the fittest is a cruel doctrine, and one which we should be glad to avoid (or lessen the impact of).
Calling someone a "second rate" human implies some sort of universal criteria to judge them. I don't think such a criteria exists. You can call someone a second-rate guitarist (I am!), but a second-rate human is quite another thing. Are disabled people "second rate"? No.
Does this web-spreadsheet store the information on Google's servers, or is it a client-side application that happens to run in a browser? I don't use spreadsheets very often, but every time I do they usually contain sensitive information (financial data, students' exam marks etc), so letting that data sit on Google's servers would be pretty irresponsible. I'd also be worried about violating data protection legislation in some cases.
Yes, of course people are thinking about this. Philosophers, cognitive scientists and AI researchers all frequently discuss such subjects. But why would turning an "intelligent" computer off cause an outcry? A truly intelligent agent will likely need a substantial amount of memory. This suggests to me that it will involve a persistent disk-based store. So turning off such an agent wouldn't "kill" it; it'd be much more akin to going to sleep (especially if you used this downtime to perform maintenance and hardware upgrades). Simply turn it back on. You'd have to actually wipe or physically destroy the disks in order to "kill" the agent. In addition, the computational power required will probably mean that the agent is simulated on a cluster of machines, rather than any one machine. Thus turning off any one machine may lead to a performance degredation or loss of specific abilities (much like a stroke), but would be temporary rather than permanent.
Comparing that to the description of DHTML itself at w3schools:
DHTML also seems to involve a fair amount of DOM. So what is new about AJAX? Is it just the addition of XMLHttpRequest? And... didn't Microsoft invent that?
Yup, we're all barred...
It's valid Java. You can specify a finally block with no catch blocks. A finally block will always be run, even if an exception is thrown (the exception will still propagate). For example, I sometimes mark undergraduate concurrency coursework/exams written in Java. try-finally blocks are used there to ensure correct lock management:
Lots of C-coders use goto in this situation where you want to exit a function early but need to do some cleanup first. It's often considered an acceptable exception to the no-goto rule, as the alternative is usually even more unreadable. Think of it as a work-around for the lack of a try-catch-finally construct. e.g., where in Java you might use:
In C, you'd do:
That way, all code goes through the same exit point and the same cleanup code. Not ideal, but then neither is C.
For that matter, what kind of dirty skank steals bins anyway? Not got enough rubbish of their own? Bloody students.
This "analog AI research" sounds quite like Braitenberg's "Vehicles". It's interesting stuff, demonstrating that it's much easier to create something that exhibits complex behaviour, than it is to work out how something works by observing its behaviour (complex behaviour may be the result of a complex environment).
Is this a joke? Are you seriously trying to suggest that these are in the same league? Frankly, I find these sorts of thoughtless comparisons rather offensive. People died fighting for civil rights.
Besides, why is it more "fair" to be able to play the same game on any media on any device, while only buying one copy? I can see that it's cheaper, and more convenient, but I'm really not seeing the "fair" here. You bought a game for a specific device, and it plays (presumably) on that specific device. I agree that it would be "better", but I don't think it would be more fair.
The web is made from paper?
JPanel jp = new JPanel();
JComponent jc = jp;
works just fine (just tested in 1.4.1). I imagine the same applies to the second one too. Also, if this wasn't the case generics wouldn't help in this code. Generics only remove the need to cast when extracting an object from a container, if I understand things correctly.
In some ways, yes. It's not a perfect solution. Note that you can still use shared libraries in a starkit. There is the problem of how to allow other programs to access useful shared functionality in a starkit. This is possible too, as starkits can be sourced into a VFS-enabled Tcl interpreter (ActiveTcl and TclKit support this).
Starkits aren't a silver bullet, but I think they go a long long way to useful cross-platform deployment with the end-user in mind. Plus, as a bonus, your application gets access to the Metakit embedded database library, which is very useful for storing configuration and application data.
There are more problems to solve, but this is a big step in the right direction, and it works extremely well. A good example of this is the Tcl'ers Wiki. The Wikit starkit contains all the code to run the wiki, and will run as CGI or a standalone Tk application. You can configure it to store all the pages in the starkit, so mirroring is a case of simply copying the file. As all the pages are stored in a Metakit datafile you get efficient searching and retrieval for free. The resulting starkit can be included in another starkit or application without change, for instance to provide a help system.
There are many many more reasons why starkits are cool. It would be nice to see the concept catch on in other languages (starkits are taking the Tcl community by storm, and ActiveState support them in the new TclDevKit releases).
I think more people should take a look at tclkit (http://www.equi4.com/tclkit) and the concept of starkits (http://www.equi4.com/starkit). This is a great concept where an application is delivered as one self-contained file (compressed, with an internal virtual file-system). This gets rid of the problem of "installation" all together.
Very cool stuff.
OK - let's take these points in order.
Firstly you comment on lack of good libraries (perhaps missing Expect and Tk as obvious counter-arguments). There are plenty of libraries for Tcl of very good quality, as a quick trawl of the Tcl'ers Wiki, the Tcl FAQ or the Tcl developer exchange would show you.
Next, you move on to not supporting various programming paradigms. I'm completely lost by this statement. Tcl supports procedural, functional, OO etc styles quite easily. One of Tcl's key advantages is that it is easily adaptable to new paradigms. The fact that Tcl only contains the basic constructs for procedural programming in the core command set maybe where you are getting this from. A bit more in-depth look would show you that Tcl easily allows you to build on these to create whatever language/programming environment fits your problem. It's a very powerful technique.
Life outside the ivory tower seems to use Tcl quite a bit, if you look at places like IBM, AOL and NASA. Tcl is used in misson-critical applications which have run 24/7 for years.
As for syntax, Tcl has used the minimum set to do the job well. If you don't like using whitespace to delimit function parameters, you can define your own function construct which takes parameters separated by commas, or whatever. That's the beauty of Tcl - if you don't like it, you can change it *from within Tcl!* See wiki pages on Radical Language Modification and others for more details.
On top of all this, Tcl has great i18n and asynchronous I/O which most other languages still don't come anywhere near (especially on Windows). Threading is getting very robust. Virtual filesystem support, which enables technology like starkits, is also very cool. Tcl still has a lot to recommend it.
There is no copy-protection on the game, but people with CD keys can download extra stuff.
Is the extra stuff copy-protected, then? Otherwise, when someone decides to put this extra stuff on Kazaa or somewhere, then it's all going to fall apart, surely?
Am I missing something?
Actually, if you read the blurb at the bottom, the article is based on the original English transcription of the interview, which was later converted to German for the magazine. /. a long time ago.
It is old though. I'm sure I've seen this on
As a reasonably active member of the Tcl community, I can say that there are plenty of people using Tcl out there. The wiki grows at a tremendous rate and the newsgroup is very active. Also, NBC are not the only people using Tcl commercially - for instance AOL use it in AOLServer (as was mentioned in the round-up) and IBM use Jacl (the Java implementation of Tcl) for automating WebSphere. :-)
Learning a language because it looks good on your CV/Resume is perhaps not the best engineering practice, but I admit it probably gets jobs. However, surely being able to pick the right tools and apply the correct theory is fundamentally more important than excelling in a particular language?
I like Tcl. I enjoy working with it, I'm productive, and the end results work well and reliably. Not everyone agrees with me, but that's ok so long as we can each choose what we like best. What annoys me is when people feel the need to slag off a tool based on personal or out-of-date technical reasons.
And don't get me started on Perl syntax