Higher level languages exist because they allow something to be expressed in a way that is more readable and efficient than a lower level language, and this leads to more robust code.
When implementing said "something", with said language, you are generally worried about the meat and potatoes of the language -- what was it designed to make easier for me. The syntax of the language to implement the primary goal of the language becomes the "main course". C++ was designed to make OO easier for those who needed C compatability with legacy code. The syntax necessary for this raised the bar on what was "sugar" vs. "meat and potatoes". "class" is a main course in C++, not a sweetener. "private" and "public" are main course words in C++ and Java (security is part of encapsulation, a necessary feature of OO design).
Some sugars are strictly of the "hey, i can do this in fewer keystrokes in my language". Java has "+" defined for Strings. Perl has so many of these its almost impossible to read.
The property-handlers (and that isn't even good OO) and the use of [] seem to fit this category. (I reiterate -- when did "l.get(index)" become so hard to type?)
"Foreach" exists in C++ as part of STL. That it was left out of Java's collections was a MAJOR oversight, severely limiting the API for use in "Generic programming" without additional support from the programming (e.g., building a "foreach"). I really wish ObjectSpace continued to support JGL they way they claimed they would. It may have been larger, but like the C++ STL it modeled, it was VERY effective.
In any instance, it is (or would be) part of the library. But is "foreach" in C# part of the language or part of the library? If its part of the library, good; shows C# having better support for generic programming than Java. If its part of the language, then WHY? What good is it for the compiler to be responsible for something that is implemented in 2 lines of code within the language itself?
Primitives as classes -- well, how sugary that is depends on the programming model they expected them to be used in. That definitely seems to be there strictly to be a "well, this isn't java" feature, rather than having a practical purpose in mind. When the language is used more heavily, we'll see if it evolves into something useful.
Java had its reasons for pass-by-read-only-reference wrappers. Mostly these had to do with thread safety. I also find them to be useful in data integrity.
Besides, EVERY language seems to be easy at first, and only when integrating pieces of it written with different design goals and implementation policies (e.g., various java libraries, or STL with MFC in C++) do things get to be hard.
From a compliler writer's point of view, C is incredibly simple. It was designed to be that way.
From a syntax point of view, Java is one of the simplest languages out there. The libraries on the other hand (because of the quantity and age) make things more difficult. Java also adds the complexity of multiple means of deployment (applet, servlet, jsp, bean that can be run from anywhere, EJB, now WebStart) is another factor that makes java complex...but again, that's a library and runtime factor, not a language factor.
Java has flexibility, and with flexibility comes complexity.
C# has some usage. It actually (given "everything is a COM object" may be better used not for writing applications, but for writing components with better speed and robustness over VB components, but can still be utilized in any COM system built in VC++ or VB.
And my argument is that unless designed right and all the developers agree on how the "syntax sweeteners" are to be used, "quick coding and limited debugging" can become maintainance nightmare.
It all depends on how long you expect your code to still be used. If you expect the people who take it over to eventually ditch the whole thing and rewrite it (something happening more often than not, these days...), then fine, use what you want.
If you expect your stuff to continue to be used and debugged, especially by others, then be choose how you use your sugars wisely. AND DOCUMENT.
Me personally, I found few of those sweeteners to be anything that would really get me to write more efficient, more readable, or more robust code. Quite the opposite, in fact.
Taking the metaphor slightly more seriously than possibly intended:
"Just gimme the damn plant, I'll roast the beans myself, thank you very much!"
When I have to read someone elses code (and I do constantly, for purposes of debugging, integration, and future maintainance 'cause that programmer's no longer with the department or company), I need to be able to see what the hell's going on. In order for this to work, the language can not be vague in its definition of what's going on.
C++ allowing overloading of the () operator was already crossing the line as far as I was concerned (though the STL justified it beyond my wildest expectations and I now adore it when used in that manner -- see "Renumerations on C++" by Koenig & Moo.
That summary description of C# basically gave me a list of things that might be nice, but when put into practice can lead to code that is unclear as to what's going on "behind the scenes". Does a "set" method do more than just "set" the field to the given value? There (taking Java as an example), I need to look up the set method. If the C# convenience was used, I'd have to look up to see if there was even a set method in the first place...THEN (if i found it anywhere in the possibly rediculously large hierarchy), I'd have to examine it to see what it does.
But just looking at it on the surface, I wouldn't know it even was calling a function.
At least with operator overloading of [], I'd know by the variable type that I had an object implemented by a class, and not an array, and would know that a function was being called.
Syntactical sugar is unnecessary. To see the effects when a language gets overloaded with it, check out Perl. I've looked at it for 10 years, and I STILL can't make sense out of 3/4ths of the programs out there written in it.
So far, I've seen no arguments that C# advances the state of the art.
More importantly, I've seen no arguments that C# exists to solve programmers' or customers' problems that can't be solved easily in another language. Languages don't really survive because of "state of the art". They survive because they answer a programmers need that is difficult (or impossible) in an existing language.
For really kick ass fast (but mostly portable) structured code: ANSI C.
For really kick ass fast Object-Oriented or Generic-Programming (mostly portable, but watch out for the non-standard libraries you use) code that also allows you C-level access to legacy and O/S libraries: ISO C++.
For moderately fast Object-Oriented code that runs unchanged on a number of platforms, with powerful libraries supporting web access, database access, and graphical user interfaces, and a whole lot more, provided a binary interpretor exists on the target platform: Java.
For pure OO: Smalltalk.
For mostly-pure OO with a decent design-by-contract model: Eiffel.
For stuff working really quickly in text or web processing: Perl.
For programming in a "safe" environment where the compiler will pretty much catch 95% of your errors for you (even things that wouldn't even snag a warning in all-warnings-on C++): Ada.
For getting stuff working really quickly in the Windows environment: Visual Basic.
What's missing that another language needs to fill? If you find something, go invent a language or language library to do it. Until then (HINT Microsloth) leave us programmers to using tools that get the job done.
Java doesn't let you use primitives (int, short, etc) as classes without wrapping them yourself (lots of overhead).... C# does.
So what? syntactical sugar, nothing more.
Java doesn't let you drop down to native code and turn off the garbage collector if you need to. Or use pointers if you want to talk to the underlying C-based OS.... C# does.
Translation : Java doesn't allow you to break its programming model and create very intentionally unstable code. C# does.
If you want Object Oriented programming with raw C-like access to the O/S, use C++. That's what its there for (ask Bjarne. he says this every time the subject comes up).
Java doesn't have a "foreach" statement.... C# does.
Syntactical sugar. Easily done by adding a foreach functional object (see C++ STL), using the collections classes. Yes, I'd rather see real generic programming (no casts) in Java like it is in C++, but until that's there, make do.
Java doesn't have property-handlers (eg. write functions that are treated as member variables - eg: a.setName("MyName") would become: a.Name = "MyName" - but it would still go through a function. These are great for encapsulation. C# has it - Java doesn't.
Syntactical sugar. I'd rather the code explicitly tell me that a function is or isn't being called. When i can't instantly look at a line of code and go "that's not calling a function" (which in C#'s case, i can't), then i won't trust the code.
Java doesn't have any versioning mechanism (other than the woefully inadequate @deprecated tag).... C# does.
So C# now forces you to keep all of your mistakes around in every single file, just like other MS products like the Office file formats? No thank you. Roughly translated, C# mandates Code Bloat automatically for you.
Java doesn't support indexers (methods on a class - say List, which allow you to take the object of type List, and use it like an array - eg: List l; l[index] = "asjdasid" C#, however, does.
Syntactial sugar. In C++, that's operator overloading. I didn't realize "l.get(index)" was so fucking hard to type or read.
The Big Three (Ritchie, Stroustrup, Gosling) each said in the C++/Java Report interview that there was certainly room for more languages, possibly derived from the C family, provided it truly fulfills a programmer's needs.
But C# doesn't answer programmers' needs. Its a syntactical "wish list" that I can do without. Using these examples, I can write a C# subset preprocessor to translate into C++ in a day (note : i've not read the spec, only this checklist).
hey, i'm going by my experience. When burn-all-gifs day came along, i took my gifs, png'd them, viewed them in gimp to see that the transparancy survived the conversion (it did), then stuck them into my pages.
Neither Netscape for windows or Netscape for linux supported the transparancy.
Well, that's a start, but that doesn't cover the RIAA's license and royalties ($5000+, independent of any deals you cut with ASCAP), nor does that include the multitude of British artists on BMI, or Canadians on SOCAN, that haven't negotiated "you scratch my back" deals with ASCAP.
And (given the direction of things in the dot-com world), there will be a limit on how long ad-revenue-only sights can survive.
well, if png hadn't made the transpearancy so complicated (think about it -- 256 pixels, and one of them is "empty" is MUCH easier to implement than full-alpha-channel support), PNG transpearancy in the browsers would exist, and we wouldn't have a need for the gifs...
the only reason PNG never caught on was 'cause GIF still gives browser-supported transpearant pixels, and the browsers don't support that for PNG.
Yes, maybe mozilla will (finally) change that...but even now its only just showing up (after 16 milestones, guys?).
We do not charge royalties for mp3 streaming or mp3 broadcasting (e.g. Internet Radio) until the end of the year 2000. Beyond this date we anticipate to charge a small annual minimum and a percentage of revenue. However, this model is not yet fully developed because we cannot yet oversee where this new market is going.
Shoutcast and Icecast/Liveice users, be ready -- you're next. Not only do you have to pay the RIAA for the recordings, and BMI/ASCAP/SOCAN for the music, you'll now have to pay these jerks for the software. Kinda rediculous, considering I've never seen an online broadcaster of music using mp3 technology showing more than, say, a couple hundred in the audience...most broadcasters had only 2-10 listeners before RIAA decided to shut them down anyways...
And if $15,000 is what they've got for minimums elsewhere, I'd hate to see what "small" is in this instance...
No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users.
This means that winamp, xmms, etc, are fine. RealJukebox Plus will owe, however.
Ok, how long will it take before RMS calls for another boycott?
The list of Apogee's trademarks also includes such gems as "Prey" and "Come get some".
A "Murphy's Rules" in an old Space Gamer (Steve Jackson Games) once reported that on 3 of the cardboard counters, the Indiana Jones Role Playing Game trademarked the term "Nazi".
The domination of MS file formats (e.g. Office files) is still a factor. It was listed in the findings of fact. It will therefore figure into the decision.
Forcing a product to come into existance that wouldn't on its own accord is out of the governments range of punishments. (Office for unix).
However, forcing open specification of the file formats IS within the vein of punishments or degrees. Personally, I still feel that opening up the file formats to a clean specification (so companies like Star Office and Applix and Corel can build interpretors without the bugs of reverse engineering) is more than enough to hurt the Office division. They lose their real monopoly, not on the GUI, but on the files being exchanged.
Why are MP3's so much more widespread over the other compressed music formats (windows, real, etc)? Beause the spec for them is open (protected by patent, but not by copyright). It allowed free programs to be built for the general masses, and commercial products build for better optomizations. For the customer, its "you get what you pay for, but you don't HAVE to pay". The proprietary formats won't allow this. Since the alternative exists, the proprietary forms only survive out of their exclusivity.
Its unfortunate that MS's media actions (all typical MS behavior, with RealNetworks being the target) all happened after the findings of fact. MS is doing the same thing to Real they did to Netscape (give away the products for market share) and it will end up going unnoticed by the decision. So lots of Windows Media stuff is still gonna come out that no Unix (Linux) user can ever see. Windows ME (Media Edition), the next generation of Win98, will have bundled into it file streaming capabilities, which makes Real's for sale server products a moot point.
Well, we know that's never gonna happen. This is STILL Microsoft we're talking about.
2) the compiler company changes the compiler on them
How often (not counting the instability of the moving standard that's been C++ and Java over the last 5-10 years) has changing a compiler really changed your work environment for the worse?
Stick to the ANSI C and ISO C++, and libraries that are either in-house or certified compliant to some acceptable standard (say, POSIX, or the C++ Standard Library), and the compiler is almost a non-issue, save speed and efficiency of optimization and debugging/profiling code, and compilation environment (e.g., IDEs).
BUGS in the compiler, that's different. (e.g., when a bug in EGCS stopped the linux kernel from compiling for a while).
Yes, I know the days when a ton of C++ code suddenly stopped compiling 'cause the complier vendor decided to switch to following the standard and BOOM all of my template based code was _loudly_ broken. but they were things i could fix. they didn't affect my executable once i finished it. they were MY problem, not my customers (save the time delays).
But i've never had a compiler introduce bugs into my final binary code that weren't mine to start with. (If a compiler is THAT broken, it would be out of business REAL fast if the vendor didn't fix it even faster, and its should be easy to go back to the older compiler that worked).
I know its possible, and probably has happened, but not to me.
Bob Cringely has on several occasions described the remedy that would satisfy Stallman's "#1" and perhaps be more damaging in the longer picture...to MS at least.
He believes the only group (the group most ignored by the prosecution and the judge so far) to be split off should be the languages and libraries group. Basically, if Windows (and therefore Internet Explorer) lost the "secretness" of its APIs (including file formats since they're all shared within ms applications), the market would quickly get more competitive.
Not sure I believe him, but its raising a point that most have forgotten. MS is still a languages company. Languages aren't "applications" in the same way that Office products are.
The "Trade Secret" factor is an unofficial interpretation of the words of the license agreement. Trade secrets are not protected in and of themselves by the DMCA. In fact, the fact that it's a trade secret is mostly irrelevant, save that it is what triggered the license agreement in the first place.
Bypassing the software that has the license agreement dialog violates the DMCA. Posting instructions to do so violate the DMCA (publishing on the web instructions for an illegal activity). Posting links to such violates the DMCA (publishing links to illegal pages).
Those items are worth fighting. The DMCA is excessive in its restrictions to the point that free speech is restricted, violating the constitution.
Slashdot carrying the full text of the document protected by copyright (regardless of either license or "trade secret" status). That has the potential to be illegal under long established (and enforced by the court system) copyright law. That part is where slashdot might not have a leg to stand on.
The compromise will end up being where slashdot removes the verbatim copies of the document, but leaves the "links and instructions" comment postings alone. Besides, by the time a decision is made, MS Kerberos will have gone through its requesite 2 versions, and the working version 3 will be up. This is only "1.0" -- no MS 1.0 works, and we know this.
I never meant to imply that SunOS was a System V varient. I was just listing all of the "popular" unix varients available. SunOS and Ultrix were BSD based. The others generally were System V based, and each adopted some degree of BSD code for compatability with software already written for SunOS (in particular NFS, which is why the System V dfstab took so long to catch on, compared to SunOS's exportfs system).
Of course, each picked their own subset of BSD features to implement...read the unix hater's handbook for some details on the nightmare this created...:)
Sheesh...I'd forgotten 'bout "DECWindows"'s widget from before Motif. The HP/Microsoft side of it (which was the "look" of Motif but not the "feel" which was DEC's) got a lot more publicity...especially with that book that someone from HP published...
but by then Digital cared even less about fixing them then in the DECwindows era
Agreed. Once "OSF" was responsible for maintainance, DEC contributed next to nothing. Same for "OSF-1" (the first 64 bit unix implementation). I wasn't suprised that updates were slow for OSF-1/Digital Unix bugs.
I don't even mind paying for it, but if it comes out of my pocket it had better be affordable.
Agreed^2. $5,000 was a bit much...especially when there were such tight limits on how far we could distribute our bug fixes even after paying that amount. For the most part, when I talked our company into a source license, my main goal was to nail down bugs tight enough to at least have a better shot at a workaround. The licensing couldn't allow much more than that.
For some reason (and this hits a whole can of worms on its own), the larger companies, who seem to have more people available and actively fixing bugs, seem to have the most trouble releasing bug fixes. From Microsoft, through IBM, DEC, OSF etc...finally down to our most recent favs, Netscape (pre AND post AOL). Seems fixing the bugs is never hard, but coordinating bug fixes and new functionality into a "release" is next to impossible...
Bug fixes somehow fail to make the "release", which ends up nothing but a whole new collection of bugs.
I first saw this at IBM with the bug in the assembler's debugging code generator that forced one to acquire a patch to get gcc to work right. The patch was described and available for AIX 3.15. By AIX 4.1, that patch fix had never actually been applied to the principle source tree. One still had to contact IBM and get the patch all over again.
Netscape's 4.x releases have been similar, especially for non-windows boxes. There's the infamous "frames and colors" bug for unix/X, that had been around since frames were first introduced (in 2.0). When the source code (such as it was) was finally released, I seem to recall it was one of the first bugs fixed...only that fixed code (which was something like 5 lines total) never made it to the 4.5x tree, and its presence in Mozilla was removed when the layout engine was rewritten. Meanwhile, netscape 4.72 STILL does funky things with my default color choices as soon as I hit a frames page, the same funky things it did 2 1/2 years ago.
Well, I never really saw Motif as that hard to program...for some reason, I was a natural to Xt's programming style from day one. One thing that made Motif difficult was its timing -- when C compilers (and certainly C++ compilers) were finally enforcing the standard, and many "cheats" people got away with were getting snagged by the compiler as violations and errors. Not one demo of code in the original O'Reilly 6 or Doug Young's first book would compile on a C++ compiler.
GTK doesn't really seem all that different. I'm trying some GTK in adding a piece to a GTK app, and finding its pretty much all the same as motif so far. The "big look improvements" (skins/themes) are all hidden behind the scenes. Benefits to the end user, but not an API simplicity. Its still "create object, set parameters, create callback, add callback to object, lather, rinse, repeat" ad nauseum for every widget you create. To me (and JWZ's said the same), nothing's different. Yes, it did take a number of years (thanks to OSF's closed source model) for decent "How To Write a Widget for Motif" works came out (O'Reilly's XResource 6 and 10 had the best ones), but otherwise...
The most dramatic change for GUI's to me was Java's Swing, with its plugable models for just about everything (models, renderers, editors, etc...), but then again, I never studied Smalltalk's MVC or what was in Fresco, so i can't comment on what they delivered. Yes, Swing is heavy, but after finally making sense of the renderers and editors and all that, I have great difficulty programming without them.
Motif was also (in my later years of it) made VERY easy with the XMT toolkit from David Flannagan, in what was at the time O'Reilly's "Motif Power Tools", later just X Reference 6C. It got to the point where I never had to do "XmCreate..." or "XtCreateWidget" again. Something like that for Java/Swing needs to come in, but Javasoft spent too much time trying to make money for GUI IDE's to do something practical for real programmers.
Ok, i stand corrected 'bout the chip release. I don't recall seeing all that many sub-3000 pc's at the time though. I seem to recall that most of the other pieces (monitor, memory especially, decent disk space) were still prohibitively expensive at the time. A 4 meg, 25mhtz 386 could handle Unix, but I wouldn't trust throwing X on it (much less a memory hog like Motif).
As a college student with no budget, and with access to a Vax/VMS box (and being a C/S major access to Sun workstations and later AIXen and SCO), yes, a 286 box (at the time, still over 2.5K or more) was expensive. The idea of "Cheap PC's" hadn't arrived yet, because the whole point of getting a faster box was because you simply couldn't run (slow or not) the software you wanted on the slower, older box, especially post-Windows 3.0/3.1/3.11. Due to addressing space issues, the chip itself just couldn't do it (and DOS didn't help matters, of course).
Yes, I'll conceed that not being able to fix motif bugs was a pain in the ass.
By the time I was working in Motif and getting paid for it, I had already taken to using either Doug Young's C++ framework, or David Flanagan's XMT library (I _really_ wish he'd do something like that for Java/Swing, rather than just the reference rehashes he's been doing for O'Reilly recently...).
I could never figure out why they would push it as a standard UI while pricing it out of reach of the hacking community.
HOLD IT!
I would like people to remember the time period of Motif 1.0: 1989. If you had access to a Unix box in 1989, you had a commerical Unix system. Period. End of discussion. You had SunOS, Ultrix, AIX, DGX, Irix, HPUX, SCO or some other System V variant. MAYBE if you were a university you might have a pure BSD box, but those were getting rarer even then. There was no PC capable of handling unix (yes, a 286 could swag Minix, but those were still expensive, and SCO was already pushing their product around for those boxes as a supported solution).
The unix hacking community centered on SunOS at the time. That was it. Since OpenLook sucked (to some hackers), most open source X apps were strictly Athena, or like XV, based on a toolkit written specifically for that application.
If you needed Motif, you bought it (since Solaris didn't support Motif in any official vein until 1993). If you had one of those boxes, you could afford it. Generally, university CS departments and corporations were the only places Unix was found. So generally, if you had a unix box at the time, you could afford the extra few $K for Motif (if it wasn't already there). The idea that every student could have their own Unix-like box was absolutely unheard of. Workstations were $20-150K, and most unix boxes were "mini computers" that still took up the size of 2 refridgerators and needed an air conditioning box of the same size to match (hence the whole idea of X terminals and central servers).
There was no "100% Free" system out there that was reliable or fast enough to bother. Linux is just now getting the kind of attention its getting not because its especially better, but because the platform was suited for (the Intel box) is finally fast enough to handle it.
Motif was a commercial solution to the problem of commercial software vendors, priced at the time when commercial software on unix boxes was expensive. That the prices even recently were as low as $99 for motif (binaries only) was unheard of 7 years ago when I graduated.
A common thread across all of these (perhaps save for Fresco) is that Licensing Is Really Important.
Fresco showed that language was very important. C++ didn't have the popularity of C, nor the stability, and certainly not the pre-standard portability. Hard to use a language that's a moving target. By the time C++ achieved a sense of stability (and g++ even more so), Motif had "won the unix desktop" (though CDE would still be 2 years away), and Doug Young's classic text on Motif + C++ had dominated the C++ based GUI development world within X.
I respect what Fresco tried to do, but it was too much for most systems (my 16 meg ultrix box had a hell of a time compiling it) and too much most programmers to deal with at the time, and by the time it would have achieved something, the pressure from MS to "standardize" had locked out all non-Motif solutions until a different audience with a different agenda came along (re: linux, kde, gnome).
Side note: Finding out now that C++/Java programmers are STILL rare in the industry, fewer still appearantly in the Open Source community (how many open source projects use C++? Even with GTK--, I've yet to see a potentially major GNOME component be built in C++).
Slashdot Mirror
Higher level languages exist because they allow something to be expressed in a way that is more readable and efficient than a lower level language, and this leads to more robust code.
When implementing said "something", with said language, you are generally worried about the meat and potatoes of the language -- what was it designed to make easier for me. The syntax of the language to implement the primary goal of the language becomes the "main course". C++ was designed to make OO easier for those who needed C compatability with legacy code. The syntax necessary for this raised the bar on what was "sugar" vs. "meat and potatoes". "class" is a main course in C++, not a sweetener. "private" and "public" are main course words in C++ and Java (security is part of encapsulation, a necessary feature of OO design).
Some sugars are strictly of the "hey, i can do this in fewer keystrokes in my language". Java has "+" defined for Strings. Perl has so many of these its almost impossible to read.
The property-handlers (and that isn't even good OO) and the use of [] seem to fit this category. (I reiterate -- when did "l.get(index)" become so hard to type?)
"Foreach" exists in C++ as part of STL. That it was left out of Java's collections was a MAJOR oversight, severely limiting the API for use in "Generic programming" without additional support from the programming (e.g., building a "foreach"). I really wish ObjectSpace continued to support JGL they way they claimed they would. It may have been larger, but like the C++ STL it modeled, it was VERY effective.
In any instance, it is (or would be) part of the library. But is "foreach" in C# part of the language or part of the library? If its part of the library, good; shows C# having better support for generic programming than Java. If its part of the language, then WHY? What good is it for the compiler to be responsible for something that is implemented in 2 lines of code within the language itself?
Primitives as classes -- well, how sugary that is depends on the programming model they expected them to be used in. That definitely seems to be there strictly to be a "well, this isn't java" feature, rather than having a practical purpose in mind. When the language is used more heavily, we'll see if it evolves into something useful.
Java had its reasons for pass-by-read-only-reference wrappers. Mostly these had to do with thread safety. I also find them to be useful in data integrity.
From a compliler writer's point of view, C is incredibly simple. It was designed to be that way.
From a syntax point of view, Java is one of the simplest languages out there. The libraries on the other hand (because of the quantity and age) make things more difficult. Java also adds the complexity of multiple means of deployment (applet, servlet, jsp, bean that can be run from anywhere, EJB, now WebStart) is another factor that makes java complex...but again, that's a library and runtime factor, not a language factor.
Java has flexibility, and with flexibility comes complexity.
C# has some usage. It actually (given "everything is a COM object" may be better used not for writing applications, but for writing components with better speed and robustness over VB components, but can still be utilized in any COM system built in VC++ or VB.
It all depends on how long you expect your code to still be used. If you expect the people who take it over to eventually ditch the whole thing and rewrite it (something happening more often than not, these days...), then fine, use what you want.
If you expect your stuff to continue to be used and debugged, especially by others, then be choose how you use your sugars wisely. AND DOCUMENT.
Me personally, I found few of those sweeteners to be anything that would really get me to write more efficient, more readable, or more robust code. Quite the opposite, in fact.
"Just gimme the damn plant, I'll roast the beans myself, thank you very much!"
When I have to read someone elses code (and I do constantly, for purposes of debugging, integration, and future maintainance 'cause that programmer's no longer with the department or company), I need to be able to see what the hell's going on. In order for this to work, the language can not be vague in its definition of what's going on.
C++ allowing overloading of the () operator was already crossing the line as far as I was concerned (though the STL justified it beyond my wildest expectations and I now adore it when used in that manner -- see "Renumerations on C++" by Koenig & Moo.
That summary description of C# basically gave me a list of things that might be nice, but when put into practice can lead to code that is unclear as to what's going on "behind the scenes". Does a "set" method do more than just "set" the field to the given value? There (taking Java as an example), I need to look up the set method. If the C# convenience was used, I'd have to look up to see if there was even a set method in the first place...THEN (if i found it anywhere in the possibly rediculously large hierarchy), I'd have to examine it to see what it does.
But just looking at it on the surface, I wouldn't know it even was calling a function.
At least with operator overloading of [], I'd know by the variable type that I had an object implemented by a class, and not an array, and would know that a function was being called.
Syntactical sugar is unnecessary. To see the effects when a language gets overloaded with it, check out Perl. I've looked at it for 10 years, and I STILL can't make sense out of 3/4ths of the programs out there written in it.
Do that to a C based language? No, thank you.
I'd rather just get the job done.
So far, I've seen no arguments that C# advances the state of the art.
More importantly, I've seen no arguments that C# exists to solve programmers' or customers' problems that can't be solved easily in another language. Languages don't really survive because of "state of the art". They survive because they answer a programmers need that is difficult (or impossible) in an existing language.
For really kick ass fast (but mostly portable) structured code: ANSI C.
For really kick ass fast Object-Oriented or Generic-Programming (mostly portable, but watch out for the non-standard libraries you use) code that also allows you C-level access to legacy and O/S libraries: ISO C++.
For moderately fast Object-Oriented code that runs unchanged on a number of platforms, with powerful libraries supporting web access, database access, and graphical user interfaces, and a whole lot more, provided a binary interpretor exists on the target platform: Java.
For pure OO: Smalltalk.
For mostly-pure OO with a decent design-by-contract model: Eiffel.
For stuff working really quickly in text or web processing: Perl.
For programming in a "safe" environment where the compiler will pretty much catch 95% of your errors for you (even things that wouldn't even snag a warning in all-warnings-on C++): Ada.
For getting stuff working really quickly in the Windows environment: Visual Basic.
What's missing that another language needs to fill? If you find something, go invent a language or language library to do it. Until then (HINT Microsloth) leave us programmers to using tools that get the job done.
Java doesn't let you use primitives (int, short, etc) as classes without wrapping them yourself (lots of overhead). ... C# does.
So what? syntactical sugar, nothing more.
Java doesn't let you drop down to native code and turn off the garbage collector if you need to. Or use pointers if you want to talk to the underlying C-based OS. ... C# does.
Translation : Java doesn't allow you to break its programming model and create very intentionally unstable code. C# does.
If you want Object Oriented programming with raw C-like access to the O/S, use C++. That's what its there for (ask Bjarne. he says this every time the subject comes up).
Java doesn't have a "foreach" statement. ... C# does.
Syntactical sugar. Easily done by adding a foreach functional object (see C++ STL), using the collections classes. Yes, I'd rather see real generic programming (no casts) in Java like it is in C++, but until that's there, make do.
Java doesn't have property-handlers (eg. write functions that are treated as member variables - eg: a.setName("MyName") would become: a.Name = "MyName" - but it would still go through a function. These are great for encapsulation. C# has it - Java doesn't.
Syntactical sugar. I'd rather the code explicitly tell me that a function is or isn't being called. When i can't instantly look at a line of code and go "that's not calling a function" (which in C#'s case, i can't), then i won't trust the code.
Java doesn't have any versioning mechanism (other than the woefully inadequate @deprecated tag). ... C# does.
So C# now forces you to keep all of your mistakes around in every single file, just like other MS products like the Office file formats? No thank you. Roughly translated, C# mandates Code Bloat automatically for you.
Java doesn't support indexers (methods on a class - say List, which allow you to take the object of type List, and use it like an array - eg: List l; l[index] = "asjdasid" C#, however, does.
Syntactial sugar. In C++, that's operator overloading. I didn't realize "l.get(index)" was so fucking hard to type or read.
The Big Three (Ritchie, Stroustrup, Gosling) each said in the C++/Java Report interview that there was certainly room for more languages, possibly derived from the C family, provided it truly fulfills a programmer's needs.
But C# doesn't answer programmers' needs. Its a syntactical "wish list" that I can do without. Using these examples, I can write a C# subset preprocessor to translate into C++ in a day (note : i've not read the spec, only this checklist).
But I don't need it.
Neither Netscape for windows or Netscape for linux supported the transparancy.
I had to keep using the GIFs.
And (given the direction of things in the dot-com world), there will be a limit on how long ad-revenue-only sights can survive.
the only reason PNG never caught on was 'cause GIF still gives browser-supported transpearant pixels, and the browsers don't support that for PNG.
Yes, maybe mozilla will (finally) change that...but even now its only just showing up (after 16 milestones, guys?).
We do not charge royalties for mp3 streaming or mp3 broadcasting (e.g. Internet Radio) until the end of the year 2000. Beyond this date we anticipate to charge a small annual minimum and a percentage of revenue. However, this model is not yet fully developed because we cannot yet oversee where this new market is going.
Shoutcast and Icecast/Liveice users, be ready -- you're next. Not only do you have to pay the RIAA for the recordings, and BMI/ASCAP/SOCAN for the music, you'll now have to pay these jerks for the software. Kinda rediculous, considering I've never seen an online broadcaster of music using mp3 technology showing more than, say, a couple hundred in the audience...most broadcasters had only 2-10 listeners before RIAA decided to shut them down anyways...
And if $15,000 is what they've got for minimums elsewhere, I'd hate to see what "small" is in this instance...
No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users.
This means that winamp, xmms, etc, are fine. RealJukebox Plus will owe, however.
Ok, how long will it take before RMS calls for another boycott?
A "Murphy's Rules" in an old Space Gamer (Steve Jackson Games) once reported that on 3 of the cardboard counters, the Indiana Jones Role Playing Game trademarked the term "Nazi".
The domination of MS file formats (e.g. Office files) is still a factor. It was listed in the findings of fact. It will therefore figure into the decision.
Forcing a product to come into existance that wouldn't on its own accord is out of the governments range of punishments. (Office for unix).
However, forcing open specification of the file formats IS within the vein of punishments or degrees. Personally, I still feel that opening up the file formats to a clean specification (so companies like Star Office and Applix and Corel can build interpretors without the bugs of reverse engineering) is more than enough to hurt the Office division. They lose their real monopoly, not on the GUI, but on the files being exchanged.
Why are MP3's so much more widespread over the other compressed music formats (windows, real, etc)? Beause the spec for them is open (protected by patent, but not by copyright). It allowed free programs to be built for the general masses, and commercial products build for better optomizations. For the customer, its "you get what you pay for, but you don't HAVE to pay". The proprietary formats won't allow this. Since the alternative exists, the proprietary forms only survive out of their exclusivity.
Its unfortunate that MS's media actions (all typical MS behavior, with RealNetworks being the target) all happened after the findings of fact. MS is doing the same thing to Real they did to Netscape (give away the products for market share) and it will end up going unnoticed by the decision. So lots of Windows Media stuff is still gonna come out that no Unix (Linux) user can ever see. Windows ME (Media Edition), the next generation of Win98, will have bundled into it file streaming capabilities, which makes Real's for sale server products a moot point.
2 flaws:
1) The OS becomes nice and robust
Well, we know that's never gonna happen. This is STILL Microsoft we're talking about.
2) the compiler company changes the compiler on them
How often (not counting the instability of the moving standard that's been C++ and Java over the last 5-10 years) has changing a compiler really changed your work environment for the worse?
Stick to the ANSI C and ISO C++, and libraries that are either in-house or certified compliant to some acceptable standard (say, POSIX, or the C++ Standard Library), and the compiler is almost a non-issue, save speed and efficiency of optimization and debugging/profiling code, and compilation environment (e.g., IDEs).
BUGS in the compiler, that's different. (e.g., when a bug in EGCS stopped the linux kernel from compiling for a while).
Yes, I know the days when a ton of C++ code suddenly stopped compiling 'cause the complier vendor decided to switch to following the standard and BOOM all of my template based code was _loudly_ broken. but they were things i could fix. they didn't affect my executable once i finished it. they were MY problem, not my customers (save the time delays).
But i've never had a compiler introduce bugs into my final binary code that weren't mine to start with. (If a compiler is THAT broken, it would be out of business REAL fast if the vendor didn't fix it even faster, and its should be easy to go back to the older compiler that worked).
I know its possible, and probably has happened, but not to me.
Bob Cringely has on several occasions described the remedy that would satisfy Stallman's "#1" and perhaps be more damaging in the longer picture...to MS at least.
He believes the only group (the group most ignored by the prosecution and the judge so far) to be split off should be the languages and libraries group. Basically, if Windows (and therefore Internet Explorer) lost the "secretness" of its APIs (including file formats since they're all shared within ms applications), the market would quickly get more competitive.
Not sure I believe him, but its raising a point that most have forgotten. MS is still a languages company. Languages aren't "applications" in the same way that Office products are.
Bypassing the software that has the license agreement dialog violates the DMCA. Posting instructions to do so violate the DMCA (publishing on the web instructions for an illegal activity). Posting links to such violates the DMCA (publishing links to illegal pages).
Those items are worth fighting. The DMCA is excessive in its restrictions to the point that free speech is restricted, violating the constitution.
Slashdot carrying the full text of the document protected by copyright (regardless of either license or "trade secret" status). That has the potential to be illegal under long established (and enforced by the court system) copyright law. That part is where slashdot might not have a leg to stand on.
The compromise will end up being where slashdot removes the verbatim copies of the document, but leaves the "links and instructions" comment postings alone. Besides, by the time a decision is made, MS Kerberos will have gone through its requesite 2 versions, and the working version 3 will be up. This is only "1.0" -- no MS 1.0 works, and we know this.
Of course, each picked their own subset of BSD features to implement...read the unix hater's handbook for some details on the nightmare this created... :)
Sheesh...I'd forgotten 'bout "DECWindows"'s widget from before Motif. The HP/Microsoft side of it (which was the "look" of Motif but not the "feel" which was DEC's) got a lot more publicity...especially with that book that someone from HP published...
but by then Digital cared even less about fixing them then in the DECwindows era
Agreed. Once "OSF" was responsible for maintainance, DEC contributed next to nothing. Same for "OSF-1" (the first 64 bit unix implementation). I wasn't suprised that updates were slow for OSF-1/Digital Unix bugs.
I don't even mind paying for it, but if it comes out of my pocket it had better be affordable.
Agreed^2. $5,000 was a bit much...especially when there were such tight limits on how far we could distribute our bug fixes even after paying that amount. For the most part, when I talked our company into a source license, my main goal was to nail down bugs tight enough to at least have a better shot at a workaround. The licensing couldn't allow much more than that.
For some reason (and this hits a whole can of worms on its own), the larger companies, who seem to have more people available and actively fixing bugs, seem to have the most trouble releasing bug fixes. From Microsoft, through IBM, DEC, OSF etc...finally down to our most recent favs, Netscape (pre AND post AOL). Seems fixing the bugs is never hard, but coordinating bug fixes and new functionality into a "release" is next to impossible...
Bug fixes somehow fail to make the "release", which ends up nothing but a whole new collection of bugs.
I first saw this at IBM with the bug in the assembler's debugging code generator that forced one to acquire a patch to get gcc to work right. The patch was described and available for AIX 3.15. By AIX 4.1, that patch fix had never actually been applied to the principle source tree. One still had to contact IBM and get the patch all over again.
Netscape's 4.x releases have been similar, especially for non-windows boxes. There's the infamous "frames and colors" bug for unix/X, that had been around since frames were first introduced (in 2.0). When the source code (such as it was) was finally released, I seem to recall it was one of the first bugs fixed...only that fixed code (which was something like 5 lines total) never made it to the 4.5x tree, and its presence in Mozilla was removed when the layout engine was rewritten. Meanwhile, netscape 4.72 STILL does funky things with my default color choices as soon as I hit a frames page, the same funky things it did 2 1/2 years ago.
I give up. Time for more beer.
GTK doesn't really seem all that different. I'm trying some GTK in adding a piece to a GTK app, and finding its pretty much all the same as motif so far. The "big look improvements" (skins/themes) are all hidden behind the scenes. Benefits to the end user, but not an API simplicity. Its still "create object, set parameters, create callback, add callback to object, lather, rinse, repeat" ad nauseum for every widget you create. To me (and JWZ's said the same), nothing's different. Yes, it did take a number of years (thanks to OSF's closed source model) for decent "How To Write a Widget for Motif" works came out (O'Reilly's XResource 6 and 10 had the best ones), but otherwise...
The most dramatic change for GUI's to me was Java's Swing, with its plugable models for just about everything (models, renderers, editors, etc...), but then again, I never studied Smalltalk's MVC or what was in Fresco, so i can't comment on what they delivered. Yes, Swing is heavy, but after finally making sense of the renderers and editors and all that, I have great difficulty programming without them.
Motif was also (in my later years of it) made VERY easy with the XMT toolkit from David Flannagan, in what was at the time O'Reilly's "Motif Power Tools", later just X Reference 6C.
It got to the point where I never had to do "XmCreate..." or "XtCreateWidget" again.
Something like that for Java/Swing needs to come in, but Javasoft spent too much time trying to make money for GUI IDE's to do something practical for real programmers.
Ok, i stand corrected 'bout the chip release. I don't recall seeing all that many sub-3000 pc's at the time though. I seem to recall that most of the other pieces (monitor, memory especially, decent disk space) were still prohibitively expensive at the time. A 4 meg, 25mhtz 386 could handle Unix, but I wouldn't trust throwing X on it (much less a memory hog like Motif).
damn...sorry 'bout the html fubar. I'm emailing slashdudes to see if they can fix it.
And no, the 486 was not really out yet. The 25 meg DX one was "introduced" April 10, 1989 (see , but the time between "introduced" and "on sale in most new boxes" is a year or more (as it still is today to some degree). 386's were still expensive boxes, especially if you needed the (then still VERY expensive) memory to really make the chip effective. In 1991, most boxes sold were still 386's, even though the 486 by that point was almost "old technology". The pentium's introduction was March, 1993. Announcents for earlier releases were generally vaporware intended to kill the early clones of the 386.
Also keep in mind general inflation. $3000 then is not $3000 now.
By the time I was working in Motif and getting paid for it, I had already taken to using either Doug Young's C++ framework, or David Flanagan's XMT library (I _really_ wish he'd do something like that for Java/Swing, rather than just the reference rehashes he's been doing for O'Reilly recently...).
HOLD IT!
I would like people to remember the time period of Motif 1.0: 1989. If you had access to a Unix box in 1989, you had a commerical Unix system. Period. End of discussion. You had SunOS, Ultrix, AIX, DGX, Irix, HPUX, SCO or some other System V variant. MAYBE if you were a university you might have a pure BSD box, but those were getting rarer even then. There was no PC capable of handling unix (yes, a 286 could swag Minix, but those were still expensive, and SCO was already pushing their product around for those boxes as a supported solution).
The unix hacking community centered on SunOS at the time. That was it. Since OpenLook sucked (to some hackers), most open source X apps were strictly Athena, or like XV, based on a toolkit written specifically for that application.
If you needed Motif, you bought it (since Solaris didn't support Motif in any official vein until 1993). If you had one of those boxes, you could afford it. Generally, university CS departments and corporations were the only places Unix was found. So generally, if you had a unix box at the time, you could afford the extra few $K for Motif (if it wasn't already there). The idea that every student could have their own Unix-like box was absolutely unheard of. Workstations were $20-150K, and most unix boxes were "mini computers" that still took up the size of 2 refridgerators and needed an air conditioning box of the same size to match (hence the whole idea of X terminals and central servers).
There was no "100% Free" system out there that was reliable or fast enough to bother. Linux is just now getting the kind of attention its getting not because its especially better, but because the platform was suited for (the Intel box) is finally fast enough to handle it.
Motif was a commercial solution to the problem of commercial software vendors, priced at the time when commercial software on unix boxes was expensive. That the prices even recently were as low as $99 for motif (binaries only) was unheard of 7 years ago when I graduated.
Fresco showed that language was very important. C++ didn't have the popularity of C, nor the stability, and certainly not the pre-standard portability. Hard to use a language that's a moving target. By the time C++ achieved a sense of stability (and g++ even more so), Motif had "won the unix desktop" (though CDE would still be 2 years away), and Doug Young's classic text on Motif + C++ had dominated the C++ based GUI development world within X.
I respect what Fresco tried to do, but it was too much for most systems (my 16 meg ultrix box had a hell of a time compiling it) and too much most programmers to deal with at the time, and by the time it would have achieved something, the pressure from MS to "standardize" had locked out all non-Motif solutions until a different audience with a different agenda came along (re: linux, kde, gnome).
Side note: Finding out now that C++/Java programmers are STILL rare in the industry, fewer still appearantly in the Open Source community (how many open source projects use C++? Even with GTK--, I've yet to see a potentially major GNOME component be built in C++).