Erik Naggum <e...@naggum.no> writes: > And let's not forget the people who can actually make use of the > specific combination of all of these things -- people have two > nasty habits: (1) they forget, and (2) they die.
I, for one, do not intend to make a habit out of item 2. (although I might be persuaded to try it once....)
> Setting yourself on a single-vendor API with only one implementation, > with no source you may redistribute in an emergency case, is suicide, > time-invenstment wise. I've been programming for long enough to know > this and who the specific vendor in question is couldn't matter less.
> I have no doubt it's more productive than MFC, though...
Well... It seems that the vendor of that particular product is more likelly to die, get splitted, sued to death, etc.. that Xanalys. Throw away those MFC books and get yourself a copy of Lispworks before it's too late! };-D
Now seriously, I got into HUGE trouble be relying in a badly supported propietary product, but I still think that going open source only for everything isn't always practical... :-(
Well, I agree that Open Source solutions don't always fit the bill.
There are some good "free" and Open Source LISP systems, but there is something very satisfying about a commercial, supported LISP environment (I chose LispWorks Professional because of the price, but I think that the Franz system is also great, because I tried their free evaluation versions for Windows and Linux). Anyway, everytime I try to do something new with LispWorks (e.g., CAPI, multi-threading, socket programming, etc.) and life is easy, it is a very satisfying feeling!
BTW, I work for an AI company, but we do everything in Java. Even though I wrote a "Java AI" book 5 years ago (and actually, I have another in production), I must say that Java is simply not as good at doing AI-ish things as LISP. There are, certainly, good marketing reasons for using Java :-)
Hopefully, people will realize the tremendous advantages of developing in LISP and continue to support the fine LISP commercial vendors.
Best regards, Mark
In article <393D3B85.ECCFC...@wanadoo.es>, Fernando =?iso-8859-1?Q?Rodr=EDguez?= <f...@wanadoo.es> wrote:
> Well... It seems that the vendor of that particular product is more likelly to die, > get splitted, sued to death, etc.. that Xanalys. Throw away those MFC books and get > yourself a copy of Lispworks before it's too late! };-D
> Now seriously, I got into HUGE trouble be relying in a badly
supported propietary
> product, but I still think that going open source only for
Fernando =?iso-8859-1?Q?Rodr=EDguez?= <f...@wanadoo.es> writes: >Martin Cracauer escribió: >> Setting yourself on a single-vendor API with only one implementation, >> with no source you may redistribute in an emergency case, is suicide, >> time-invenstment wise. I've been programming for long enough to know >> this and who the specific vendor in question is couldn't matter less.
>> I have no doubt it's more productive than MFC, though...
>Well... It seems that the vendor of that particular product is more likelly to die, >get splitted, sued to death, etc.. that Xanalys. Throw away those MFC books and get >yourself a copy of Lispworks before it's too late! };-D >Now seriously, I got into HUGE trouble be relying in a badly supported propietary >product, but I still think that going open source only for everything isn't always >practical... :-(
It doesn't have to be open-Source, just a Standard that is implemented by more than one Vendor.
Erik Naggum <e...@naggum.no> writes: >* Martin Cracauer >| And what will you do if the vendors gives up the product, develops the >| product in a direction you don't like (i.e. it becomes unstable), if >| the vendors dies and noone picks up the product, if the vendor simply >| raises the price - maybe even for redistribution of runtimes - or if >| you need to support a platform the vendor does not support? > This has a very simple and obvious answer: You do what you always do > when "the world" dissolves underneath a programmer: You reimplement > your software with the best available tools and people at that time.
Yes, but you can reduce the frequence of being forced to.
Since I'm using... - somewhat Posix 1003.[12] - complaint Unixes - ANSI C 89 - Common Lisp (no GUI programming)
I have a much better time than before with... - DOS ==> Windows 3.0 - moving-target C++ - NeXT - Smalltalk
> It's a strange illusion that just because it's in some "free" form, > it's going to stay useful forever.
The things I listed can also be avoided by a standard that is implemented by several vendors (non-free).
> Operating systems come and go, > languages change and their compilers and development tools with them > -- including such fickle things as the support libraries that change > in subtly incompatible ways all the time.
Yes, this happens all the time and even the Unix platforms I support still do this. Hoever, they do it in ways that are somewhat obvious and can be traced down fast. What counts is that they usually force you to change a simple function call and maybe to all a little bookkeeping stuff.
You don't have to rework major parts of your program design, as you would have to when your Object-Oriented GUI framework goes away.
The same applies for Common Lisp. CMUCL is far from being ANSI CL compliant, but the differences usually require a few #+, not different programming style as it would when CL was a one-Vendor standard only, went away and I would be forced to do Interlisp instead.
> And let's not forget the > people who can actually make use of the specific combination of all > of these things -- people have two nasty habits: (1) they forget, > and (2) they die. All of this happens all of the time -- regardless > of whether you have source code to something. Even the hardware on > which the last system in the world ran will deteriorate and die. > What does using stuff that follows standard buy you? _More_ time, > not eternity, and not even necessarily _much_ time, either. If the > standard is _excellent_ and it's universally adopted by someone who > is not so cavalier about standards as Microsoft, it may buy you a > lot of time, like 15 years. If it's a bad standard, it will also be > improved.
I agree about your scepsis about Standards, in fact Posix 1003.1 and 1003.2 (Unix C interface and Unix shell utils) are quite stupid in a number of ways and the free Unix derivates declared that they will not implement some of the annoying parts.
Still, these Standards raised the livetime of my own code to something I doubt CAPI will have.
> Reimplementing is part of the maintenance costs of a project. > You're a damn fool if you don't calculate it into the price of > something that is going to be in use for a long time. It's very > much like longevity in data storage: If you don't plan to have > someone copy data off of old media onto new media to keep it alive, > possibly converting it in the process, it _will_ wither and die.
Well, I think some of our different opinions are grounded in our past experience. I wasn't programming 15 years ago and I avoid some areas of computing that forces many reimplementations, i.e. I don't do GUI programming escept for some Web applications.
>| Setting yourself on a single-vendor API with only one implementation, >| with no source you may redistribute in an emergency case, is suicide, >| time-invenstment wise. I've been programming for long enough to know >| this and who the specific vendor in question is couldn't matter less. > Then you should also admit that there is _no_ cure.
I do, but the toolchain change I outlined at the beginning of my posting reduced the problem by an order of magnitude.
> Just about > everything is suicide, time-investment-wise: Everything dies in the > end
That can't be proven in the mathematical sense :-)
> and under more miserable conditions the longer it has been kept > alive artificially, I might add. The question is how much time you > lose or fail to lose (but that is not "gain") with each move you > make. There is nothing to indicate that having source code access > buys you any more time than not having source code access does, in > the general case. Specific cases may of course be cited the same > way alternative medicine cites its successes.
Well, I think I have quite a number of such specific cases. I would have lost CMUCL and FreeBSD if I didn't act, and I could only act because I had the source to fix technical or other problems without going as far as working for the vendor.
I think your point bites in a quite different way: if I had more pressure on the "real" projects I did a few years ago and therefore less time to study the tools I use, I wouldn't have been in the position to do something about the tools.
However, now that I already invested the time to be able to act on problems with my tools (by fixing them, not throwing them away), I think I and my employer are both in a good situation, even when time pressure on "real" stuff is acute.
I won't even start how much my programming style and capabilities improved by having my propposed changed stumbled over by experienced people in on OpenSource-Projects. The will and ability for correctness and elegance in some OpenSource projects is much larger than in any commercial environment I know.
* Martin Cracauer | It doesn't have to be open-Source, just a Standard that is | implemented by more than one Vendor.
Why isn't a publicly available specification sufficient? Why does it have to be implemented by more than one vendor? How do you bootstrap this process for new products/ideas?
#:Erik -- If this is not what you expected, please alter your expectations.
Erik Naggum wrote: > Why isn't a publicly available specification sufficient? > Why does it have to be implemented by more than one vendor? > How do you bootstrap this process for new products/ideas?
This hits the nail on the head[1]
;) will
[1] and is a key point made by Rob Pike (see Rob Pike article thread for ref.)
Erik Naggum <e...@naggum.no> writes: >* Martin Cracauer >| It doesn't have to be open-Source, just a Standard that is >| implemented by more than one Vendor. > Why isn't a publicly available specification sufficient?
If complete, it would be. However, when writing code for things like CAPI, more or less of it can only be written down the right way by using other sources than the specification (try'n'error, support calls, reverse engeneering, existing examples).
> Why does it have to be implemented by more than one vendor?
When one dies, you can take your existing source and continue to use it on the other vendor's implementation.
Of course, that's not a general solution, since maybe you're now left with one vendor again, but it helps a lot.
> How do you bootstrap this process for new products/ideas?
The whole point only applies when the new things you want are in your source code, not the APIs you use.
Your point is probably that your can't do really new things in existing frameworks.
On the other hand, when I try to do new things on new platforms/apis/languages, I am usually stopped by problems with the implementation of these new building blocks before the thing I build reaches a state where it is something "new".
I wonder why you prefer using things like existing vendor-specific APIs over doing everything yourself from ground up. It takes time, but so does reimplementing your (direct) project when you are forced to build on new grounds.
* Martin Cracauer | If complete, it would be. However, when writing code for things | like CAPI, more or less of it can only be written down the right way | by using other sources than the specification (try'n'error, support | calls, reverse engeneering, existing examples).
It seems you should retarget your efforts to improve specifications.
| When one dies, you can take your existing source and continue to use | it on the other vendor's implementation.
When a vendor dies, what exactly prevents you from continuing to use the product? It doesn't evaporate. You can call them up and tell them you want to purchase the whole thing for a trifle amount of money. Trust me, this happens _all_ the time when companies fail. It's actually part and parcel of the liquidation process.
| The whole point only applies when the new things you want are in | your source code, not the APIs you use.
That seems awfully irrelevant. Your source code is somebody else's "API" and vice versa.
| Your point is probably that your can't do really new things in | existing frameworks.
Yes, I'm subtly and implicitly criticing you for that position, since what you are saying is fairly hostile to real innovation¹.
| On the other hand, when I try to do new things on new | platforms/apis/languages, I am usually stopped by problems with the | implementation of these new building blocks before the thing I build | reaches a state where it is something "new".
If so, it seems you should retarget your efforts to improve quality in the components you use.
| I wonder why you prefer using things like existing vendor-specific | APIs over doing everything yourself from ground up.
Pardon me? When and where did I say any such thing? Why the hell do you wonder why? I'm arguing against _your_ position, because I think it lacks all relevant merit.
| It takes time, but so does reimplementing your (direct) project when | you are forced to build on new grounds.
If it takes N amount of time to build on vendor-specific "API"s, it will take M*N amount of time to reimplement it M times. Your argument is that M will be so high that the value of N is immaterial in the equation T < M*N, where T is the time it takes to reinvent the wheel and do it all yourself. I find this a rather curious position, to say the least.
#:Erik ------- ¹ as opposed to Microsoft innovation -- If this is not what you expected, please alter your expectations.
Martin Cracauer wrote: > Setting yourself on a single-vendor API with only one implementation, > with no source you may redistribute in an emergency case, is suicide,
What is your specific suggestion for tools that I should use in my case?
I need to develop a 2-D interactive graphics application (not just GUI, but 2-D graphics) in the least amount of time and fuss (including learning curve, experimentation time, implementation time) that has to run on machines/OS'es constituting a large market.
I am truly interested in good, specific suggestions.
Erik Naggum <e...@naggum.no> writes: >* Martin Cracauer >| Your point is probably that your can't do really new things in >| existing frameworks. > Yes, I'm subtly and implicitly criticing you for that position, > since what you are saying is fairly hostile to real innovation¹. >| On the other hand, when I try to do new things on new >| platforms/apis/languages, I am usually stopped by problems with the >| implementation of these new building blocks before the thing I build >| reaches a state where it is something "new". > If so, it seems you should retarget your efforts to improve quality > in the components you use.
And how do I do it when I can't change them without working full-time for the vendor?
>| I wonder why you prefer using things like existing vendor-specific >| APIs over doing everything yourself from ground up. > Pardon me? When and where did I say any such thing?
Sorry, I should have worded differently: if you want innovation you can't get when working inside existing multi-vendor frameworks, isn't it preferrable to implement a thing like CAPI on your own, basing just on Common Lisp, Posix/Win32 and X11/basic windows draw routines? (Over using existing frameworks you cannot control).
>| It takes time, but so does reimplementing your (direct) project when >| you are forced to build on new grounds. > If it takes N amount of time to build on vendor-specific "API"s, it > will take M*N amount of time to reimplement it M times. Your > argument is that M will be so high that the value of N is immaterial > in the equation T < M*N, where T is the time it takes to reinvent > the wheel and do it all yourself. I find this a rather curious > position, to say the least.
I say that using an existing API (over doing it yourself) saves A time, but it costs B time that it is not specilized for your needs, it costs C time to work around bugs in implementation or documentation, it may cost D time to do something about it when the vendors fails to continue the product in an appropriate manner. And that B + C + D easily > A. And when it it, it often is in annoying quantity, including risks for your own project or company.
Since I started programming professionally (1991), there were few frameworks for which this formular wasn't true. NeXT and the Smalltalks are propably the best examples. The only innovate frameworks that you could continue to use until today are from microsoft... Also, since 1991, most successful things I did were implemented in exsting multi-vendor tools, as success was defined mostly not by innovate features in my products, but people were happy that the things worked at all, had few bugs and were fast.
I don't know how the situation was before 1991 and I could easily believe that customer's expectations were different. But today - from my point of view - most people have so many problems with lack of throughput, bugs, bloat, incompatibilities that they are happy when you do something about these, they don't expect innovative features and they are even so sceptical about them that they refuse offers of them or don't use them when they are available.
That is a bad situation, and there are several ways to approach a solution.
One is to use innovative environments to produce innovate products and hope that the result speaks for itself.
The other is to do the current things right, so that users and customers will be freed of the "doesn't-work-anyway" expectation and will have their head free to even recognize advanced concepts.
I think that the OpenSource community did a lot in the latter regard and that using single-vendors APIs will lead to forced changes in your software that is contrary to it.
Martin Cracauer wrote: > And what will you do if the vendors gives up the product, develops the > product in a direction you don't like (i.e. it becomes unstable), if
Apply effort.
This is the same risk as for the case when the open source community doesn't yet support a device I need, or I find a customer who, for good reasons, insists on using a machine/OS/configuration that I don't yet support.
The trick is to minimize the risk & cost of unexpected new effort. The way to do this is to stop obsessing about code and to start obsessing about blazingly clear architecture.
You can use many methods to make architecture clear:
- choose simple models for aspects of your system (Tcl/TK is simple, CAPI is simpler than CLIM)
- insulate - yeah, I know that CAPI is single-sourced, so I endeavour to scurry away CAPI calls in routines that have expressive sentences as their names
- write application-specific code - it's easier to understand a single clearly-written application (and, therefore to reengineer it and to port it) than it is to understand an abstract class library (this bit of experiential advice should raise some eyebrows :-)
- use tools that cause you not to tangle implementation with architecture; Lisp has a psychological effect on me that almost no other language does - I find it mentally easy to chop applications up into inanely small pieces while not worrying about efficiency (and commercial Lisp compilers give me the warm-and-fuzzies by having good compilers), whereas with C/C++ I can't get my mind out of the micro-efficiency gutter and can't get any useful work done, likewise, with Smalltalk/Eiffel I spend all of my time honing class libraries instead of doing useful work - with C/C++/Smalltalk/Eiffel, the final code is so polluted with implementation & abstraction details that it becomes expensive to consider a rebuild; garbage collection hides a huge amount of non-architectural detail
- use tools that require fewer (clear) lines of code in the implementation (so, even if you blow the architecture, the amount of time to reverse-engineer it is lowered since there's less to read and understand)
- build tools (e.g. small languages (Kernighan, Pike, et al)) that generate parts of your application from tool-independent specifications.
>I need to develop a 2-D interactive graphics application (not just GUI, but 2-D >graphics) in the least amount of time and fuss (including learning curve, >experimentation time, implementation time) that has to run on machines/OS'es >constituting a large market.
>I am truly interested in good, specific suggestions.
It's all a matter of how autonomous (i.e. how much it must interact with other, unspecified applications on the client platform) your application is. If it's fairly autonomous, then something (anything) based on X would probably be your best choice. Every major desktop platform of note can run an X Server.
CAPI is supposed to port between X and windows, I imagine Open Graphics does as well. There's alway the basic CLX stuff.
Seriously, you can write the app on an Intel unix solution, the hardware is dirt cheap, particularly compared to the software, and you can serve several clients from one machine (depending on the application of course). $1000/3 users for hardware, $300 for an X-Server client for their personal machine, and $30,000 per seat for your software! :-)
The machine lives either in a machine room, or under the desk. Hunt down some "embedded" PC options to get nice form factor for your app servers. Cost will go up a little, but the users will appreciate the space saved. Make sure you ship a bootble CD ROM to reload the machines when they explode. Share your files on a NFS or Window/Samba file server. Back up those file servers, not your app servers.
* Erik Naggum | ... it seems you should retarget your efforts to improve quality in | the components you use.
* Martin Cracauer | And how do I do it when I can't change them without working | full-time for the vendor?
You talk to the vendors (plural) that you could purchase something from and choose the one (oh, no! :) that listens to you.
I wonder where the notion that you cannot affect a software product except by tinkering with the source code comes from. It's bogus.
| Sorry, I should have worded differently: if you want innovation you | can't get when working inside existing multi-vendor frameworks, | isn't it preferrable to implement a thing like CAPI on your own, | basing just on Common Lisp, Posix/Win32 and X11/basic windows draw | routines? (Over using existing frameworks you cannot control).
No, I don't think so. I want to be good at what I do, and I have found, after having become good at perhaps 20 different things in as many years, that if I can find somebody else with like attitude, or better yet, a whole bunch of people with like attitude, we don't all have to be good at the _same_ things. Sometimes, I'd like to go to a doctor and say: "Hey, I broke this, can you fix it?" and let him do his work, instead of studying the parts of medicine that I need to fix it and hope I learned it in time not to have done ill worse.
| I say that using an existing API (over doing it yourself) saves A | time, but it costs B time that it is not specilized for your needs, | it costs C time to work around bugs in implementation or | documentation, it may cost D time to do something about it when the | vendors fails to continue the product in an appropriate manner. And | that B + C + D easily > A. And when it it, it often is in annoying | quantity, including risks for your own project or company.
What a sad, paranoid view of the world! Here's a suggestion: Drop the crap you're working on and take a week's vacation right now, during which you ponder seriously whether you ever again want to work with incompetent suppliers. If you conclude that, yes, you want to work with incompetent suppliers, go back to work. If you conclude that, no, you do not ever want to deal with any supplier who is incompetent, buy firearms and ammo and go back to work :) _or_ get a new job. According to the newspapers and the screaming idiots in the IT business, there is a shortage of people who know just about _anything_. (Never mind that there are unemployed IT people, too, we don't want to be honest while marketing, do we? :) If you can't get a new job where you don't have to deal with a lot less incompetent suppliers, do something else that you're good at.
| That is a bad situation, and there are several ways to approach a | solution.
Some situations have only one solution, and it's the opposite of "approach": it's "butt out!". I honestly don't think people should try to solve the problems created by using Microsoft products.
| The other is to do the current things right, so that users and | customers will be freed of the "doesn't-work-anyway" expectation and | will have their head free to even recognize advanced concepts.
I'm worried about your fixation on "advanced concepts" and innovation, so I'm sorry I brought it up to begin with. There's such a mind-numbing lack of competence in any IT field that you don't have to be brilliant to be extraordinary, and you don't have to excel to deliver consistently high quality. People don't do quality work because they can get away with not doing it, and all you need to do is to make sure nobody gets away with around you. I know: I do just this.
| I think that the OpenSource community did a lot in the latter regard | and that using single-vendors APIs will lead to forced changes in | your software that is contrary to it.
Some day, I hope to find out what Open Source _really_ is a solution to. So far, the only thing that really stands out is "at least it's not Microsoft", and I was pleased that Rob Pike seems to have the same insight. I don't think we have solved anything of importance with Open Source, except how to threaten software development in the long term to the point of extinction or utter non-innovation. The sad fact is: people don't contribute for free to anything that they can't charge to a "surplus/luxury account", and in programming, that's what they know _too_ well. Add the pain of solving some really hard stuff to the equation, and a lot fewer people will want to contribute for free. To engage the masses of people that Open Source relies on, you can't _do_ really hard stuff for long. At some point, those who give away will want a return on investment. If they find out that they killed a lot of software companies or blocked a lot of ways to make money by giving too much stuff away, they will turn on Open Source and blame it for the reduction in their options. So Open Source is a luxury phenomenon, to vanish or be sharply reduced when we can no longer afford that luxury.
#:Erik -- If this is not what you expected, please alter your expectations.
Erik Naggum <e...@naggum.no> writes: > * Martin Cracauer > | It doesn't have to be open-Source, just a Standard that is > | implemented by more than one Vendor.
> Why isn't a publicly available specification sufficient?
I think CommonLisp is a good example why this doesn't work for many people. The CommonLisp spec leaves many important areas of the language and the environment unspecified, and writing code (in particular, numerical code) that works efficiently across implementations is hard.
> Why does it have to be implemented by more than one vendor?
Implementations from only a single vendor put customers at the complete mercy of that vendor once they have built a product. The vendor can charge up to the customer's pain threshold, and if they drop the product, the customer is left stranded. Few people who are responsible for a large software development project want to accept that kind of risk, even if the tool is quite a bit better.
> How do you bootstrap this process for new products/ideas?
Well, vendors need to take the concerns of their customers more seriously: many customers don't want to become dependent on a single vendor and simply won't buy.
Open source is a reasonably good way of ensuring that when coming up with a new language. Detailed open specifications also help. Vendors should not put proprietary extensions into their tools without separating them clearly from the core, open specification and giving customers the option of turning them off completely. And building industry support around the language is important as well.
Sun did several of those things with Java, which is why people jumped on it. Critics of Java often seem to assume that people picked it out of ignorance of the alternatives. In my experience, people who helped get Java off the ground and pushed it into the mainstream (at IBM and other places) knew the alternatives full well, but they supported Java because it addressed those practical concerns; often, this meant dropping support for languages they preferred technically.
* tom <tmb at ncal point verio point com x...@x.x> | Implementations from only a single vendor put customers at the | complete mercy of that vendor once they have built a product. The | vendor can charge up to the customer's pain threshold, and if they | drop the product, the customer is left stranded. Few people who are | responsible for a large software development project want to accept | that kind of risk, even if the tool is quite a bit better.
Sounds good! Now explain Microsoft.
#:Erik -- If this is not what you expected, please alter your expectations.
Erik Naggum <e...@naggum.no> writes: > * Martin Cracauer > | And how do I do it when I can't change them without working > | full-time for the vendor?
> You talk to the vendors (plural) that you could purchase something > from and choose the one (oh, no! :) that listens to you.
> I wonder where the notion that you cannot affect a software product > except by tinkering with the source code comes from. It's bogus.
I think the issue of influencing venders of propietary software is more complex than a "yes you can, no you can't". So in short I agree that it's bogus to say that you can't affect a proprietary product.
As a professional programmer, you can influence proprietary products in several ways. Being a customer gives you the vendors ear to some extent, and having direct contact with the engineers working on the product can give you even greater control. If the product is tracking a public standard, then being on the standards commitee helps too. I'm sure we can think of a dozen more ways that require varying levels of time or financial investment.
As a hobbiest, or perhaps a professional programmer with only a minimal amount of capital, many of these mechanisms for influencing proprietary software are not available to you. Your capital is largely limited to your labor power. I would argue that Free Software *usually* presents the most direct translation of labor power into project influence/improvement when it comes to influencing third party projects. This is because your labor power can be directly applied to the project itself, and not have to be translated thru capital.
I qualified that statement with "usually" for a reason. There are various licenses and distribution models which aren't Free Software, but would still provide the benefit of a more direct translation of labor power into project advancement. There are even proprietary vendors who provide the same advantage after the initial outlay of capital for the product license.
In my life as a professional programmer, I look at this as a complication of the "build or buy" question. How much I buy, and how much I build depends on how much capital I have for the project, and how much labor power I can apply to it. The ratio of the two often determines wether I use proprietary or Free Software. This is not the only influence on the decision tho. The available vendors have to be evaluated for their longevity, "enlightenment" factor, product quality, and support efficacy. The Free Software projects are evaluated along the same lines.
My personal preferences are much different. I prefer Free Software for ethical reasons directly related to Freedom and the return of the results of a socialized production process to the control of the people whose labor produced it. I am not going to attempt to argue for that position if we're limiting ourselves to "professional programmers" tho.
-- Craig Brozefsky <cr...@red-bean.com> Lisp Web Dev List http://www.red-bean.com/lispweb --- The only good lisper is a coding lisper. ---
* tom wrote: > Implementations from only a single vendor put customers at the > complete mercy of that vendor once they have built a product. The > vendor can charge up to the customer's pain threshold, and if they > drop the product, the customer is left stranded. Few people who are > responsible for a large software development project want to accept > that kind of risk, even if the tool is quite a bit better.
This is plausible, but there's a glaring counterexample -- microsoft. How does that work (not a rhetorical question).
> Sun did several of those things with Java, which is why people jumped > on it. Critics of Java often seem to assume that people picked it out > of ignorance of the alternatives. In my experience, people who helped > get Java off the ground and pushed it into the mainstream (at IBM and > other places) knew the alternatives full well, but they supported Java > because it addressed those practical concerns; often, this meant > dropping support for languages they preferred technically.
I think there are two very interesting things about Java (not in any order):
1. Sun are *very* good at marketing. Whatever they did to make Java apparently such a success is worth close study. (I say `apparently' because I don't think I've ever used a significant Java program in anger, so it's not hit my particular bywater yet, though it may well yet do so)
2. It had some easy competition. C++ had been causing serious & ongoing pain for some time when Java started appearing, and in which many large and failed or failing projects had been attempted. Targetting Java as a better C++ was smart.
In article <ey3puptgkzn....@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
>* tom wrote:
>> Implementations from only a single vendor put customers at the >> complete mercy of that vendor once they have built a product. The >> vendor can charge up to the customer's pain threshold, and if they >> drop the product, the customer is left stranded. Few people who are >> responsible for a large software development project want to accept >> that kind of risk, even if the tool is quite a bit better.
>This is plausible, but there's a glaring counterexample -- microsoft. >How does that work (not a rhetorical question).
What tom described is called "Monopolistic behavior." True, Microsoft has been a monopoly for some time now, but they never really knew it or took advantage of it. Bill Gates started with a very small company and built it up. Initially, his company was one among many, surrounded by fierce competitors, and Gates behaved accordingly. That's no longer true, but it seems as if he's not aware of the fact; he handles Microsoft as if it were still small and could go under any time. This approach has brought them major problems, of course, when they confronted Netscape this way, won the battle, only to find that the government is trying to break them apart. Great big monopolies just aren't allowed to behave like little small outfits teetering on the brink of extinction.
But maybe now Microsoft is finding out that they have to change their modus operandi. If so, we can anticipate that they won't make full efforts to exploit their monopoly situation.
-- John E. Doner, UCSB Math. Dept., do...@math.ucsb.edu
> In article <ey3puptgkzn....@cley.com>, Tim Bradshaw <t...@cley.com> wrote: >>* tom wrote:
>>> Implementations from only a single vendor put customers at the >>> complete mercy of that vendor once they have built a product. The >>> vendor can charge up to the customer's pain threshold, and if they >>> drop the product, the customer is left stranded. Few people who are >>> responsible for a large software development project want to accept >>> that kind of risk, even if the tool is quite a bit better.
>>This is plausible, but there's a glaring counterexample -- microsoft. >>How does that work (not a rhetorical question).
> What tom described is called "Monopolistic behavior." True, > Microsoft has been a monopoly for some time now, but they > never really knew it or took advantage of it. Bill Gates > started with a very small company and built it up. Initially, > his company was one among many, surrounded by fierce > competitors, and Gates behaved accordingly. That's no longer > true, but it seems as if he's not aware of the fact; he > handles Microsoft as if it were still small and could go under > any time. This approach has brought them major problems, of > course, when they confronted Netscape this way, won the > battle, only to find that the government is trying to break > them apart. Great big monopolies just aren't allowed to > behave like little small outfits teetering on the brink of > extinction.
> But maybe now Microsoft is finding out that they have to > change their modus operandi. If so, we can anticipate that > they won't make full efforts to exploit their monopoly > situation.
Is this an example of Microsoft's PR machine scanning all newsgroups for any mention of their name and respondong by putting their spin on current events? --
> What tom described is called "Monopolistic behavior." True, > Microsoft has been a monopoly for some time now, but they > never really knew it or took advantage of it.
You're in the wrong group here better try comp.advocacy....
> Bill Gates > started with a very small company and built it up. Initially, > his company was one among many, surrounded by fierce > competitors, and Gates behaved accordingly. That's no longer > true, but it seems as if he's not aware of the fact; he > handles Microsoft as if it were still small and could go under > any time. This approach has brought them major problems, of > course, when they confronted Netscape this way, won the > battle, only to find that the government is trying to break > them apart. Great big monopolies just aren't allowed to > behave like little small outfits teetering on the brink of > extinction.
Microsoft has a monopoly and used it to supress other. Finding of facts AFAIK
