In literature (and in the vernacular), a day is simply some more-or-less arbitrary unit of time:
"In my day,...." and so forth.
The question is whether you accept scripture as being written (and translated) as literature or as, shoot, I don't know, maybe as God's scientific experimental log or something.
I don't particularly find any benefit in the infallibility argument. God may be infallible, but if He is going to communicate with us, He has to communicate with particularly fallible humans. That necessitates (in the scriptural criticism sense, as well is in the logical senses) written scriptures that will be interpreted incorrectly by some sincere interpreters. Which, if I accept the existence of God as fact leads me to either declare God is the devil, or to decide I have to ask God what he meant. (Thus, prayer.)
The devil, of course, wants me to believe He is God.
I have USB2 drives and my Mac Mini has USB2 ports. But my keyboard kills the speed of the USB ports. Makes it a pain to move large files to USB drives.
Yeah, yeah, you can talk about how the manufacturer is to blame for not have completely separate controllers there.
Better to just keep the pipes separate.
(And, yeah, proposing SCSI as an example for your argument suggests to me that you believe you're happiest when you don't know any better.)
A Mac Mini used as a router, ethernet to the telco's dongle, Firewire to the local network.
It's true that you may be able (with considerable effort and a few choice Japanese and Korean words of incantation) to do that with a USB port, but you can't do it with standard USB.
Stupid Docomo phone that runs Linux, has a cable that can hook to USB, but only allows using the phone as a MODEM if the computer is running MSWindows. A properly implemented firewire connection should allow standard IP over firewire.
The really screwed up formats for saving stuff to the SD card might not be relevant here. But, even though you can mount the SD over the cable, you can only usefully access jpeg files from a Mac or Linux box. I can hexdump the files they save the text in, and see the text, but I'm going to have to do some serious reverse engineering to actually access the text in a useful manner.
The holes in the USB standard are probably more important to manufacturers who think they can make money by limiting functionality than the licensing fees.
Are you guys listening?
Let me say it again: I have a stupid USB capable mobile phone. I could, if I chose to buy MSWindows, use the phone tethered. When I asked the salesman whether I could use it tethered with a Linux box or a Mac he looked at me like I must be crazy for trying to use anything but Microsoft. He said (in Japanese), Don't even think about trying to connect the phone to your Mac via USB for anything but charging the battery. (I could tell he wanted to ask me why I would be carrying a Mac portable around on the train or to work or anywhere I might possibly want to use e-mail, besides a Starbucks, maybe.)
There are holes in the USB standard.
If we buy this shift to USB, we are supporting two known monopolists. And we will lose functionality, one standard at a time.
You, my friend, are a bundle of information expressed physically.
Freedom is not absolute, but then RMS is not talking about absolute freedom, either.
Freedom of information is freedom of ideas, and without freedom of ideas, people are not free. (Whether or not you believe my introductory neo-transcendentalism.)
I've watched managers say essentially the same thing you are saying and proceed to do exactly what you say should be done and end up with a pile of unusable and unused code and a huge pile of bills and no path forward.
That's not a very rewarding end to a project.
Money does not solve every problem. Not even a lot of money and a lot of time.
Yeah, it's open source, but they have to consider their target, and they have to consider that their target has already been hit, and more than once in the closed source world. And they also need to try to figure out why (besides runrev being closed source) runrev hasn't killed MSOffice.
Near as I can tell, Java 7 hasn't addressed the problem that makes the Java implementations of hypercard interpreters founder. (I suppose I might be off-base, but until the Java camp gets past talking about dynamic objects, I can only suppose that things will remain as they are.)
Or maybe a little driving from the sidewalk, if you'll pardon me for taking the metaphor a little too far.
Question one, did you consider Runtime Revolution at any point in your analysis/development? What were the specific reasons for rejecting it?
I am not employed by runrev, I'm not even much of a fan, just a sometimes user. There may be valid reasons for rejecting Runtime Revolution, depending on what you are trying to do. But I strongly urge you and the entire team to be sure you understand what those reasons are, because you are going to be re-inventing a lot of wheels in many more ways than one.
Question two, has technical management clearly understood the issues underlying dynamic objects? Can they write competent, real-time time-line based multi-module code in each of Java, Smalltalk/Squeak, and Objective C? (And Runtime Revolution's implementation of Hypertalk, to be thorough.) Do they know what they (not just the Bulgarian team) are going to fight with when they shift from Squeak's object model to Java's object model? (Delayed reference resolution is not a trivial topic.)
Does everyone on your team understand the implications of Sun's move from Java 5 to Java 7?
There may be much more than sore grapes motivating the disappointment you are hearing expressed from the original team. You're literally trying to move the earth underneath your project. Business manager's instinctive reach for the mainstream or for the "cool" (whichever it might have been) is not a good technical reason for inducing an earthquake in the code base. They have to have more than that, or all the "acceptance" available in business circles really is not good enough reason for this kind of decision. When you let marketing determine the technical directions, you're doing the exact thing that most typically kills projects, and it is exactly what a lot of funding at an inappropriate time tends to do. (I've seen this personally. Watched a decent company bury itself in inappropriate funding.)
Trying to think of examples where this kind of thing succeeded, I can't. When Apple moved from Pascal to C, they were able to keep most of the underlying run-time and most of the documentation. The headers (the machine-readable part of the API) were a mostly mechanical translation from Pascal syntax to C, and that succeeds because Pascal and C are syntactically close. (Closer than C is to Java, really.) That was nothing near the kind of shift going from Smalltalk to Java.
Nevertheless, as you are probably aware, the original Macintosh code base has now been officially abandoned, as has the classic Macintosh UI and API. Apple succeeded with that precisely because they were not just kicking the version numbers up. They maintained compatibility through emulation (expensive, but cheaper than actually trying to maintain it in the API going forward) and they have now jettisoned the emulation. The only connection that remains is some of the user base and some of the engineers, and the name of the Company. You cannot take even a simple application written for Macintosh System 7 and run it on Mac OS 10.5 either under emulation or even by a quick re-compile.
I could go on, but I know I'm not even a passenger in the same car, so I'm kibitzing from way out of context. But I don't think I should just agree with the chorus of, "Forking is part of the reason for open source!" It is true that forking is part of the reason for open source, and, much though you may not want to see it that way, what you are attempting is most definitely a fork by any engineering definition. But forks are a bit beside the point.
If you are satisfied that you have checked all these issues, my comments are unnecessary. I offer them in case you haven't.
You know, Mellon could have funded a Revolution and saved a lot of money.
I think I would assume, however, that they actually considered runrev and had reasons for wanting to depart from the Hypercard legacy.
Why head from Hypercard to Java, I'm not sure. Is Java 7 better at dynamic stuff than Java 5? Or have they discovered that attempts to generalize dynamic linking generally incur huge penalties in both speed and stability?
There's a reason Mac OS X is not written in either Java or Squeak (Smalltalk), you know.
Those who "get" Java definitely seem not to have any antipathy towards it.
Those of us who look at _good_ Java code and can think of ten other ways to do it, most of them more efficient, more explicit, more elegant, more expressive, more maintainable, more manageable, etc., have to fight serious cognitive dissonance every time we use it. The noise can be mentally deafening at times, or can simply cause a headache (or stomachache or other sign of mental distress).
I still don't get Java because every path taken in its design (and I do mean every path) contradicts my instincts. When I'm looking at some code that I have to take from here to there, none of my guesses take me anywhere. Then I go dig up source of something similar to what I'm doing, and it always takes me a few days at minimum to figure out what on earth the authors are doing.
And then there are the projects that have been killed by the penchant of the project managers to get lost in abstraction, primarily because they have the mistaken impression that abstraction will allow them to implement all the features the sales group has been foolish enough to agree to on the schedule the sales group has been silly enough to promise.
In other words, you mention being burned by legitimate bugs. I propose to you that Java is one big design bug from the bottom up.
As long as it doesn't become a monoculture (like Microsoft's stuff) I have no problem with that. All useful tools fail in certain ways. Good tools will be quite useable to those who instinctively understand them. Others may find themselves feeling like a lefthander using a right-handed pair of scissors. It becomes painful after a while.
Slashdot Mirror
In literature (and in the vernacular), a day is simply some more-or-less arbitrary unit of time:
"In my day, ... ." and so forth.
The question is whether you accept scripture as being written (and translated) as literature or as, shoot, I don't know, maybe as God's scientific experimental log or something.
I don't particularly find any benefit in the infallibility argument. God may be infallible, but if He is going to communicate with us, He has to communicate with particularly fallible humans. That necessitates (in the scriptural criticism sense, as well is in the logical senses) written scriptures that will be interpreted incorrectly by some sincere interpreters. Which, if I accept the existence of God as fact leads me to either declare God is the devil, or to decide I have to ask God what he meant. (Thus, prayer.)
The devil, of course, wants me to believe He is God.
And the only cause that is politically useful.
Blind leading the blind.
We are the market. We're getting tired of getting screwed by big manufacturer X.
The original clamshell iBook.
That thing is a pain to load an alternative OS on because of the lack of Firewire.
Just wait.
Will it really work?
do you speak French?
Why don't we have +1 troll mods?
I have USB2 drives and my Mac Mini has USB2 ports. But my keyboard kills the speed of the USB ports. Makes it a pain to move large files to USB drives.
Yeah, yeah, you can talk about how the manufacturer is to blame for not have completely separate controllers there.
Better to just keep the pipes separate.
(And, yeah, proposing SCSI as an example for your argument suggests to me that you believe you're happiest when you don't know any better.)
A Mac Mini used as a router, ethernet to the telco's dongle, Firewire to the local network.
It's true that you may be able (with considerable effort and a few choice Japanese and Korean words of incantation) to do that with a USB port, but you can't do it with standard USB.
Stupid Docomo phone that runs Linux, has a cable that can hook to USB, but only allows using the phone as a MODEM if the computer is running MSWindows. A properly implemented firewire connection should allow standard IP over firewire.
The really screwed up formats for saving stuff to the SD card might not be relevant here. But, even though you can mount the SD over the cable, you can only usefully access jpeg files from a Mac or Linux box. I can hexdump the files they save the text in, and see the text, but I'm going to have to do some serious reverse engineering to actually access the text in a useful manner.
The holes in the USB standard are probably more important to manufacturers who think they can make money by limiting functionality than the licensing fees.
Are you guys listening?
Let me say it again: I have a stupid USB capable mobile phone. I could, if I chose to buy MSWindows, use the phone tethered. When I asked the salesman whether I could use it tethered with a Linux box or a Mac he looked at me like I must be crazy for trying to use anything but Microsoft. He said (in Japanese), Don't even think about trying to connect the phone to your Mac via USB for anything but charging the battery. (I could tell he wanted to ask me why I would be carrying a Mac portable around on the train or to work or anywhere I might possibly want to use e-mail, besides a Starbucks, maybe.)
There are holes in the USB standard.
If we buy this shift to USB, we are supporting two known monopolists. And we will lose functionality, one standard at a time.
I can't imagine the damage universal USB3 would do to the industry.
Cheap computer, three USB ports, hi-speed USB drive, cheap USB keyboard.
Hook the keyboard in and the hi-speed drive runs at low data rates.
Do we really think USB3 will fix this tendency of manufacturers to scrimp just because they can?
Keep the specs, connectors, and cables clean.
I strongly suspect that Jobs is acting on iNTEL orders to push the world to USB.
iNTEL really, really, really, really wants your pipes. All of them.
They want to get the toll and they want to be able to write the rules of the road.
Not while iNTEL owns USB.
USB is good for keyboards and maybe printers.
But iNTEL owns USB and they want to own your pipes. All of them.
Does Apple pay licensing fees for firewire?
But I think this is less about money and more about iNTEL.
iNTEL really, really, really wants to own all your pipes.
Should be modded informative.
Why should you be free?
You, my friend, are a bundle of information expressed physically.
Freedom is not absolute, but then RMS is not talking about absolute freedom, either.
Freedom of information is freedom of ideas, and without freedom of ideas, people are not free. (Whether or not you believe my introductory neo-transcendentalism.)
What can I say?
I've watched managers say essentially the same thing you are saying and proceed to do exactly what you say should be done and end up with a pile of unusable and unused code and a huge pile of bills and no path forward.
That's not a very rewarding end to a project.
Money does not solve every problem. Not even a lot of money and a lot of time.
Yeah, it's open source, but they have to consider their target, and they have to consider that their target has already been hit, and more than once in the closed source world. And they also need to try to figure out why (besides runrev being closed source) runrev hasn't killed MSOffice.
Near as I can tell, Java 7 hasn't addressed the problem that makes the Java implementations of hypercard interpreters founder. (I suppose I might be off-base, but until the Java camp gets past talking about dynamic objects, I can only suppose that things will remain as they are.)
Because of iNTEL?
Because of 10.5?
I am not buying new Apples because of iNTEL. I'd even buy one with AMD, but I'm not funding yet another out-of-control monopolist.
I am not buying 10.5 because they have removed Classic.
Or maybe a little driving from the sidewalk, if you'll pardon me for taking the metaphor a little too far.
Question one, did you consider Runtime Revolution at any point in your analysis/development? What were the specific reasons for rejecting it?
I am not employed by runrev, I'm not even much of a fan, just a sometimes user. There may be valid reasons for rejecting Runtime Revolution, depending on what you are trying to do. But I strongly urge you and the entire team to be sure you understand what those reasons are, because you are going to be re-inventing a lot of wheels in many more ways than one.
Question two, has technical management clearly understood the issues underlying dynamic objects? Can they write competent, real-time time-line based multi-module code in each of Java, Smalltalk/Squeak, and Objective C? (And Runtime Revolution's implementation of Hypertalk, to be thorough.) Do they know what they (not just the Bulgarian team) are going to fight with when they shift from Squeak's object model to Java's object model? (Delayed reference resolution is not a trivial topic.)
Does everyone on your team understand the implications of Sun's move from Java 5 to Java 7?
There may be much more than sore grapes motivating the disappointment you are hearing expressed from the original team. You're literally trying to move the earth underneath your project. Business manager's instinctive reach for the mainstream or for the "cool" (whichever it might have been) is not a good technical reason for inducing an earthquake in the code base. They have to have more than that, or all the "acceptance" available in business circles really is not good enough reason for this kind of decision. When you let marketing determine the technical directions, you're doing the exact thing that most typically kills projects, and it is exactly what a lot of funding at an inappropriate time tends to do. (I've seen this personally. Watched a decent company bury itself in inappropriate funding.)
Trying to think of examples where this kind of thing succeeded, I can't. When Apple moved from Pascal to C, they were able to keep most of the underlying run-time and most of the documentation. The headers (the machine-readable part of the API) were a mostly mechanical translation from Pascal syntax to C, and that succeeds because Pascal and C are syntactically close. (Closer than C is to Java, really.) That was nothing near the kind of shift going from Smalltalk to Java.
Nevertheless, as you are probably aware, the original Macintosh code base has now been officially abandoned, as has the classic Macintosh UI and API. Apple succeeded with that precisely because they were not just kicking the version numbers up. They maintained compatibility through emulation (expensive, but cheaper than actually trying to maintain it in the API going forward) and they have now jettisoned the emulation. The only connection that remains is some of the user base and some of the engineers, and the name of the Company. You cannot take even a simple application written for Macintosh System 7 and run it on Mac OS 10.5 either under emulation or even by a quick re-compile.
I could go on, but I know I'm not even a passenger in the same car, so I'm kibitzing from way out of context. But I don't think I should just agree with the chorus of, "Forking is part of the reason for open source!" It is true that forking is part of the reason for open source, and, much though you may not want to see it that way, what you are attempting is most definitely a fork by any engineering definition. But forks are a bit beside the point.
If you are satisfied that you have checked all these issues, my comments are unnecessary. I offer them in case you haven't.
You know, Mellon could have funded a Revolution and saved a lot of money.
I think I would assume, however, that they actually considered runrev and had reasons for wanting to depart from the Hypercard legacy.
Why head from Hypercard to Java, I'm not sure. Is Java 7 better at dynamic stuff than Java 5? Or have they discovered that attempts to generalize dynamic linking generally incur huge penalties in both speed and stability?
There's a reason Mac OS X is not written in either Java or Squeak (Smalltalk), you know.
It seems like a really brutal way to enforce a fork.
It seems like a slap in the face to the original devs.
And I have seen projects that start with speccing an existing project out in Java turning into deathmarches.
I'd like to see the other side of the story, but not everyone who reads this guy's complaint is automatically thinking he has no valid complaint.
Those who "get" Java definitely seem not to have any antipathy towards it.
Those of us who look at _good_ Java code and can think of ten other ways to do it, most of them more efficient, more explicit, more elegant, more expressive, more maintainable, more manageable, etc., have to fight serious cognitive dissonance every time we use it. The noise can be mentally deafening at times, or can simply cause a headache (or stomachache or other sign of mental distress).
I still don't get Java because every path taken in its design (and I do mean every path) contradicts my instincts. When I'm looking at some code that I have to take from here to there, none of my guesses take me anywhere. Then I go dig up source of something similar to what I'm doing, and it always takes me a few days at minimum to figure out what on earth the authors are doing.
And then there are the projects that have been killed by the penchant of the project managers to get lost in abstraction, primarily because they have the mistaken impression that abstraction will allow them to implement all the features the sales group has been foolish enough to agree to on the schedule the sales group has been silly enough to promise.
In other words, you mention being burned by legitimate bugs. I propose to you that Java is one big design bug from the bottom up.
As long as it doesn't become a monoculture (like Microsoft's stuff) I have no problem with that. All useful tools fail in certain ways. Good tools will be quite useable to those who instinctively understand them. Others may find themselves feeling like a lefthander using a right-handed pair of scissors. It becomes painful after a while.
Get back, troll.