Protium-XML will be immediately familiar to persons conversant with XML (or to a lesser degree, HTML).
Huh? This is like saying that LISP is "immediately familiar to persons who use parantheses." Bollocks. Do you know anything about XML or do you just like acronyms that start with "X"? They are cool, aren't they...
As an XML dialect, all valid HTML is therefore valid Protium-XML.
...except that HTML is not valid XML. XHTML is valid XML. The "do you actually know anything about XML" question springs to mind again.
Perl, Coldfusion, Java Servlets, PHP and Microsoft Active Server Pages,... none of these offer the speed,... of... Protium-XML...
Protium-XML runs as a CGI-bin application on a webserver.
Do you know anything about web servers? Do you realize that you're re-inventing JSP with taglibs? Except with really crappy performance?
Fuck, why am I bothering? I can barely read your fucked up web pages on Linux Netscape. You don't even know HTML, you freak losers. So, to answer your conditional, you are not crazy; you are butt stupid. Sorry, but that's just the way it is.
I admit to some confusion regarding XSL and XSLT. I don't feel a lot of incentive to clear up that confusion, personally, and a couple posters have been kind enough to offer some clarifying details.
For people dealing with very large and varied sets of XML formats... it is infinitely more maintainable to have the conversions... written out as a set of XSL sheets instead of... one rat's nest of perl script after another.
Well, as a Java bigot, I am dedicated to eliminating Perl rats' nests wherever possible! In fact, I'd agree with your statement 100% if I'd ever had to deal with XML documents. I don't have to deal with XML documents and I've never seen anyone who did (with the exception of certain specific publishing applications).
My data is always in the form of some kind of Java object or collection of Java objects. I suppose that if I were a Perl programmer, I'd have some Perl arrays, hashes or object containing my data instead.
An XML document in a file or a memory buffer does me almost no good whatsoever, so the closest I'll ever have to an XML document is the JDOM tree resulting from parsing the source document. This JDOM tree is, of course... you guessed it... a collection of Java objects. Again, if I were a Perl programmer, I could use Perl's powerful text munging to stay closer to the original XML, but I'd still end up parsing stuff out of it.
Seeing as how my data is not in XML documents, but in Java objects, I have a variety of standard, non-confusing, error-free and flexible ways of turning it into HTML, WML, PDF, TeX, MIF or some kind of XML. WebMacro is a personal favorite.
XML is a useful data description and interchange mechanism, but things got way out of hand before people finally figured out what they really wanted to do with it. During this time, I saw several systems that operated on data by passing it around as XML documents. This might make sense in a server-to-server context, but within an application, it represents a fuckload of unecessary parsing and reconstituting of XML documents. If I already have the data in a format that is convenient and accessable to my programming language of choice, why the hell would I turn it into an XML document, unless I was exporting it to some "black box" on the end of a socket connection? Because it's trendy?! No thanks!
XSL and XSLT are predicated on the idea that my data will be in the form of an XML document while I'm working on it. In practice, it turns out that this is extra effort. If I find myself in the position of being given existing XML documents that need only to be converted to another kind of document, I'll revisit XSL, but I tend to work on more dynamic data than that.
...pre-emptively submit the death of iCopyright.com to FuckedCompany. $1.6M in funding? 66 employees? I give them until 3Q2001... maybe 1Q2002, if they're frugal.
If you can't cost-justify giving free access to your website, then there are ways to make people pay for access.
The dot-com graveyard is full of companies that couldn't really afford to do what they were doing for free, but couldn't get people to pay. That's just tough. Would you pay for access to Slashdot? If not, prepare for it to go away (unless its ad revenue sustains it). We'd all miss it, but it wouldn't be our fault that Cmdr. Taco et al gave away free access to it. That was their choice, their plan and we were happy to soak up their precious resources while they lasted.
When you put up a link, it's as if you are including part of their web site in yours.
No, it's not "as if you are including part of their web site in yours." It's not including anything on their website unless you actually copy part of their website to add context to the link. This copying may already be permissable under "Fair Use" provisions in US copyright law, as well.
Putting up a publically-accessable web page is like leaving an infinite supply of leaflets in a stack somewhere. You may make money by putting ads on the leaflets. If I tell someone "hey, there's a leaflet about Foo and you can find it in a pile on the corner of Bar Lane and Baz Avenue," I owe you nothing. In fact, if you gain revenue by distributing leaflets, I've done you a favor.
If the leaflets are for "paying customers only" it's your job to make those customers pay -- not mine.
I didn't read the white paper, but what you describe sounds [like] the ResizeTool object we use in our own product...
Now that my post has gotten a couple of responses, I realize that by the end of the day, there will probably be two dozen examples of things that this is "like". Yeah, it's kind of like your ResizeTool and it's also reminiscent of the Decorator Pattern as the other poster pointed out.
Fine. Maybe I'm insane and DML is the pinnacle of OOP. Go ahead and embrace it... love it... touch it! Lieben Sie das DML! Now is the the time on Slashdot when we dance!
What if the client wants to get the data displayed in a format they can control?... I think the concept of getting raw data from the server and being able to present it client-specifically is an awesome idea.
Yeah, but that's not the concept behind XML/XSL. It is, to some extent, the concept behind XML; the server delivers raw data for whatever purposes the client needs it. However, if I attach an XSL or XSLT document, then I'm telling you how I want it displayed. The issue is "where is the presentation layer"? If I deliver you HTML, that question has been determined: I'm at the presentation stage. If I deliver you some kind of XML, then I have no idea how (or if) the data is to be presented to a human.
Your point is quite valid, but the issue of how data is delivered and presented is artificial. It was created by people who forgot that not all clients are web browsers and not all transports are HTTP. (Actually, they probably never knew, because they got out of school in 1996 and went to work at Microsoft.) "Web" designers who use a Model-View-Controller design don't have any problem delivering an "XML version" of their data, where appropriate. The XML+XSL was a clumsy one-size-fits all approach. "It's for browser! It's for middle tiers!" Oh I see... I'm a server and I don't know what I'm serving to or why, I just spray whatever data you want into any socket connection that comes my way. That works great until you start serving data that has some value (like account information or a telnet session or email for a particular recipient). Then the server has to be a little more careful about what data is sends and what it is willing to do on behalf of the client.
Actually, this is a really cool design pattern called Decorator. Read up on it, it's actually a useful idea for some applications.
No it isn't. Adding a resize object to a widget in order to make it resizable is not a Decorator pattern. A proper use of the Decorator patter would be to create a DecoratedWidget base class that contained a reference ordinary Widget. The DecoratedWidget would pass through ordinary Widget methods and subclasses of DecoratedWidget could add "one-off" methods such as resize() without creating zillions of subclasses of Widget.
This design pattern is heavily used in Java, particularly when doing a lot of AWT (GUI) programming (something I avoid, but I've done enough of it...). Decorators are particularly useful when your language doesn't support multiple inheritance (like Java). Java, in particular, supports a mechanism called an "interface" which is like a pure virtual object. You can "implent" as many interfaces as you'd like, but you have to provide method implementations for all of each interface's methods. Often, for an inteface "Foo", there will be a class called "SimpleFoo" that you can use in a Decorator pattern to provide the base functionality for implementations of Foo. Read up on it.
I was suffering from insomnia, so I read the DML whitepaper. Now I'm suffering from nausea as well.
Have you ever seen one of those situations where someone takes a smattering of technical knowledge and industriously recreates something that already exists... but does it badly? (If you haven't seen this, Microsoft has a whole catalog of products to illustrate this point.)
There is so much cluelessness on the Athena OS site, it's really hard to figure out where to start, but getting down to the core technology: DML is stupid. DML is the "Object Oriented GUI language in XML." Buzzword compliant? You bet? Useful? Not!
XML is a rotten format for programming languages. Anyone who's worked with XSLT knows what I mean. XSLT (related to XSL) is, essentially, a programming language that converts XML documents into other XML documents and XSLT itself is (drum roll please) an XML document. Why? 'Cause XML documents are sooooo late 90's -- and in the late 90's, you could sell shit-on-a-stick if it was XML-compliant. If you've ever seen an XSLT program/document that did anything vaguely complex, you immediately think, "Fuck! I could do this in 10 lines of..." Perl? PHP? Java? Visual Basic? All of the above! There is no language that is not preferable to XSLT.
The idea that spawed XSL/XSLT was that in "the future", browsers wouldn't download HTML, they'd download XML documents, and an associated XSL document would turn it into something displayable on the client side. God forbid a Perl, Java, PHP, or ASP program on the server do this for you -- no, let's make the thin client fat again, by giving it the responsibility of not only rendering, but organizing the data. Proof positive that this was a dumb idea what that Internet Explorer 5.0 proudly featured a robust implementation of this idiocy.
So, already, we have the case that anyone who isn't laboring under the deficits inflicted by a head injury has figured out that you really don't want to force any kind of programming language to look like a valid XML document. So what is the big deal with "Athena OS"? Oh, it's a programming language that is XML-compliant. How clever.
This "XML-compliant" programming language causes you to do really weird things architecturally. If you read the whitepaper, you will see an example where they make a widget resizable by attaching "resize" objects to it. "resize" is an object?! Diagram that, UML-mongers!
Piled on top of basic Bad Technology(tm), are numerous statements that indicate that these guys have never looked at any other system. Their claims about the flexibility of their design are laughable to anyone who has seen Motif widget management or Java AWT LayoutManagers (GridBagLayout is a bear, but it's incredibly powerful). Seriously, they try to sound like they've invented a better mousetrap, but you start to wonder if they've ever seen a real mouse. Like, where did they get this gem:
XML and HTML standards are defined by their respective organisations and have no direct association with Rocklyte Systems or the DML standard.
It's like they don't even know where HTML and XML come from... but whereever they're from, it's not Rocklyte Systems and we want to remind you of that. This is just laugh-out-loud funny.
Object Oriented! Well-documented core APIs available on all platforms! Runtime loading of objects! Closed source to "protect its integrity"! It's... it's...
...I do not want to see issues such as this decided by the government. I would like to see these issues decided by the common sense of the masses.
This is a great idea!
Unfortunately, we need a way to distill and enforce this common sense. Sure, "market forces" seem like a tempting answer, but market forces only reflect the common sense of the market, not the commoen sense of the masses. As others have pointed out, a killer-for-hire service may be supported by the marketplace, but is obviously against the "common sense of the masses."
Maybe we could elect representatives who would be answerable to various segments of the population. These representatives could be granted enforcement powers -- powers they hold only as long as they stay in office, something they can only do by faithfully representing the "will" of their segment.
We could call it "Democracy."
Actually, on second thought, it wouldn't work. It would require the constant participation of the population, obviously too much to ask. Instead, the "masses" will call for some kind of new system that promotes their interests but doesn't require any effort from them whatsoever. They'll get what they deserve, at that point.
According to some corporate cultures, a person who is not progressing in "rank" is seen as stagnant, and therefore a loser. This is actually codified in the military (at least the US military) and is prevalent in professional services firms where you can make partner. (Law firms, accounting firms, "consulting" firms like McKinsey and BCG).
If you don't promote someone to a more leveraged position, it's difficult to cost-justify paying them more each year. In theory, a management position allows you to leverage your expertise by helping less-senior people do the job your doing now. Economic factors may cause your position to become more valuable, but barring those externalities, your intrinsic value to the company isn't changing if you don't move up. You need to be prepared to get a small or zero raise if you stay in one role.
That said, consulting/account firm PricewaterhouseCooopers, a venerable practitioner of "up or out," did a study a couple of years ago and figured out that it cost them $50K, on average, to punt a perfectly good employee just because he or she didn't fit the next higher promotion level. This issue is particularly accute in these kinds of companies because as you progress from "Manager" to "Senior Manager", your role changes from "person who does work" to "person who sells work." I'm willing to bet that a lot of people who read Slashdot would cringe at the thought or going from project participant to salesbot. Anyway, PwC is trying to tackle the issue as are other "up or out" organizations, inlcuding the US military.
Anyway, I agree with the posters urging you to tell your company that you don't want a permanent promotion. Point out the cost of filling your job as well as the management position. Give them a deadline or they may "forget" that your position is temporary.
As an aside, although the consulting firms are ultimately geek-unfriendly, they can be great experience for a couple years, particularly starting out.
As many posters have noted, the short answer to this question is "yes" Open Source OS's are viable in the enterprise environment (and more so every day).
There are plenty of stories wherein open source software has quietly proven a success. Quietly? Sure. Home Depot may be on Linux, but IT is not percieved as a fundamental issue for Home Depot's financial success, things like Supply Chain Management (SCM) are. Of course, if their IT infrastructure fails, it will screw up their cutting-edge SCM, but financial analysts rarely drill that far down.
A good example is the rise of DEC. (The fall of DEC is an example of other things:-).
In the mid-80's, insurance giant Aetna bought out a small insurance company -- something they do all the time. In the course of their due diligence, they requested a roster of standard reports. The reports arrive two days later. The Aetna execs were flabbergasted. It took weeks for a team of RPG and COBOL programmers to coax similar reports from Aetna's computers. What kind of computers was this small company using? "We run on DEC machines running UNIX," they answered.
Before you knew it, DEC was the new star in corporate IT. IIRC, 1986 was the Year DEC Could Not Be Stopped. Linux has a lot of good buzz, but it hasn't crossed that perception barrier. What will it take? It will take someone betting on, and winning with, Open Source.
I'm running my ecommerce infrastructure using Linux, Apache, NetBSD, mod_php, Jakarta Tomcat and PostgreSQL. The only closed-source element is the JVM that runs Tomcat and I can replace that with Kaffe eventually. Have I bet my business on Open Source? Not really. I told a Sun and an Oracle rep just last Thursday that if Linux and PostgreSQL begin to break under stress, they could expect a call. I can switch to Solaris and Oracle in a weekend. Even though I have the source code, I have neither the time, the expertise or even the interest in developing Linux and PostgreSQL into a solution that can rival the power and stability of Oracle running on dual E6500's. I will, at the point where I need that, have the money to pay for them. Right now, I'm just one of thousands of businesses that is controlling their startup costs by building their initial infrastructure on Open Source. That's a plus, but it's not the testimonial Wall Street needs to see.
What needs to happen is a success story build on Linux or NetBSD that couldn't have happened using closed-source approaches. I don't know what that's going to be, but I'm sure it's on the horizon. If I do think of it, look for me on the cover of Forbes (I'll see if I can get Linus to stand behind me and grin appreciatively).
Nomadic makes a good point and there are even more historical examples. 13th century Sufi poet Rumi wrote in Persian because it made his work more commercial at the time.
In China, the common language is Mandarin, but there are over 350 other dialects, Cantonese being the second most popular. What's worse is that they're usually mutually unintelligable. People in Hong Kong speak Cantonese, and unless they are well-educated (and sometimes, even if they are), they neither speak nor understand Mandarin. That became a big problem in 1997 when they rejoined the PRC.
Rather than fretting over the "destruction" of dialects, China maintains the supremacy of Mandarin. If they didn't, the country would balkanize and lose its status as a world power really quickly.
When I heard about this, I was pretty surprised. I thought "obfuscated Perl" was redundant. If they want a challenge, how about a "Documented Perl" contest?
In this, the entrants must write a non-trivial application, entirely in Perl, that has to be completely portable across at least 3 implementations (including one on Windows) and at least 25,000 lines of code (not counting comments).
Judges will introduce a bug into each program that would be obvious if you knew what the program did. Each bug *must* involve a cascade from an ambiguous or subtle misuse one of Perl's much-heralded "Do what I mean" functions.
A panel of experienced Perl programmers will be given the programs to debug. The program that takes the least average time to debug wins.
Really? 'Cause he says, in the very next sentence:
Gravity, mass and velocity
These were widely understood before Einstein described objects moving through space curved by mass. Nuclear physics, quantum physics, relativity and special relativity are fairly new (but not even 50-75 years new), but that's not what he's talking about. He's talking about good ol' Newtonian physics. As in Sir Isaac Newton, the 17th century mathematician.
Frequently, in Slashdot flame wars, the participants whip out their incomes like frat boys measuring their dicks.
For example, one programmer bragging about how much Java helps his bottom line was one-up'ed by another AC claiming that Perl programming had netted him "$5 million" a year.
Another good troll is to point out that the dot-com industry has, for the most part, only actually made money by selling equity -- not products or ads. Immediately a bunch of AC's will come out and say "oh, you're just jealous because you didn't make tons of money like we did."
Fine. I guess I'm the only person who reads Slashdot who doesn't have a couple mil' in the bank and a private jet.
Why, then, with geeks supposedly swimming in cash, is the EFF "underfunded"? I suspect that the "swimming in cash" is just part of the delusions of granduer that the geek community has. Sure, some geeks are loaded, but I think that a lot more are sitting on some stock options that have yet to do anything and even more are just pulling in a decent paycheck and want, desperately, to believe that they'll be millionaires someday, too (clue: no one ever became rich selling their time).
OS/2 isn't dead, either. In fact, it's still for sale from a real company, unlike the Amiga.
Also, unlike the Amiga, OS/2 has been mentioned once on Slashdot this year. The Amiga has been a headline seven times and it has it's own fucking category.
Good products fail and fade away. It sucks, but it's true. For every one, there are the core faithful who still use it. Good for them. Slashdot's techno-necrophilia regarding the Amiga is just silly.
Java where it's not even possible to write directly in bytecode (at least not so far as I know
You can.
The next time the code is called, the compiler optimizes that code a little more, and so on, until frequently used code is extremely optimized.... No Java JIT that I know of can do this.
Ummm... it's called "HotSpot" and it's been out about a year.
Do you know anything about anything, or do you just like typing?
I think the ultimate geek diet is The Zone Diet. The diet is based on deep scientific research by a geek who actually when to MIT to study nutrition (MIT closed the "Food and Nutrition Science" department in the mid-80's).
Following the zone diet involves geeky calulations and measuring of things. Your kitchen becomes a lab. Barry Sears encourages people to think of food as a psychoactive drug. How much more geeky can you get?
The Dilberito is too high in carbs, too low in protien and the protien is does have is locked in a fiber matrix, making it hard to absorb. It's weird because in the same "Dilbert Future" paragraph that Adams talks about the then-hypothetical food, he also mentions the Zone. I was disappointed to see that the Dilberito is not "Zone Friendly" particularly because it's so difficult for vegitarians to get the protien requirements needed to adhere to the Zone diet.
Corrinne Yu: [I'm in the 99.9999 percentile. Nothing you say applies to me. Stop it!]
Look, lady, Better Homes and Gardens outsells Penthouse and Playboy combined while Ms. and Working Woman struggle for subscriptions. Women did that. Cosmopolitan sells millions of issues without a single article on programming. Women buy it.
When you get to the fringes of the culture, generalizations cease to apply. Still, there's no point in pretending, that these generalizations are invented. They're not; they are based on observating the mass of people who inhabit the center of the bell curve.
It's obvious that a lot of guys on Slashdot have never actually spoken to a typical American woman. I wonder if you have, either.
Slashdot Mirror
- Protium-XML will be immediately familiar to persons conversant with XML (or to a lesser degree, HTML).
Huh? This is like saying that LISP is "immediately familiar to persons who use parantheses." Bollocks. Do you know anything about XML or do you just like acronyms that start with "X"? They are cool, aren't they...- Perl, Coldfusion, Java Servlets, PHP and Microsoft Active Server Pages,
... none of these offer the speed, ... of ... Protium-XML...
Protium-XML runs as a CGI-bin application on a webserver.
Do you know anything about web servers? Do you realize that you're re-inventing JSP with taglibs? Except with really crappy performance?Fuck, why am I bothering? I can barely read your fucked up web pages on Linux Netscape. You don't even know HTML, you freak losers. So, to answer your conditional, you are not crazy; you are butt stupid. Sorry, but that's just the way it is.
- For people dealing with very large and varied sets of XML formats
... it is infinitely more maintainable to have the conversions ... written out as a set of XSL sheets instead of ... one rat's nest of perl script after another.
Well, as a Java bigot, I am dedicated to eliminating Perl rats' nests wherever possible! In fact, I'd agree with your statement 100% if I'd ever had to deal with XML documents. I don't have to deal with XML documents and I've never seen anyone who did (with the exception of certain specific publishing applications).My data is always in the form of some kind of Java object or collection of Java objects. I suppose that if I were a Perl programmer, I'd have some Perl arrays, hashes or object containing my data instead.
An XML document in a file or a memory buffer does me almost no good whatsoever, so the closest I'll ever have to an XML document is the JDOM tree resulting from parsing the source document. This JDOM tree is, of course... you guessed it... a collection of Java objects. Again, if I were a Perl programmer, I could use Perl's powerful text munging to stay closer to the original XML, but I'd still end up parsing stuff out of it.
Seeing as how my data is not in XML documents, but in Java objects, I have a variety of standard, non-confusing, error-free and flexible ways of turning it into HTML, WML, PDF, TeX, MIF or some kind of XML. WebMacro is a personal favorite.
XML is a useful data description and interchange mechanism, but things got way out of hand before people finally figured out what they really wanted to do with it. During this time, I saw several systems that operated on data by passing it around as XML documents. This might make sense in a server-to-server context, but within an application, it represents a fuckload of unecessary parsing and reconstituting of XML documents. If I already have the data in a format that is convenient and accessable to my programming language of choice, why the hell would I turn it into an XML document, unless I was exporting it to some "black box" on the end of a socket connection? Because it's trendy?! No thanks!
XSL and XSLT are predicated on the idea that my data will be in the form of an XML document while I'm working on it. In practice, it turns out that this is extra effort. If I find myself in the position of being given existing XML documents that need only to be converted to another kind of document, I'll revisit XSL, but I tend to work on more dynamic data than that.
...pre-emptively submit the death of iCopyright.com to FuckedCompany. $1.6M in funding? 66 employees? I give them until 3Q2001... maybe 1Q2002, if they're frugal.
The dot-com graveyard is full of companies that couldn't really afford to do what they were doing for free, but couldn't get people to pay. That's just tough. Would you pay for access to Slashdot? If not, prepare for it to go away (unless its ad revenue sustains it). We'd all miss it, but it wouldn't be our fault that Cmdr. Taco et al gave away free access to it. That was their choice, their plan and we were happy to soak up their precious resources while they lasted.
Or are you a "freeloader" posting here?
- When you put up a link, it's as if you are including part of their web site in yours.
No, it's not "as if you are including part of their web site in yours." It's not including anything on their website unless you actually copy part of their website to add context to the link. This copying may already be permissable under "Fair Use" provisions in US copyright law, as well.Putting up a publically-accessable web page is like leaving an infinite supply of leaflets in a stack somewhere. You may make money by putting ads on the leaflets. If I tell someone "hey, there's a leaflet about Foo and you can find it in a pile on the corner of Bar Lane and Baz Avenue," I owe you nothing. In fact, if you gain revenue by distributing leaflets, I've done you a favor.
If the leaflets are for "paying customers only" it's your job to make those customers pay -- not mine.
- I didn't read the white paper, but what you describe sounds [like] the ResizeTool object we use in our own product...
Now that my post has gotten a couple of responses, I realize that by the end of the day, there will probably be two dozen examples of things that this is "like". Yeah, it's kind of like your ResizeTool and it's also reminiscent of the Decorator Pattern as the other poster pointed out.Fine. Maybe I'm insane and DML is the pinnacle of OOP. Go ahead and embrace it... love it... touch it! Lieben Sie das DML! Now is the the time on Slashdot when we dance!
- What if the client wants to get the data displayed in a format they can control?
... I think the concept of getting raw data from the server and being able to present it client-specifically is an awesome idea.
Yeah, but that's not the concept behind XML/XSL. It is, to some extent, the concept behind XML; the server delivers raw data for whatever purposes the client needs it. However, if I attach an XSL or XSLT document, then I'm telling you how I want it displayed. The issue is "where is the presentation layer"? If I deliver you HTML, that question has been determined: I'm at the presentation stage. If I deliver you some kind of XML, then I have no idea how (or if) the data is to be presented to a human.Your point is quite valid, but the issue of how data is delivered and presented is artificial. It was created by people who forgot that not all clients are web browsers and not all transports are HTTP. (Actually, they probably never knew, because they got out of school in 1996 and went to work at Microsoft.) "Web" designers who use a Model-View-Controller design don't have any problem delivering an "XML version" of their data, where appropriate. The XML+XSL was a clumsy one-size-fits all approach. "It's for browser! It's for middle tiers!" Oh I see... I'm a server and I don't know what I'm serving to or why, I just spray whatever data you want into any socket connection that comes my way. That works great until you start serving data that has some value (like account information or a telnet session or email for a particular recipient). Then the server has to be a little more careful about what data is sends and what it is willing to do on behalf of the client.
- Actually, this is a really cool design pattern called Decorator. Read up on it, it's actually a useful idea for some applications.
No it isn't. Adding a resize object to a widget in order to make it resizable is not a Decorator pattern. A proper use of the Decorator patter would be to create a DecoratedWidget base class that contained a reference ordinary Widget. The DecoratedWidget would pass through ordinary Widget methods and subclasses of DecoratedWidget could add "one-off" methods such as resize() without creating zillions of subclasses of Widget.This design pattern is heavily used in Java, particularly when doing a lot of AWT (GUI) programming (something I avoid, but I've done enough of it...). Decorators are particularly useful when your language doesn't support multiple inheritance (like Java). Java, in particular, supports a mechanism called an "interface" which is like a pure virtual object. You can "implent" as many interfaces as you'd like, but you have to provide method implementations for all of each interface's methods. Often, for an inteface "Foo", there will be a class called "SimpleFoo" that you can use in a Decorator pattern to provide the base functionality for implementations of Foo. Read up on it.
Have you ever seen one of those situations where someone takes a smattering of technical knowledge and industriously recreates something that already exists... but does it badly? (If you haven't seen this, Microsoft has a whole catalog of products to illustrate this point.)
There is so much cluelessness on the Athena OS site, it's really hard to figure out where to start, but getting down to the core technology: DML is stupid. DML is the "Object Oriented GUI language in XML." Buzzword compliant? You bet? Useful? Not!
XML is a rotten format for programming languages. Anyone who's worked with XSLT knows what I mean. XSLT (related to XSL) is, essentially, a programming language that converts XML documents into other XML documents and XSLT itself is (drum roll please) an XML document. Why? 'Cause XML documents are sooooo late 90's -- and in the late 90's, you could sell shit-on-a-stick if it was XML-compliant. If you've ever seen an XSLT program/document that did anything vaguely complex, you immediately think, "Fuck! I could do this in 10 lines of..." Perl? PHP? Java? Visual Basic? All of the above! There is no language that is not preferable to XSLT.
The idea that spawed XSL/XSLT was that in "the future", browsers wouldn't download HTML, they'd download XML documents, and an associated XSL document would turn it into something displayable on the client side. God forbid a Perl, Java, PHP, or ASP program on the server do this for you -- no, let's make the thin client fat again, by giving it the responsibility of not only rendering, but organizing the data. Proof positive that this was a dumb idea what that Internet Explorer 5.0 proudly featured a robust implementation of this idiocy.
So, already, we have the case that anyone who isn't laboring under the deficits inflicted by a head injury has figured out that you really don't want to force any kind of programming language to look like a valid XML document. So what is the big deal with "Athena OS"? Oh, it's a programming language that is XML-compliant. How clever.
This "XML-compliant" programming language causes you to do really weird things architecturally. If you read the whitepaper, you will see an example where they make a widget resizable by attaching "resize" objects to it. "resize" is an object?! Diagram that, UML-mongers!
Piled on top of basic Bad Technology(tm), are numerous statements that indicate that these guys have never looked at any other system. Their claims about the flexibility of their design are laughable to anyone who has seen Motif widget management or Java AWT LayoutManagers (GridBagLayout is a bear, but it's incredibly powerful). Seriously, they try to sound like they've invented a better mousetrap, but you start to wonder if they've ever seen a real mouse. Like, where did they get this gem:
- XML and HTML standards are defined by their respective organisations and have no direct association with Rocklyte Systems or the DML standard.
It's like they don't even know where HTML and XML come from... but whereever they're from, it's not Rocklyte Systems and we want to remind you of that. This is just laugh-out-loud funny.- Java
...but six years too late and not nearly as good.- "Check by phone"? What sort of crap is that? I'm glad there is no such thing in my country!
I'm sure they'll have it in your country, too, as soon as they have phones. - ...I do not want to see issues such as this decided by the government. I would like to see these issues decided by the common sense of the masses.
This is a great idea!Unfortunately, we need a way to distill and enforce this common sense. Sure, "market forces" seem like a tempting answer, but market forces only reflect the common sense of the market, not the commoen sense of the masses. As others have pointed out, a killer-for-hire service may be supported by the marketplace, but is obviously against the "common sense of the masses."
Maybe we could elect representatives who would be answerable to various segments of the population. These representatives could be granted enforcement powers -- powers they hold only as long as they stay in office, something they can only do by faithfully representing the "will" of their segment.
We could call it "Democracy."
Actually, on second thought, it wouldn't work. It would require the constant participation of the population, obviously too much to ask. Instead, the "masses" will call for some kind of new system that promotes their interests but doesn't require any effort from them whatsoever. They'll get what they deserve, at that point.
- According to some corporate cultures, a person who is not progressing in "rank" is seen as stagnant, and therefore a loser. This is actually codified in the military (at least the US military) and is prevalent in professional services firms where you can make partner. (Law firms, accounting firms, "consulting" firms like McKinsey and BCG).
- If you don't promote someone to a more leveraged position, it's difficult to cost-justify paying them more each year. In theory, a management position allows you to leverage your expertise by helping less-senior people do the job your doing now. Economic factors may cause your position to become more valuable, but barring those externalities, your intrinsic value to the company isn't changing if you don't move up. You need to be prepared to get a small or zero raise if you stay in one role.
That said, consulting/account firm PricewaterhouseCooopers, a venerable practitioner of "up or out," did a study a couple of years ago and figured out that it cost them $50K, on average, to punt a perfectly good employee just because he or she didn't fit the next higher promotion level. This issue is particularly accute in these kinds of companies because as you progress from "Manager" to "Senior Manager", your role changes from "person who does work" to "person who sells work." I'm willing to bet that a lot of people who read Slashdot would cringe at the thought or going from project participant to salesbot. Anyway, PwC is trying to tackle the issue as are other "up or out" organizations, inlcuding the US military.Anyway, I agree with the posters urging you to tell your company that you don't want a permanent promotion. Point out the cost of filling your job as well as the management position. Give them a deadline or they may "forget" that your position is temporary.
As an aside, although the consulting firms are ultimately geek-unfriendly, they can be great experience for a couple years, particularly starting out.
There are plenty of stories wherein open source software has quietly proven a success. Quietly? Sure. Home Depot may be on Linux, but IT is not percieved as a fundamental issue for Home Depot's financial success, things like Supply Chain Management (SCM) are. Of course, if their IT infrastructure fails, it will screw up their cutting-edge SCM, but financial analysts rarely drill that far down.
A good example is the rise of DEC. (The fall of DEC is an example of other things :-).
In the mid-80's, insurance giant Aetna bought out a small insurance company -- something they do all the time. In the course of their due diligence, they requested a roster of standard reports. The reports arrive two days later. The Aetna execs were flabbergasted. It took weeks for a team of RPG and COBOL programmers to coax similar reports from Aetna's computers. What kind of computers was this small company using? "We run on DEC machines running UNIX," they answered.
Before you knew it, DEC was the new star in corporate IT. IIRC, 1986 was the Year DEC Could Not Be Stopped. Linux has a lot of good buzz, but it hasn't crossed that perception barrier. What will it take? It will take someone betting on, and winning with, Open Source.
I'm running my ecommerce infrastructure using Linux, Apache, NetBSD, mod_php, Jakarta Tomcat and PostgreSQL. The only closed-source element is the JVM that runs Tomcat and I can replace that with Kaffe eventually. Have I bet my business on Open Source? Not really. I told a Sun and an Oracle rep just last Thursday that if Linux and PostgreSQL begin to break under stress, they could expect a call. I can switch to Solaris and Oracle in a weekend. Even though I have the source code, I have neither the time, the expertise or even the interest in developing Linux and PostgreSQL into a solution that can rival the power and stability of Oracle running on dual E6500's. I will, at the point where I need that, have the money to pay for them. Right now, I'm just one of thousands of businesses that is controlling their startup costs by building their initial infrastructure on Open Source. That's a plus, but it's not the testimonial Wall Street needs to see.
What needs to happen is a success story build on Linux or NetBSD that couldn't have happened using closed-source approaches. I don't know what that's going to be, but I'm sure it's on the horizon. If I do think of it, look for me on the cover of Forbes (I'll see if I can get Linus to stand behind me and grin appreciatively).
Nomadic makes a good point and there are even more historical examples. 13th century Sufi poet Rumi wrote in Persian because it made his work more commercial at the time. In China, the common language is Mandarin, but there are over 350 other dialects, Cantonese being the second most popular. What's worse is that they're usually mutually unintelligable. People in Hong Kong speak Cantonese, and unless they are well-educated (and sometimes, even if they are), they neither speak nor understand Mandarin. That became a big problem in 1997 when they rejoined the PRC. Rather than fretting over the "destruction" of dialects, China maintains the supremacy of Mandarin. If they didn't, the country would balkanize and lose its status as a world power really quickly.
Most Linux course try to include this demonstration:
Take out a raw egg and say, "This is your brain." Then say,"This is your brain on Windows." Then pelt Bill Gates with the egg.
The reason this is usually skipped is that it's tough to get Bill Gates, but it's worth the extra effort.
When I heard about this, I was pretty surprised. I thought "obfuscated Perl" was redundant. If they want a challenge, how about a "Documented Perl" contest?
In this, the entrants must write a non-trivial application, entirely in Perl, that has to be completely portable across at least 3 implementations (including one on Windows) and at least 25,000 lines of code (not counting comments).
Judges will introduce a bug into each program that would be obvious if you knew what the program did. Each bug *must* involve a cascade from an ambiguous or subtle misuse one of Perl's much-heralded "Do what I mean" functions.
A panel of experienced Perl programmers will be given the programs to debug. The program that takes the least average time to debug wins.
That's a contest.
- .kids [and]
.tel ... seemed too ambiguous.
Yeah, what's to stop me from putting up a website with the URL:http://sex.with.kids
http://promise.not.to.tel
Nothing can stop me. I'm evil.
- he means modern physics
Really? 'Cause he says, in the very next sentence:- Gravity, mass and velocity
These were widely understood before Einstein described objects moving through space curved by mass. Nuclear physics, quantum physics, relativity and special relativity are fairly new (but not even 50-75 years new), but that's not what he's talking about. He's talking about good ol' Newtonian physics. As in Sir Isaac Newton, the 17th century mathematician.- OK, I know the actual science of physics has only been around for around 50-75 years, but it's pretty well documented;
Wow, you're off by almost an order of magnitude on the age of the science of physics -- and that's if you ignore Plato and Aristotle's efforts.For example, one programmer bragging about how much Java helps his bottom line was one-up'ed by another AC claiming that Perl programming had netted him "$5 million" a year.
Another good troll is to point out that the dot-com industry has, for the most part, only actually made money by selling equity -- not products or ads. Immediately a bunch of AC's will come out and say "oh, you're just jealous because you didn't make tons of money like we did."
Fine. I guess I'm the only person who reads Slashdot who doesn't have a couple mil' in the bank and a private jet.
Why, then, with geeks supposedly swimming in cash, is the EFF "underfunded"? I suspect that the "swimming in cash" is just part of the delusions of granduer that the geek community has. Sure, some geeks are loaded, but I think that a lot more are sitting on some stock options that have yet to do anything and even more are just pulling in a decent paycheck and want, desperately, to believe that they'll be millionaires someday, too (clue: no one ever became rich selling their time).
Also, unlike the Amiga, OS/2 has been mentioned once on Slashdot this year. The Amiga has been a headline seven times and it has it's own fucking category.
Good products fail and fade away. It sucks, but it's true. For every one, there are the core faithful who still use it. Good for them. Slashdot's techno-necrophilia regarding the Amiga is just silly.
- Java where it's not even possible to write directly in bytecode (at least not so far as I know
You can.- The next time the code is called, the compiler optimizes that code a little more, and so on, until frequently used code is extremely optimized.
... No Java JIT that I know of can do this.
Ummm... it's called "HotSpot" and it's been out about a year.Do you know anything about anything, or do you just like typing?
Following the zone diet involves geeky calulations and measuring of things. Your kitchen becomes a lab. Barry Sears encourages people to think of food as a psychoactive drug. How much more geeky can you get?
The Dilberito is too high in carbs, too low in protien and the protien is does have is locked in a fiber matrix, making it hard to absorb. It's weird because in the same "Dilbert Future" paragraph that Adams talks about the then-hypothetical food, he also mentions the Zone. I was disappointed to see that the Dilberito is not "Zone Friendly" particularly because it's so difficult for vegitarians to get the protien requirements needed to adhere to the Zone diet.
- Corrinne Yu:
Look, lady, Better Homes and Gardens outsells Penthouse and Playboy combined while Ms. and Working Woman struggle for subscriptions. Women did that. Cosmopolitan sells millions of issues without a single article on programming. Women buy it.[I'm in the 99.9999 percentile. Nothing you say applies to me. Stop it!]
When you get to the fringes of the culture, generalizations cease to apply. Still, there's no point in pretending, that these generalizations are invented. They're not; they are based on observating the mass of people who inhabit the center of the bell curve.
It's obvious that a lot of guys on Slashdot have never actually spoken to a typical American woman. I wonder if you have, either.
Pat Robertson.