Hey, go back and brush up on your History of Linux. Linus specifically argued the whys and hows of microkernels with Tannenbaum, (here) and he's repeated in various interviews (like this one with Yamagata) his reasons for not going with a microkernel.
Ugh. I hope not too much convergence until industrial designers solve some usability problems first. I've tried various small devices and found many of them to be frustratingly modal. One example -- a new camera that had 4 buttons arranged in a circle which did different things depending on what the setting of the camera was -- a setting that was controlled by another button on a different part of the camera -- and there was no way to tell without looking closely (and taking your attention away from trying to get the picture) which mode you were in. It was a nightmare of everything you could do wrong in design.
OK, from the standpoint of having done Java, C++, and COM, (and sorry to say, a bit of VB) here's what C# is trying to be:
It's C++ minus some of the messiest parts of the syntax. Think ATL.
It's VB plus some bits of Java and C++ to give the language more power. Except MSFT to push it to try to stem the tide of VB programmers rushing to Java.
It's a new COM language -- built on and married with COM. Except that COM is going away in favor of.NET. Except that.NET is really COM. Well I dunno what's going on here.
It's Java plus pointers and some other C/C++ language "features" that certain ossified programmers can't seem to learn how to do without.
It's another MSFT product to get you to buy something to replace all that product that you've sweated bullets to make halfway-functional but isn't making MSFT any money anymore.
At the end of the article the C# product manager slams Java and tries to smack write-once/run-anywhere by quoting an interview with Gosling as supposedly saying it is nothing but a bunch of marketing hype. There's a link to that interview, and if you read it, he really says that there are limitations on certain platforms (embedded devices, e.g.) but that overall his point is "Java is -- a glue layer that tries to make "write once, run everywhere" as close to true as it can be"
Just like it's impossible to completely reverse engineer.DOC, it's going to be impossible to clone winDOS. Certain 'features' of winDOS are just NoGo code that solified into the morass. Unlike Linux, which can be POSIX-compliant and therefore has a particular behavior goal, winDOS is just whatever MS says it is.
60% of all new software is written in Visual Basic
That's quite a claim. References? By what measure? Lines of code? Useless. Number of projects started? Please. Function points? What? Back up this claim or let VB molder in the grave it deserves.
Given that C# is currently nothing but a specification, and an incomplete one at that, what is it that you are converting? The syntax? That's trivial, but for a couple of things that wouldn't map well, like unsafe and pointer arithmetic. But given that the language is going to be wedded to COM for all its functionality, you'd have to go a long long way to generate Java to do all that. If a C# program calls an Excel automation interface, what are you going do? (Well, I know a pointer to a beginning of a solution -- use the JIntegra Java-COM bridge, but that's just a pointer).
BTW I totally 2nd the poster who comments on how C# is not search-engine compliant. I presume the alternates of C-sharp and Csharp would become the preferred variants for searchable text, but really. I think I'll invent a language and call it/.:+!
I really want to stress two points. One is that while charitable organizations certainly have a need for computer skills, the kinds of needs most deeply felt are food, shelter, and clothing, and meeting those needs isn't the job for a computer whiz doing computer stuff. Which leads me to my second point. Get a job that pays you according to the market, and your needs, in an organization that doesn't make you feel like you're compromising your deep values. Volunteer your time to an organization that needs help -- doing whatever they need done, computer or not -- and then, and this is most important, give at least 10% of your income directly to the organization of your choice. Some organizations, like my favorite, Portland's Sisters of the Road Cafe, can even set up an automatic withdrawal monthly. Now your incentives to raise your income also benefit others. But please, don't stop at just sending money -- contribute your human touch as well.
''Java tends to be slow, and usually not such a great thing for realtime involving a lot of data.''
Hahahaha. To paraphrase a former VP candidate: "I know Java, and you're no Java guru". Puhleeze. If I hear "slow" and Java in the same sentence one more time I'm gonna puke. If you'd been paying attention (and like me, attended JavaOne 2000) you'd know how wrong you are. Heck, as I type this I'm running a Java video capture program. But thanks for playing.
Everyone will (and has already) compared this language to Java. This is fine. However, it is clear that C# (Coctothorpe) is C++ with some significant changes to make it look as much like Java as possible while retaining pretty much everything in COM-flavored C/C++. Think about it -- you could build front-end parser that would take C# and translate it quite easily to C++, throw in automatic reference-counting implemented ala COM, translate the library calls to calls into the appropriate ActiveX/COM components and you're good to go.
What is clear to me from looking pretty closely at the reference doc is that it has everything C/C++ has (operator overloading, pointers) but doesn't much from Java except some syntactic ideas and mutexes. But it's meant to be compiled to native code and rely on native libraries.
It doesn't really look much like a new programming language, just decorated C++ for COM.
I learned so much about the current state and future of the Java language and platform at JavaOne I can now spot those who speak from ignorance in 7 words or less.
Well see, AOL/Time Warner, MS and the link won't have to pay money. They'll just sign a "cross licensing" agreement. In other words, they'll throw a few tasty patents at BT for them to use at no charge in exchange for using the hyperlink patent.
So no, they won't lobby the government to change this, because, as you may conclude, a patent like this only has the effect of keeping out the little guys, who don't have patents to cross license or money to pay BT. This means less competition for the big guys, which means more money for them. Everybody worth a billion dollars or more wins.
Rich GUI front end. Java. Database backend. Java (in spades -- it's very good for this). RAD. Java, Pick any of a half dozen. Platform independence. Java. Your rfp didn't mention any other requirements, why look at any other options?
A while back a couple sailed around the world and recorded their trip through the Houston Chronicle newspaper's web site. All the stuff is still up at the At Sea site and if you take a look at the FAQ I think you'll see they sent and recieved e-mail via Inmarsat-C satellite transmission. BTW I coded up the mapping from open-source tools -- gnuplot and perl:)
Excuse me? Your web site design sucks because the browsers are broken and you design for that fantasy world where they all support the standards as you see them? Boy how far can we take this? I'll just leave it with "typical attitude of a wanna-be deadtrees graphic designer who can only envision web pages as looking exactly the way he wants them to look. Since when is "liquid" design something new that you have to design special for? Slashdot gets it -- the pages look fine on everything from lynx to 1600x1400. Oh right -- they don't look "good" according to your design preferences. You say "Separation of style and content is the way forward" but really you don't know what that means oh and by the way you don't really mean that because "The problem is the browsers."
Bzzzzt. Thank you for playing.
I hope the day never comes when web design standards are driven by print-media mindset designers whose egos are too big to imagine their work in a different monitor/pixel resolution/font/color combo than their Mac's G4 19" screen. Don't worry though, I'm sure you could get a job designing pages for WebTV.
Even Java, Python, Eiffel and Ruby (which, btw, was the precursor to VB) are susceptible to reference leaks of this sort. The mark & sweep method isn't the be-all end-all of GC. How often do you create an object, hand a reference to it to an object of another class not of your creation (a GUI class, e.g.) and then your reference goes out of scope. Later, you may be completely done with the object but it can't be GC'd because some other object still has a now-useless reference to it. Read the book, btw, Perl's GC is a little bit better than Java's (the default GC, not the GC in Hotspot).
And just because you can't call the constructor of more than one superclass (actually you can, if you know the right tricks), that doesn't make it non-MI. In Java interfaces only define, well, interfaces, which you must implement. In Perl you can define a class, say, Platypus, and inherit from, say Mammal and Reptile and you will get real, callable methods, say, hasFur() and layEgg(). In Java if you have implement Mammal and Reptile you have to write your own hasFur() and layEgg() methods.
But then, I don't like MI. Try creating a class Osprey and inheriting from Airplane and Helicopter and then calling fly(). My real-world experience with MI in Perl jumped up and bit me, and we re-designed and took the MI out.
No, in fact this book is quite lite on OO as a programming method. You have your basic PIE, but beyond that you need another text. BTW, you should use the 'Preview' button on your post next time.
Does it? Ever considered blessing a regex? Bet you didn't know that would work! How about writing an extensible double-dispatch handler? Object serialization? Hell yeh it covers a lot more than perltoot!
Well, mebbe not. I am waiting to hear more comments from non-English slashdotters on this subject, the comments so far reflect a definite world view -- the English world.
There is an opportunity (or was, some vendors have missed it) when converting an O/S from 32-bit to 64-bit to also build in support for Unicode. Let's face it, current multi-byte encoding schemes (1, 2, or 3 bytes per character, varying) are a pain, but Unicode is a breeze to use. Try writing some internationalized Java if you don't believe me.
Ah, but you could instead put them both under (to extend your example) org.perl.xml (or org.java or whatever) and solve that problem. That simply entails changing a few lines around. Of course in Perl, XML::Writer and XML::Path don't share any data -- visibilty in package namespaces doesn't work that way, so they can't share data just by virtue of having the same first element in their package name.
Having said that, this reduces the issue down to the simple matter of users knowing that two perl modules are related because they have similar names, while two java classes in the org.java.xml package do have shared visibility.
The problem may come to when something goes kablooie (even unrelated to the open source software) and the headhunters come flocking to put someone on the chopping block. If the software was from a large, dominant provider, the boss and anyone else who ought to be taking responsibility can just shrug and say 'Oh well, buggy as usual' and go on. If there's a "new" and "untried" thing sitting around it's an instant magnet for finger pointers. So a manager who's more worried about his job & perqs will either outlaw open source or go for the 'plausible deniability' solution by not looking too closely.
Ultimately, if you're working in a culture where blame and firings are the way problems are addressed, then you take your fine resume' and your marketable skillset and go on to the next job. You do have that, right, because you're smart enough to choose the right solution instead of the safe one.
Your question boils down to Which languages go best with which tasks? That's an excellent place to focus.
If you are doing classing CGI, you first task with every request serviced will be to get the query params and the host environment. Look for a language that provides good facilities for that. Perl's CGI.pm is a good example, Here's how simple it is:
I'm sure fans of other languages can come up with similar languages.
Most, if not all, CGI handling will involve some text manipulation. There are few arguments that Perl is king of that domain.
Will you be doing any database accesses or otherwise responding to the request with persistent data? Look for a language that supports some kind of useful DB interface.
Do you need to maintain session state? You'll need a language that provides facilities for easy cookie handling or URL mangling.
The only language I know that meets all these criteria for straight CGI is Perl. If you are willing and able to go to the next step beyond CGI, look at Java servlets and JSP.
Slashdot Mirror
Hey, go back and brush up on your History of Linux. Linus specifically argued the whys and hows of microkernels with Tannenbaum, (here) and he's repeated in various interviews (like this one with Yamagata) his reasons for not going with a microkernel.
Ugh. I hope not too much convergence until industrial designers solve some usability problems first. I've tried various small devices and found many of them to be frustratingly modal. One example -- a new camera that had 4 buttons arranged in a circle which did different things depending on what the setting of the camera was -- a setting that was controlled by another button on a different part of the camera -- and there was no way to tell without looking closely (and taking your attention away from trying to get the picture) which mode you were in. It was a nightmare of everything you could do wrong in design.
OK, from the standpoint of having done Java, C++, and COM, (and sorry to say, a bit of VB) here's what C# is trying to be:
.NET. Except that .NET is really COM. Well I dunno what's going on here.
It's C++ minus some of the messiest parts of the syntax. Think ATL.
It's VB plus some bits of Java and C++ to give the language more power. Except MSFT to push it to try to stem the tide of VB programmers rushing to Java.
It's a new COM language -- built on and married with COM. Except that COM is going away in favor of
It's Java plus pointers and some other C/C++ language "features" that certain ossified programmers can't seem to learn how to do without.
It's another MSFT product to get you to buy something to replace all that product that you've sweated bullets to make halfway-functional but isn't making MSFT any money anymore.
At the end of the article the C# product manager slams Java and tries to smack write-once/run-anywhere by quoting an interview with Gosling as supposedly saying it is nothing but a bunch of marketing hype. There's a link to that interview, and if you read it, he really says that there are limitations on certain platforms (embedded devices, e.g.) but that overall his point is "Java is -- a glue layer that tries to make "write once, run everywhere" as close to true as it can be"
"What do you do if your productivity drops to two lines of code a day...?"
I stop measuring my productivity in 70s-era LOC metrics.
Just like it's impossible to completely reverse engineer .DOC, it's going to be impossible to clone winDOS. Certain 'features' of winDOS are just NoGo code that solified into the morass. Unlike Linux, which can be POSIX-compliant and therefore has a particular behavior goal, winDOS is just whatever MS says it is.
Given that C# is currently nothing but a specification, and an incomplete one at that, what is it that you are converting? The syntax? That's trivial, but for a couple of things that wouldn't map well, like unsafe and pointer arithmetic. But given that the language is going to be wedded to COM for all its functionality, you'd have to go a long long way to generate Java to do all that. If a C# program calls an Excel automation interface, what are you going do? (Well, I know a pointer to a beginning of a solution -- use the JIntegra Java-COM bridge, but that's just a pointer).
/.:+!
BTW I totally 2nd the poster who comments on how C# is not search-engine compliant. I presume the alternates of C-sharp and Csharp would become the preferred variants for searchable text, but really. I think I'll invent a language and call it
I really want to stress two points. One is that while charitable organizations certainly have a need for computer skills, the kinds of needs most deeply felt are food, shelter, and clothing, and meeting those needs isn't the job for a computer whiz doing computer stuff. Which leads me to my second point. Get a job that pays you according to the market, and your needs, in an organization that doesn't make you feel like you're compromising your deep values. Volunteer your time to an organization that needs help -- doing whatever they need done, computer or not -- and then, and this is most important, give at least 10% of your income directly to the organization of your choice. Some organizations, like my favorite, Portland's Sisters of the Road Cafe, can even set up an automatic withdrawal monthly. Now your incentives to raise your income also benefit others. But please, don't stop at just sending money -- contribute your human touch as well.
''Java tends to be slow, and usually not such a great thing for realtime involving a lot of data.''
Hahahaha. To paraphrase a former VP candidate: "I know Java, and you're no Java guru". Puhleeze. If I hear "slow" and Java in the same sentence one more time I'm gonna puke. If you'd been paying attention (and like me, attended JavaOne 2000) you'd know how wrong you are. Heck, as I type this I'm running a Java video capture program. But thanks for playing.
Everyone will (and has already) compared this language to Java. This is fine. However, it is clear that C# (Coctothorpe) is C++ with some significant changes to make it look as much like Java as possible while retaining pretty much everything in COM-flavored C/C++. Think about it -- you could build front-end parser that would take C# and translate it quite easily to C++, throw in automatic reference-counting implemented ala COM, translate the library calls to calls into the appropriate ActiveX/COM components and you're good to go.
What is clear to me from looking pretty closely at the reference doc is that it has everything C/C++ has (operator overloading, pointers) but doesn't much from Java except some syntactic ideas and mutexes. But it's meant to be compiled to native code and rely on native libraries.
It doesn't really look much like a new programming language, just decorated C++ for COM.
I like developing on Linux and Unix (tm) in general because the following program will *NOT* result in a system crash:
int main() {
int *p;
int i;
p = rand();
i = *p;
}
A segfault, yes, but in winDOS you're as likely to lock up the whole system as anything.
I learned so much about the current state and future of the Java language and platform at JavaOne I can now spot those who speak from ignorance in 7 words or less.
Well see, AOL/Time Warner, MS and the link won't have to pay money. They'll just sign a "cross licensing" agreement. In other words, they'll throw a few tasty patents at BT for them to use at no charge in exchange for using the hyperlink patent.
So no, they won't lobby the government to change this, because, as you may conclude, a patent like this only has the effect of keeping out the little guys, who don't have patents to cross license or money to pay BT. This means less competition for the big guys, which means more money for them. Everybody worth a billion dollars or more wins.
Rich GUI front end. Java. Database backend. Java (in spades -- it's very good for this). RAD. Java, Pick any of a half dozen. Platform independence. Java. Your rfp didn't mention any other requirements, why look at any other options?
A while back a couple sailed around the world and recorded their trip through the Houston Chronicle newspaper's web site. All the stuff is still up at the At Sea site and if you take a look at the FAQ I think you'll see they sent and recieved e-mail via Inmarsat-C satellite transmission. BTW I coded up the mapping from open-source tools -- gnuplot and perl :)
Bzzzzt. Thank you for playing.
I hope the day never comes when web design standards are driven by print-media mindset designers whose egos are too big to imagine their work in a different monitor/pixel resolution/font/color combo than their Mac's G4 19" screen. Don't worry though, I'm sure you could get a job designing pages for WebTV.
And just because you can't call the constructor of more than one superclass (actually you can, if you know the right tricks), that doesn't make it non-MI. In Java interfaces only define, well, interfaces, which you must implement. In Perl you can define a class, say, Platypus, and inherit from, say Mammal and Reptile and you will get real, callable methods, say, hasFur() and layEgg(). In Java if you have implement Mammal and Reptile you have to write your own hasFur() and layEgg() methods.
But then, I don't like MI. Try creating a class Osprey and inheriting from Airplane and Helicopter and then calling fly(). My real-world experience with MI in Perl jumped up and bit me, and we re-designed and took the MI out.
No, in fact this book is quite lite on OO as a programming method. You have your basic PIE, but beyond that you need another text. BTW, you should use the 'Preview' button on your post next time.
Does it? Ever considered blessing a regex? Bet you didn't know that would work! How about writing an extensible double-dispatch handler? Object serialization? Hell yeh it covers a lot more than perltoot!
At least Perl (unlike VB) supports inheritance (even multiple, if you're a masochist) and unlike C++, Perl manages memory for you -- no memory leaks.
There is an opportunity (or was, some vendors have missed it) when converting an O/S from 32-bit to 64-bit to also build in support for Unicode. Let's face it, current multi-byte encoding schemes (1, 2, or 3 bytes per character, varying) are a pain, but Unicode is a breeze to use. Try writing some internationalized Java if you don't believe me.
Having said that, this reduces the issue down to the simple matter of users knowing that two perl modules are related because they have similar names, while two java classes in the org.java.xml package do have shared visibility.
On the constructive side, take a look at JFA Projects and The Open Source Java Web Ring
The problem may come to when something goes kablooie (even unrelated to the open source software) and the headhunters come flocking to put someone on the chopping block. If the software was from a large, dominant provider, the boss and anyone else who ought to be taking responsibility can just shrug and say 'Oh well, buggy as usual' and go on. If there's a "new" and "untried" thing sitting around it's an instant magnet for finger pointers. So a manager who's more worried about his job & perqs will either outlaw open source or go for the 'plausible deniability' solution by not looking too closely.
Ultimately, if you're working in a culture where blame and firings are the way problems are addressed, then you take your fine resume' and your marketable skillset and go on to the next job. You do have that, right, because you're smart enough to choose the right solution instead of the safe one.
If you are doing classing CGI, you first task with every request serviced will be to get the query params and the host environment. Look for a language that provides good facilities for that. Perl's CGI.pm is a good example, Here's how simple it is:
use CGI.pm
$q = new CGI;
@querykeys = $q->param();
foreach $key (@querykeys) {
print $q->param($key);
}
I'm sure fans of other languages can come up with similar languages.
Most, if not all, CGI handling will involve some text manipulation. There are few arguments that Perl is king of that domain.
Will you be doing any database accesses or otherwise responding to the request with persistent data? Look for a language that supports some kind of useful DB interface.
Do you need to maintain session state? You'll need a language that provides facilities for easy cookie handling or URL mangling.
The only language I know that meets all these criteria for straight CGI is Perl. If you are willing and able to go to the next step beyond CGI, look at Java servlets and JSP.