Also, I have to say that it's pretty shallow to break off a relationship because your partner wants to wait to have sex. It's only one part of a multi-faceted interaction, and you'll do just fine without for a while.
Everybody is entitled to their opinion. But people are in relationships for all sorts of reasons: children, sex, companionship, social expectations, working together, etc. And to many people, the sex is important enough that they would like to test drive before investing a lot of time and effort.
Re:What did they miss about checked exceptions
on
How C# Was Made
·
· Score: 1
The only justification I can possibly see for the C# approach is that so few people really understand exception handling in Java, such as the example you have listed above. You catch the implementation specific exception, add context, and rethrow as an interface specific exception.
Yeah, and what have you gained? Every interface has at least one interface-specific exception, and the IOException that a caller expected is now wrapped up in some obscure wrapper class.
You apparently view software systems as being composed of "upper-level users" and "what is beneath". That's a very procedural world-view. In a procedural world-view, Java's exception handling makes sense.
But for object-oriented programming styles, things don't work that way. In an object-oriented style, when we have method P calling method Q calling method R, then method P may know exactly what exceptions method R may throw, but method Q may be from a completely different library and should not have to know or care about exceptions that propagate from R to P.
Declared exceptions in Java are a testament to procedural thinking; they show that a lot of Java programmers pay lip service to OOP but still just program like they were writing FORTRAN programs.
IOException is something that needs to be checked.
Maybe, maybe not. But checked exceptions make the additional assumption that everybody up the call chain, up to the point where the handler is, actually should be aware of the possibility that that a particular exception can be thrown and should hence declare it.
That's a stupid assumption because there is no reason why it should be satisfied in an object-oriented program. It ends up encoding knowledge about exceptions in places that don't need to know about those exceptions at all, or it forces me to declare new wrapper exception types anywhere where I need to pass those things up.
Checked exceptions were an idiotic design choice. Many other languages had been down that road years before and ended up rejecting checked exceptions because they make no sense.
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...)
It is true that there is more open source server-side web stuff for Java than there is for C#. But, against that, you have to hold that C# actually has a full-featured, high-performance, compatible open source implementation. Also, you can get a full-featured, open-source, widely-used GUI toolkit for C#, namely Gtk#.
And all that open source Java stuff doesn't really matter as long as Sun owns key parts of the platform (e.g., the Swing implementation). Yes, you can exchange open source Java libraries all you want, but Sun has ultimate control.
Each tiny crappy component, each crappy lib for C# out there on the net is sold,
No, it isn't. You are thinking.NET components..NET and C# are two entirely different things. There is a lot of open source C# software out there (check go-mono.com).
What you should really be asking if you are interested in open source is: if I only use open source tools, how do the two software platforms compare? And if you only use open source tools, Java looks like a pretty sad platform: you can choose between Kaffe, orp, and gcj as runtimes, but none of them are anywhere near complete and most open source Java libraries don't run on them. You can't even get a working open source Swing implementation. In comparison, C# is much further along: Mono has a lot of the.NET APIs implemented, and, additionally already has a complete set of open source toolkits and libraries, with APIs that, unlike the Java stuff, are already familiar to existing open source programmers.
You can't hold a patent on something that was a key to the tech boom of 1999-2001, and then show up in 2004 claiming you deserve royalties on it all.
Well, yes, you can. It's entirely legal, and six years is not an unreasonable period for detecting patent infringement and preparing a lawsuit.
There comes a point where if a patent owner doesn't stop the theft of their technology, they forfeit their right to go to the courts...
No, they don't forfeit their right by not prosecuting, even if they were aware of infringement. Their argument to recover past damages may become somewhat weaker, depending on the exact circumstances, but the patent remains valid and fully in force.
For big companies, the current patent system is great: big companies have big patent portfolios that they cross-license. So, they don't generally have to worry about each other. That arrangement keeps new competitors out of the market. And patent application and prosecution costs are high enough that the number of stupid patents filed and prosecuted by small companies are negligible in comparison. Occasionally, something like this slips through. But by and large, stupid patents are filed by the big companies themselves and then cross-licensed in an arrangement that helps big companies.
missing the point, but it doesn't matter
on
How C# Was Made
·
· Score: 5, Informative
I think on many issues, Hejlsberg is missing the point and the reasons he gives aren't necessarily the actual reasons why particular design tradeoffs are good ones.
But it really doesn't matter. The changes that C# made relative to Java are obvious and proven (e.g., value classes, removal of statically checked exception declarations, declared unsafe code sections). Many of them had made Sun's bug parade. All of them had been in other languages before either Java or C#. In fact, C# is, in many ways, close to Modula-3.
There seems to be another reason for some of the design decisions: patents. Sun has patents on several aspects of the JVM and Java, and if Microsoft wanted to be free of potential future claims by Sun, they had to avoid those in their own competing virtual machine.
Keep in mind that Hejlsberg is also a salesperson for the language anyway. That means that he may not be telling you the real reasons behind design decisions, but the reasons that sell the language well.
In any case, however it came into existence, C# is a somewhat better language than Java, and we should be happy about that: whether you are planning on using C# or not, it raises the bar for what is considered standard in industry. Without C#, Sun probably wouldn't even have made the largely cosmetic changes they made to Java in 1.5, and maybe the continued existence of C# will force them to fix other misfeatures of Java and the JVM in future versions. And C# (but not.NET) may turn out to be the free and open language that Java should have been; time will tell.
There would be nothing wrong with an interface that took the font size in pixels or in current units as the "simplified" interface.
So, what shape should a "40 pixel Bodoni font" have? The shape of "Bodoni 12"? The shape of "Bodoni 40"? Should the shape of the font you get change with the resolution of your screen?
Think of the "font size" as a "visual angle" specification. A "Bodoni 12pt" font is actually "Bodoni designed for a viewing angle of 0.95 degree" (12pt at 10"). That's what the "point size" really means--it's not a size, it's a design parameter. The fact that it renders at a size that makes its largest letters approximately (12pt/72 * resolution) is because it has to render at some size, and one might as well pick that one because it's the most natural one.
I am completely pissed off at KDE for obeying the DPI, since the dpi comes up with random values each time I reboot the machine (switching between 75 and 100).
If your hardware is broken, then use the "-dpi" flag to override it in software. It is also correct to use "-dpi" to compensate for non-standard viewing conditions (if you sit very close, lower the dpi, if you sit very far away, increase it).
What should be a minor XFree86 bug is turned into a complete disasterous headache,
Well, gee, if XFree86 changed the color channels around, would that also be a "minor bug"? Would you then insist that we all use black-and-white to avoid turning such a "minor bug" into a "disastrous headache"?
And DPIs aren't there to annoy you, some people really do work on 300dpi monitors with regularity.
They are graphic elements and they should be measured the same.
Quite right: other complex graphic elements, like buttons and scrollbars, should also be parameterized by the viewing angle they are designed for. The fact that they aren't in most toolkits is a problem with the toolkits, not with fonts. That's why most desktop toolkits look awful on handhelds or very high resolution screens.
There is already "nanotechnology" (and "picotechnology") that resists disassembly: compounds that take a long time to break down in the environment, compounds that cause harm to the environment when they break down, etc. You know, things like DDT, plastics, etc. If we can't even manage to get reliable biodegradability into shopping bags or computers, how does anybody expect to get it into nanotechnology?
Fortunately, this particular worry is a marketing gimmick: we are about as likely to be overwhelmed by non-degradable nanomachines as we are to fall into a black hole. We don't need a "center for responsible nanotechnology" because there isn't any nanotechnology and there likely won't be, ever. Unless, of course, you are referring to paint manufacturers and biotechnology companies.
However the interface you are suggesting is the same as if asking for "bold" always returned a font that was 1.2 times taller.
I'm not suggesting an interface at all, I'm simply describing the interface that is there. And, yes, a 12pt bold font may well be slightly taller in terms of pixels than the corresponding 12pt plain font, but it would still be a 12pt font. Point size does not give you the exact size at which a string in a given font will actually render. If you want to render at a precise pixel size, you have to query the font metrics and choose a scale that makes the rendered string exactly the size you want.
My complaint is that in all current systems for screen graphics, the font is selected in a mysterious unit that is different than every other graphic.
Yes, and the reason for that is that something like "a 12 point Bodoni font" has a well-defined meaning: people know what the purpose and the look of that kind of font is going to be. Nobody knows what "a 40 pixel Bodoni font" looks like--it just isn't well defined, because it could have the shape of a 12 point Bodoni font or of a 40 point Bodoni font. The actual shape of the glyphs is only defined in terms of points, i.e., in terms of the size that the corresponding font would have were it printed on paper. Just think of the point size as part of the font name.
So, you have to specify the point size because that determines the shape of the font. And since the point size implies a default pixel size through the known resolution, people figure they might as well make that "natural" size the default rendering size, because that's often the size people want anyway.
You could have another API in which the user always specifies the point size and the pixel size of the rendered string, although most developers would probably find that more cumbersome; the usual way fonts are used is that the rest of the UI accomodates the text, no the other way around. But while that is a valid choice, it just makes no sense to specify only the pixel size because then the shape of the font would depend on the magnification at which you view the document and on the resolution of the output device.
Putting the GPS inside the camera may be neither necessary nor desirable right now. You are probably better off getting a Bluetooth GPS and putting Bluetooth into the camera. That way, you can keep the GPS in your backpack, give it its own big battery, and you can share it with your PDA and mapping software as well. Of course, eventually, GPS becomes small enough that it really doesn't matter.
Note that some cameras already have "built-in GPS", or rather, they have a PCMCIA slot plus the software to drive a GPS that you put into it.
Yes, but against that unjustified negative bias, you have to put the unjustified positive bias, namely that this is something "ground breaking". Altogether, this is a non-story about some nerd at Microsoft doing what other nerds elsewhere have done before. It's neither particularly amazing nor particularly scary.
it breaks new ground in digital photography by combining metadata, like location via GPS, with the image
No, it doesn't. The idea of combining GPS data with photography is about as old as GPS, and as soon as digital cameras started coming out, people started using GPS and digital cameras, as well as putting the information on the web and place it on maps. Please, guys, look around a bit before hyping this sort of thing up.
It's nice that Microsoft is doing this as well, but it really is nothing new.
Nevertheless, I stand by my original comments. Visit the palminfocenter.com forums, and while there are some people experiencing problems like yours, most seem to be getting by fine.
Those are not contradictory. The fact that Palm crashes with regularity does not make it unusable as a PDA, so most people don't bother mentioning it. But if you actually claim that it's a robust, well-designed platform, I have to disagree: technically, both the design of PalmOS and its implementation suck. The only thing that makes a Palm worth buying is its PIM applications, which are mature and the best there is.
Look around on the comments around here, and you'll notice most people are saying things like "it's cool I can do linux-y things on my Zaurus, but my palm still handles PIM functions better"
Of course it does. I have said the same thing. But the reason for that isn't some "Zen of Palm" or some particularly deep insights by the Palm engineering team, it's simply because they have the oldest, most widely-used platform in the market. And, if anything, Palm is standing in the way of progress the same way Microsoft did for years in the desktop space: because they have market dominance and control a few, key applications for the platform, they can get buy releasing buggy, poorly engineered systems. Palm is the Microsoft of the handheld space. They can try to hold on a little longer through dirty tricks (and their continuing refusal to give PalmOS standard APIs really is a dirty trick), but eventually, open source and competition will kill them no matter what they do.
BTW, OS6 is supposed to fix some of those database problems, but I guess we'll see on Monday:)
I seriously doubt it. It's simply not in the genes of either Palm or BeOS; they are thinking along different lines. And their public statements, too, indicate that they simply don't even get what the problem is, let alone know how to solve it.
I don't see why that would help. If you want persistent globals, you can have them right now: copy your "persistent globals" into a database on deactivation and copy them back on activation. The problem is that developers aren't paying attention.
And that's why built-in multitasking makes sense: it ensures that every application can be switched to/from without demanding any extra effort from the programmer. It gives the user more consistency and makes the programmer's life easier. That's what an OS should do.
Others'MMV, but I've owned / used / beaten to near-death 4 different Palms since the III (c.1998) and I can count on my fingers & toes the number of crashes I recall. The preponderance of those are recent*.
My Tungsten T3 crashes and/or hangs with some regularity. The previous T3 (which went back because of a bad digitizer) crashed even more frequently. So did the Sony Clie I had before.
The m500 I was using before that was fairly reliable, as long as I did not install any third party software.
Never have any of them (III, IIIx, IIIxe, Tungsten T) locked up in the middle of doing these things - they've locked up when syncing, when Finding (searching) against "bad apps," when attempting to switch from a live "Arkanoid" game, but never in the middle of real usage.
Well, gee, and those don't count as crashes in your book?
No, entering words in the Date Book usually doesn't cause the Palm to crash, but so what?
*- Also, at least in recent Tungsten memory, when I have reset it, it hasn't lost a damn thing - Not a Note, not a To Do, nor a Calendar entry.
Yes, there I agree: data usually survives crashes intact.
But I have lost lots of data from incompatibilities between different Palms (when migrating) or differing desktop versions. So, back up your data frequently anyway.
Am not a typical Palm user, and often whished for Palm to have multitasking (e.g. I sit in IRC and suddenly need to look up someone's address), but for most Palm users it is not an essential feature.
The consequences are quite visible even to people who don't do that sort of thing. For example, you can't switch apps when certain dialog boxes are up and views change haphazardly when you go from one application to another and back again. Multitasking would solve that. You don't need multitasking to solve that, but since application programmers are obviously incapable of doing it themselves, it seems like the only solution.
PalmOS is for palm-sized devices (e.g. ORGANIZERS) that have very little flexibility as far as data loss, convenience, and user-friendliness. No user wants to open up a console and mess with XF86 settings to try and get their organizer working right in the middle of a meeting.
I have a Palm (a T3 if you must know). It crashes with regularity, it hangs with regularity, it has weird "breathing spaces", where it doesn't respond for a few seconds. When migrating between different versions, I have lost data (all the birthdays went away going from one Palm to another) because Palm's database design sucks. Don't give us this b.s. that the Palm "just works". It doesn't. PalmOS can be a royal pain and require hours of fiddling.
And stop trying to assassinate Linux by raising the dreaded "messing with XF86 settings" issue. If you buy an organizer running X11, it graphics system just runs, there is nothing to "mess" with. People "mess" with Linux and XF86 settings when they are trying to install it on hardware that the manufacturer doesn't support it on; that's not a design flaw with XF86, it's a testament to its flexibility and openness that you can do that with it.
So, if it is such a pain, why am I using a Palm? Because its PIM applications are fairly usable, because the file and communications formats are open and documented, because the devices are pretty small, and because they are comparatively cheap. In part, that's because the platform is so old, and in part it's because the platform is so dominant. If someone gave me an X11-based PDA with Palm-like applications, I'd take it in a minute and I'd know already that it would require less "messing with" and crash far less than Palm.
But the notion that PalmOS is a well-designed or stable OS, or that the Palm developers have some special touch ("The Zen of Palm") is ludicrous.
is that user requirements for an organizer is significantly different from a computer. Users expect it to work just as well as their wristwatch
Yes, and I'm still waiting for a PDA for which that is true. Palm, at least, is moving further and further away from that goal. Maybe a Linux PDA will be able to deliver this.
I'm confused why you think your pseudocode is doing what I want.
I have no idea what you want. You started off with statements like these:
I have no idea why X, Microsoft, and you all seem to think points are important, especially when every other graphics call measures stuff in pixels.
All modern font rendering systems render those two fonts exactly the same. Check the source code for FreeType if you don't believe me.
I think we have established now that a single TrueType fonts can have different shapes depending on the point size it is rendered at, so that simply scaling one to match the size of the other will not give you the same thing. That's all I'm saying.
How you choose to parameterize it is up to you. Suffice it to say that the current parameterization (select font in point size, then use geometric transformations for rescaling) seems completely natural to most experienced developers of graphics software.
Yes I read it. It talks almost entirely about changing letter shapes for rasterization, though it does mention the type of scaling you are talking about, calling it "Optical scaling".
Good. That's all this discussion has been about as far as I'm concerned.
All the other stuff you throw at me now has nothing to do with your original statement.
Palm OS is the OS for low-end devices with simple functions which do not require the headache of viruses/spyware/BSOD etc, and which do simple monotasking applications on budget ram and flash and no MMU.
Well, since even the low-end Zire has 8M of RAM and a 126MHz ARM processor--more powerful than desktop workstations of maybe ten years ago--obviously, that makes it "the OS" for absolutely nothing anymore.
PalmOS regularly BSODs anyway, and the only reason it doesn't have viruses or spyware is because it is nearly incapable of downloading anything from the network even if it is connected. But since people do want to download things, that will come.
Palm will then have to rely solely on their lower end OS on even smaller devices.
I doubt it: technically, it's just not up to it, and there are better choices for small-device operating systems anyway.
I think Palm should try to remain as simple as PalmOS 3.5 or 4.0 and instead focus more on applications.
Strange as it may seem, building better applications depends on having a better OS. Right now, Palm applications are each trying to reinvent more and more of what should be in the OS in the first place. That's what we have operating systems for: to standardize functionality and support application programming.
If all I need is just a PIM (calendaring, contacts, notes, money, short messages), then what would be the reason to choose PalmOS vs Linux on PDA?
Well, those applications are what Palm does well (if you define "well" as "doing better than the competition"). And it's pretty much the only thing it does well. So, if that's what you want, hold your nose and get yourself a Palm. That's what I did. The Palm will crash/hang with regularity, but you won't lose data.
The Zaurus (I have one) isn't good for PIM functionality, in my experience, and the GUI is iffy as well. And it doesn't look like Sharp or TrollTech are capable of fixing the GUI problems it has. So, unless you really need Linux in a PDA form factor for some other reason, don't bother.
What we need is a Linux-based PDA with Palm-like applications. But nobody is offering that.
Basically it's the transition to a real protected-memory OS, requiring a new underlying system architecture.
How "real" of an OS PalmOS 6 ends up being remains to be seen. From what I have heard so far, it still falls short in many areas. Unfortunately, it looks like Palm is going to try to prolong the pain by giving us multiple, wildly incompatible upgrades before reaching some reasonable, stable point.
TrueType fonts can contain fairly general scaling instructions, to move pixels around as well as to achieve better apearance at different sizes. Therefore, you simply cannot use the font size parameters to achieve physical scaling. But all common graphics APIs now give you simple physical scaling (for fonts or anything else) through transformation parameters in addition to the font size parameter.
Many TrueType fonts (including all the "standard" Microsoft ones, AFAIK) only use TrueType to push pixels around a little. But some fonts do more more work (a good Bodoni implementation should).
I would agree with you if you could point out a system where the following is true:
You can implement such an API on top of PostScript, Java2D, RENDER, and MacOS X, if you must. You can probably implement with the new GDI, although I don't know that very well.
In pseudocode, minus your newly added and unnecessary complications, it looks something like:
where was the demand for autoboxing and generics before C# (quite publically) had it? I certainly don't recall hearing about them except on language lawyer mailing lists
I see. So, you think it just doesn't matter what the language experts say.
--meaning that the market wasn't howling for them.
And that surprises you? Do you think that the market is composed of language experts who know exactly what features they need and want? Well, gee, then VisualBasic must be a brilliant language design because the market kept buying it, too. Why, then, did we even need Java?
How would implementing those things create an industry that would keep Java momentum up?
I dunno. Why would I care? Microsoft Windows and VisualBasic had a lot of "momentum" and was enormously successful in the market. Why didn't you jump on that bandwagon yourself if you care so much about "momentum"?
"Momentum" is neutral. It can be used to move forward a technically good platform or a technically bad platform. When a language like Java loses its way, as I think it has, then "momentum" behind it amounts to "stagnation".
For all of the mixed blessing that J2EE is, you must admit that, it having been the focus of Java development for the last few years, has kept Java moving at the front of the market, which is what keeps it alive long enough to evolve as a language.
I disagree. I think J2EE has undermined what originally was at least a sensible goal. Java's distinguishing design goals are 100% binary cross-platform compatibility and the ability to sandbox untrusted code. But those goals simply are not key features for server-side applications: recompiling a server side application for a different platform is no big deal, and server side application frameworks generally do not run untrusted code.
J2EE may have been a smart business move for Sun, but Java is technically the wrong platform to support it. And the stuff Sun originally promised and that propelled Java to its initial success, web delivery of applications and thin clients, basically has withered on the vine, not because it wouldn't be tremendously useful, but because Sun couldn't figure out how to make money with it.
Okay, I didn't realize that you have such a hate-on for Java,
Typical: pretend that criticism is irrational hatred. Unfortunately, most of the response from Java advocates these days seems to reduce to such emotional button-pushing. Sad, but there is no technology or even strategy in the Java community anymore--just a "milk it for all its worth" and "anti-Microsoft is automatically good for everybody else" kind of attitude.
Slashdot Mirror
Also, I have to say that it's pretty shallow to break off a relationship because your partner wants to wait to have sex. It's only one part of a multi-faceted interaction, and you'll do just fine without for a while.
Everybody is entitled to their opinion. But people are in relationships for all sorts of reasons: children, sex, companionship, social expectations, working together, etc. And to many people, the sex is important enough that they would like to test drive before investing a lot of time and effort.
The only justification I can possibly see for the C# approach is that so few people really understand exception handling in Java, such as the example you have listed above. You catch the implementation specific exception, add context, and rethrow as an interface specific exception.
Yeah, and what have you gained? Every interface has at least one interface-specific exception, and the IOException that a caller expected is now wrapped up in some obscure wrapper class.
Wow, someone who understands exceptions.
Too bad he doesn't understand OOP.
You apparently view software systems as being composed of "upper-level users" and "what is beneath". That's a very procedural world-view. In a procedural world-view, Java's exception handling makes sense.
But for object-oriented programming styles, things don't work that way. In an object-oriented style, when we have method P calling method Q calling method R, then method P may know exactly what exceptions method R may throw, but method Q may be from a completely different library and should not have to know or care about exceptions that propagate from R to P.
Declared exceptions in Java are a testament to procedural thinking; they show that a lot of Java programmers pay lip service to OOP but still just program like they were writing FORTRAN programs.
IOException is something that needs to be checked.
Maybe, maybe not. But checked exceptions make the additional assumption that everybody up the call chain, up to the point where the handler is, actually should be aware of the possibility that that a particular exception can be thrown and should hence declare it.
That's a stupid assumption because there is no reason why it should be satisfied in an object-oriented program. It ends up encoding knowledge about exceptions in places that don't need to know about those exceptions at all, or it forces me to declare new wrapper exception types anywhere where I need to pass those things up.
Checked exceptions were an idiotic design choice. Many other languages had been down that road years before and ended up rejecting checked exceptions because they make no sense.
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...)
.NET components. .NET and C# are two entirely different things. There is a lot of open source C# software out there (check go-mono.com).
.NET APIs implemented, and, additionally already has a complete set of open source toolkits and libraries, with APIs that, unlike the Java stuff, are already familiar to existing open source programmers.
It is true that there is more open source server-side web stuff for Java than there is for C#. But, against that, you have to hold that C# actually has a full-featured, high-performance, compatible open source implementation. Also, you can get a full-featured, open-source, widely-used GUI toolkit for C#, namely Gtk#.
And all that open source Java stuff doesn't really matter as long as Sun owns key parts of the platform (e.g., the Swing implementation). Yes, you can exchange open source Java libraries all you want, but Sun has ultimate control.
Each tiny crappy component, each crappy lib for C# out there on the net is sold,
No, it isn't. You are thinking
What you should really be asking if you are interested in open source is: if I only use open source tools, how do the two software platforms compare? And if you only use open source tools, Java looks like a pretty sad platform: you can choose between Kaffe, orp, and gcj as runtimes, but none of them are anywhere near complete and most open source Java libraries don't run on them. You can't even get a working open source Swing implementation. In comparison, C# is much further along: Mono has a lot of the
You can't hold a patent on something that was a key to the tech boom of 1999-2001, and then show up in 2004 claiming you deserve royalties on it all.
Well, yes, you can. It's entirely legal, and six years is not an unreasonable period for detecting patent infringement and preparing a lawsuit.
There comes a point where if a patent owner doesn't stop the theft of their technology, they forfeit their right to go to the courts...
No, they don't forfeit their right by not prosecuting, even if they were aware of infringement. Their argument to recover past damages may become somewhat weaker, depending on the exact circumstances, but the patent remains valid and fully in force.
For big companies, the current patent system is great: big companies have big patent portfolios that they cross-license. So, they don't generally have to worry about each other. That arrangement keeps new competitors out of the market. And patent application and prosecution costs are high enough that the number of stupid patents filed and prosecuted by small companies are negligible in comparison. Occasionally, something like this slips through. But by and large, stupid patents are filed by the big companies themselves and then cross-licensed in an arrangement that helps big companies.
I think on many issues, Hejlsberg is missing the point and the reasons he gives aren't necessarily the actual reasons why particular design tradeoffs are good ones.
.NET) may turn out to be the free and open language that Java should have been; time will tell.
But it really doesn't matter. The changes that C# made relative to Java are obvious and proven (e.g., value classes, removal of statically checked exception declarations, declared unsafe code sections). Many of them had made Sun's bug parade. All of them had been in other languages before either Java or C#. In fact, C# is, in many ways, close to Modula-3.
There seems to be another reason for some of the design decisions: patents. Sun has patents on several aspects of the JVM and Java, and if Microsoft wanted to be free of potential future claims by Sun, they had to avoid those in their own competing virtual machine.
Keep in mind that Hejlsberg is also a salesperson for the language anyway. That means that he may not be telling you the real reasons behind design decisions, but the reasons that sell the language well.
In any case, however it came into existence, C# is a somewhat better language than Java, and we should be happy about that: whether you are planning on using C# or not, it raises the bar for what is considered standard in industry. Without C#, Sun probably wouldn't even have made the largely cosmetic changes they made to Java in 1.5, and maybe the continued existence of C# will force them to fix other misfeatures of Java and the JVM in future versions. And C# (but not
There would be nothing wrong with an interface that took the font size in pixels or in current units as the "simplified" interface.
So, what shape should a "40 pixel Bodoni font" have? The shape of "Bodoni 12"? The shape of "Bodoni 40"? Should the shape of the font you get change with the resolution of your screen?
Think of the "font size" as a "visual angle" specification. A "Bodoni 12pt" font is actually "Bodoni designed for a viewing angle of 0.95 degree" (12pt at 10"). That's what the "point size" really means--it's not a size, it's a design parameter. The fact that it renders at a size that makes its largest letters approximately (12pt/72 * resolution) is because it has to render at some size, and one might as well pick that one because it's the most natural one.
I am completely pissed off at KDE for obeying the DPI, since the dpi comes up with random values each time I reboot the machine (switching between 75 and 100).
If your hardware is broken, then use the "-dpi" flag to override it in software. It is also correct to use "-dpi" to compensate for non-standard viewing conditions (if you sit very close, lower the dpi, if you sit very far away, increase it).
What should be a minor XFree86 bug is turned into a complete disasterous headache,
Well, gee, if XFree86 changed the color channels around, would that also be a "minor bug"? Would you then insist that we all use black-and-white to avoid turning such a "minor bug" into a "disastrous headache"?
And DPIs aren't there to annoy you, some people really do work on 300dpi monitors with regularity.
They are graphic elements and they should be measured the same.
Quite right: other complex graphic elements, like buttons and scrollbars, should also be parameterized by the viewing angle they are designed for. The fact that they aren't in most toolkits is a problem with the toolkits, not with fonts. That's why most desktop toolkits look awful on handhelds or very high resolution screens.
There is already "nanotechnology" (and "picotechnology") that resists disassembly: compounds that take a long time to break down in the environment, compounds that cause harm to the environment when they break down, etc. You know, things like DDT, plastics, etc. If we can't even manage to get reliable biodegradability into shopping bags or computers, how does anybody expect to get it into nanotechnology?
Fortunately, this particular worry is a marketing gimmick: we are about as likely to be overwhelmed by non-degradable nanomachines as we are to fall into a black hole. We don't need a "center for responsible nanotechnology" because there isn't any nanotechnology and there likely won't be, ever. Unless, of course, you are referring to paint manufacturers and biotechnology companies.
However the interface you are suggesting is the same as if asking for "bold" always returned a font that was 1.2 times taller.
I'm not suggesting an interface at all, I'm simply describing the interface that is there. And, yes, a 12pt bold font may well be slightly taller in terms of pixels than the corresponding 12pt plain font, but it would still be a 12pt font. Point size does not give you the exact size at which a string in a given font will actually render. If you want to render at a precise pixel size, you have to query the font metrics and choose a scale that makes the rendered string exactly the size you want.
My complaint is that in all current systems for screen graphics, the font is selected in a mysterious unit that is different than every other graphic.
Yes, and the reason for that is that something like "a 12 point Bodoni font" has a well-defined meaning: people know what the purpose and the look of that kind of font is going to be. Nobody knows what "a 40 pixel Bodoni font" looks like--it just isn't well defined, because it could have the shape of a 12 point Bodoni font or of a 40 point Bodoni font. The actual shape of the glyphs is only defined in terms of points, i.e., in terms of the size that the corresponding font would have were it printed on paper. Just think of the point size as part of the font name.
So, you have to specify the point size because that determines the shape of the font. And since the point size implies a default pixel size through the known resolution, people figure they might as well make that "natural" size the default rendering size, because that's often the size people want anyway.
You could have another API in which the user always specifies the point size and the pixel size of the rendered string, although most developers would probably find that more cumbersome; the usual way fonts are used is that the rest of the UI accomodates the text, no the other way around. But while that is a valid choice, it just makes no sense to specify only the pixel size because then the shape of the font would depend on the magnification at which you view the document and on the resolution of the output device.
Putting the GPS inside the camera may be neither necessary nor desirable right now. You are probably better off getting a Bluetooth GPS and putting Bluetooth into the camera. That way, you can keep the GPS in your backpack, give it its own big battery, and you can share it with your PDA and mapping software as well. Of course, eventually, GPS becomes small enough that it really doesn't matter.
Note that some cameras already have "built-in GPS", or rather, they have a PCMCIA slot plus the software to drive a GPS that you put into it.
Yes, but against that unjustified negative bias, you have to put the unjustified positive bias, namely that this is something "ground breaking". Altogether, this is a non-story about some nerd at Microsoft doing what other nerds elsewhere have done before. It's neither particularly amazing nor particularly scary.
it breaks new ground in digital photography by combining metadata, like location via GPS, with the image
No, it doesn't. The idea of combining GPS data with photography is about as old as GPS, and as soon as digital cameras started coming out, people started using GPS and digital cameras, as well as putting the information on the web and place it on maps. Please, guys, look around a bit before hyping this sort of thing up.
It's nice that Microsoft is doing this as well, but it really is nothing new.
Nevertheless, I stand by my original comments. Visit the palminfocenter.com forums, and while there are some people experiencing problems like yours, most seem to be getting by fine.
:)
Those are not contradictory. The fact that Palm crashes with regularity does not make it unusable as a PDA, so most people don't bother mentioning it. But if you actually claim that it's a robust, well-designed platform, I have to disagree: technically, both the design of PalmOS and its implementation suck. The only thing that makes a Palm worth buying is its PIM applications, which are mature and the best there is.
Look around on the comments around here, and you'll notice most people are saying things like "it's cool I can do linux-y things on my Zaurus, but my palm still handles PIM functions better"
Of course it does. I have said the same thing. But the reason for that isn't some "Zen of Palm" or some particularly deep insights by the Palm engineering team, it's simply because they have the oldest, most widely-used platform in the market. And, if anything, Palm is standing in the way of progress the same way Microsoft did for years in the desktop space: because they have market dominance and control a few, key applications for the platform, they can get buy releasing buggy, poorly engineered systems. Palm is the Microsoft of the handheld space. They can try to hold on a little longer through dirty tricks (and their continuing refusal to give PalmOS standard APIs really is a dirty trick), but eventually, open source and competition will kill them no matter what they do.
BTW, OS6 is supposed to fix some of those database problems, but I guess we'll see on Monday
I seriously doubt it. It's simply not in the genes of either Palm or BeOS; they are thinking along different lines. And their public statements, too, indicate that they simply don't even get what the problem is, let alone know how to solve it.
I don't see why that would help. If you want persistent globals, you can have them right now: copy your "persistent globals" into a database on deactivation and copy them back on activation. The problem is that developers aren't paying attention.
And that's why built-in multitasking makes sense: it ensures that every application can be switched to/from without demanding any extra effort from the programmer. It gives the user more consistency and makes the programmer's life easier. That's what an OS should do.
Others'MMV, but I've owned / used / beaten to near-death 4 different Palms since the III (c.1998) and I can count on my fingers & toes the number of crashes I recall. The preponderance of those are recent*.
My Tungsten T3 crashes and/or hangs with some regularity. The previous T3 (which went back because of a bad digitizer) crashed even more frequently. So did the Sony Clie I had before.
The m500 I was using before that was fairly reliable, as long as I did not install any third party software.
Never have any of them (III, IIIx, IIIxe, Tungsten T) locked up in the middle of doing these things - they've locked up when syncing, when Finding (searching) against "bad apps," when attempting to switch from a live "Arkanoid" game, but never in the middle of real usage.
Well, gee, and those don't count as crashes in your book?
No, entering words in the Date Book usually doesn't cause the Palm to crash, but so what?
*- Also, at least in recent Tungsten memory, when I have reset it, it hasn't lost a damn thing - Not a Note, not a To Do, nor a Calendar entry.
Yes, there I agree: data usually survives crashes intact.
But I have lost lots of data from incompatibilities between different Palms (when migrating) or differing desktop versions. So, back up your data frequently anyway.
Am not a typical Palm user, and often whished for Palm to have multitasking (e.g. I sit in IRC and suddenly need to look up someone's address), but for most Palm users it is not an essential feature.
The consequences are quite visible even to people who don't do that sort of thing. For example, you can't switch apps when certain dialog boxes are up and views change haphazardly when you go from one application to another and back again. Multitasking would solve that. You don't need multitasking to solve that, but since application programmers are obviously incapable of doing it themselves, it seems like the only solution.
PalmOS is for palm-sized devices (e.g. ORGANIZERS) that have very little flexibility as far as data loss, convenience, and user-friendliness. No user wants to open up a console and mess with XF86 settings to try and get their organizer working right in the middle of a meeting.
I have a Palm (a T3 if you must know). It crashes with regularity, it hangs with regularity, it has weird "breathing spaces", where it doesn't respond for a few seconds. When migrating between different versions, I have lost data (all the birthdays went away going from one Palm to another) because Palm's database design sucks. Don't give us this b.s. that the Palm "just works". It doesn't. PalmOS can be a royal pain and require hours of fiddling.
And stop trying to assassinate Linux by raising the dreaded "messing with XF86 settings" issue. If you buy an organizer running X11, it graphics system just runs, there is nothing to "mess" with. People "mess" with Linux and XF86 settings when they are trying to install it on hardware that the manufacturer doesn't support it on; that's not a design flaw with XF86, it's a testament to its flexibility and openness that you can do that with it.
So, if it is such a pain, why am I using a Palm? Because its PIM applications are fairly usable, because the file and communications formats are open and documented, because the devices are pretty small, and because they are comparatively cheap. In part, that's because the platform is so old, and in part it's because the platform is so dominant. If someone gave me an X11-based PDA with Palm-like applications, I'd take it in a minute and I'd know already that it would require less "messing with" and crash far less than Palm.
But the notion that PalmOS is a well-designed or stable OS, or that the Palm developers have some special touch ("The Zen of Palm") is ludicrous.
is that user requirements for an organizer is significantly different from a computer. Users expect it to work just as well as their wristwatch
Yes, and I'm still waiting for a PDA for which that is true. Palm, at least, is moving further and further away from that goal. Maybe a Linux PDA will be able to deliver this.
I have no idea what you want. You started off with statements like these:
I think we have established now that a single TrueType fonts can have different shapes depending on the point size it is rendered at, so that simply scaling one to match the size of the other will not give you the same thing. That's all I'm saying.
How you choose to parameterize it is up to you. Suffice it to say that the current parameterization (select font in point size, then use geometric transformations for rescaling) seems completely natural to most experienced developers of graphics software.
Yes I read it. It talks almost entirely about changing letter shapes for rasterization, though it does mention the type of scaling you are talking about, calling it "Optical scaling".
Good. That's all this discussion has been about as far as I'm concerned.
All the other stuff you throw at me now has nothing to do with your original statement.
Palm OS is the OS for low-end devices with simple functions which do not require the headache of viruses/spyware/BSOD etc, and which do simple monotasking applications on budget ram and flash and no MMU.
Well, since even the low-end Zire has 8M of RAM and a 126MHz ARM processor--more powerful than desktop workstations of maybe ten years ago--obviously, that makes it "the OS" for absolutely nothing anymore.
PalmOS regularly BSODs anyway, and the only reason it doesn't have viruses or spyware is because it is nearly incapable of downloading anything from the network even if it is connected. But since people do want to download things, that will come.
Palm will then have to rely solely on their lower end OS on even smaller devices.
I doubt it: technically, it's just not up to it, and there are better choices for small-device operating systems anyway.
I think Palm should try to remain as simple as PalmOS 3.5 or 4.0 and instead focus more on applications.
Strange as it may seem, building better applications depends on having a better OS. Right now, Palm applications are each trying to reinvent more and more of what should be in the OS in the first place. That's what we have operating systems for: to standardize functionality and support application programming.
If all I need is just a PIM (calendaring, contacts, notes, money, short messages), then what would be the reason to choose PalmOS vs Linux on PDA?
Well, those applications are what Palm does well (if you define "well" as "doing better than the competition"). And it's pretty much the only thing it does well. So, if that's what you want, hold your nose and get yourself a Palm. That's what I did. The Palm will crash/hang with regularity, but you won't lose data.
The Zaurus (I have one) isn't good for PIM functionality, in my experience, and the GUI is iffy as well. And it doesn't look like Sharp or TrollTech are capable of fixing the GUI problems it has. So, unless you really need Linux in a PDA form factor for some other reason, don't bother.
What we need is a Linux-based PDA with Palm-like applications. But nobody is offering that.
Basically it's the transition to a real protected-memory OS, requiring a new underlying system architecture.
How "real" of an OS PalmOS 6 ends up being remains to be seen. From what I have heard so far, it still falls short in many areas. Unfortunately, it looks like Palm is going to try to prolong the pain by giving us multiple, wildly incompatible upgrades before reaching some reasonable, stable point.
Well, that's another misconception you have.
I agree that a perception-based font renderer that changes the shapes based on physical size is a good idea, but none of the systems do this.
I can only say it again: read the Microsoft page.
TrueType fonts can contain fairly general scaling instructions, to move pixels around as well as to achieve better apearance at different sizes. Therefore, you simply cannot use the font size parameters to achieve physical scaling. But all common graphics APIs now give you simple physical scaling (for fonts or anything else) through transformation parameters in addition to the font size parameter.
Many TrueType fonts (including all the "standard" Microsoft ones, AFAIK) only use TrueType to push pixels around a little. But some fonts do more more work (a good Bodoni implementation should).
I would agree with you if you could point out a system where the following is true:
You can implement such an API on top of PostScript, Java2D, RENDER, and MacOS X, if you must. You can probably implement with the new GDI, although I don't know that very well.
In pseudocode, minus your newly added and unnecessary complications, it looks something like:Depending on the font design, changing fontsize_in_points may or may not affect the appearance of the glyphs on screen.
where was the demand for autoboxing and generics before C# (quite publically) had it? I certainly don't recall hearing about them except on language lawyer mailing lists
I see. So, you think it just doesn't matter what the language experts say.
--meaning that the market wasn't howling for them.
And that surprises you? Do you think that the market is composed of language experts who know exactly what features they need and want? Well, gee, then VisualBasic must be a brilliant language design because the market kept buying it, too. Why, then, did we even need Java?
How would implementing those things create an industry that would keep Java momentum up?
I dunno. Why would I care? Microsoft Windows and VisualBasic had a lot of "momentum" and was enormously successful in the market. Why didn't you jump on that bandwagon yourself if you care so much about "momentum"?
"Momentum" is neutral. It can be used to move forward a technically good platform or a technically bad platform. When a language like Java loses its way, as I think it has, then "momentum" behind it amounts to "stagnation".
For all of the mixed blessing that J2EE is, you must admit that, it having been the focus of Java development for the last few years, has kept Java moving at the front of the market, which is what keeps it alive long enough to evolve as a language.
I disagree. I think J2EE has undermined what originally was at least a sensible goal. Java's distinguishing design goals are 100% binary cross-platform compatibility and the ability to sandbox untrusted code. But those goals simply are not key features for server-side applications: recompiling a server side application for a different platform is no big deal, and server side application frameworks generally do not run untrusted code.
J2EE may have been a smart business move for Sun, but Java is technically the wrong platform to support it. And the stuff Sun originally promised and that propelled Java to its initial success, web delivery of applications and thin clients, basically has withered on the vine, not because it wouldn't be tremendously useful, but because Sun couldn't figure out how to make money with it.
Okay, I didn't realize that you have such a hate-on for Java,
Typical: pretend that criticism is irrational hatred. Unfortunately, most of the response from Java advocates these days seems to reduce to such emotional button-pushing. Sad, but there is no technology or even strategy in the Java community anymore--just a "milk it for all its worth" and "anti-Microsoft is automatically good for everybody else" kind of attitude.