The parent post is quite correct that getting new code onto the server is a question the Berlin team have not yet addressed - though if I remember correctly there are a number of approaches that might work, including adding new widgets as remote CORBA objects. Allowing Java, or better (though probably not appropriate to Berlin) Postscript, code to be downloaded to the server would certainly be a big plus. Probably there are other configuration management issues to tackle in the system (as there are in X).
I'm not sure comments on how other people choose to expend their free-time are really appropriate, and Berlin is at the very least interesting, and at best possibly very useful.
I'm not at all sure how one could "use Java as a display server". You could provide remote access (using, say, RMI) to the AWT or Swing, and this has indeed been done for the AWT, and works. Kinda. You still have the same issues with getting new graphical objects from client to server as you do with Berlin. Remoting Java2D would really only give you a "better X", or really a "better ICA" since it has no windowing primitives. Nor am I sure what is meant by "implementing AWT and... Java2D... on raw hardware" - they already use acceleration where it is available, what more is needed ?
Finally, while the design of X has much to commend it, the protocol itself is by no means the last word in how to design a graphics system. It has no support for, for instance, vector based fonts or antialiasing, and these problems do show increasingly as the protocol is used more and more to push bitmaps and nothing else in systems that try to get more out of it than it was designed to provide (eg Englightenment).
The basic difference between X and Berlin at this level is that the Berlin system stores representations of all graphical objects on the server, whereas X only stores windows. There are swings and roundabouts here, but one of the swings is that, as the parent message points out, that Berlin does repaints on the server. However, the downside of this is that the server's memory usage is dependant on the complexity of the display, and probably higher on average than that of an X server.
This does not have much impact on bandwidth use - all display changes still have to be sent by the client to the server, and these are more frequent by far than window-damage repaints. Oddly, remote UI graphics are not especially bandwidth hungry - both LBX and Citrix's ICA use roughly modemeseue amounts of bandwidth. It does, however, have a positive impact on latencies and Berlin, if done right, should be usable over much higher latency connections than X (like the internet).
Simon
Disclaimer: I work for Citrix, but am not speaking for my employer.
13 states are also litigants, so even in GWB does get the DOJ to drop the case, it will not stop, though it may lose momentum.
I don't see it as inevitable that he will however. There are probably just as many powerful interests (Oracle, AOL etc) pushing for the case to continue as opposing it. His recent comments re what should be illegal under anti-trust not only do not match the current long-standing legislation (which is broader), but also may simply be pandering to the public sympathy MS still has.
Well, I agree with you about weenie winging - especially all this "I've looked at some screenshots, so I know Nautilus/Eazel/Gnome/X/Linux/Unix/Computers suck" stuff that seems to be passing for debate just now.
On the other hand, it is true to some extent that elements of X *are* a problem. Some are cultural problems, and some (shockingly) are real technical problems.
Amongst the technical problems is the fact that the rendering model was not very good even when it was designed (there was a rather good article linked from/. about this). Because of this, applications like Gnome and Enlightenment that try to push the graphical envelope end up sending more or less nothing but bitmaps to the server. This is not efficient of network bandwidth and is a direct consequence of trying to do certain complex things in X.
Antialiased fonts are a good example, in fact. Since X's text drawing commands only work with things X knows are fonts, and these are defined to be bitmap fonts, X knows nothing of the vector info needed to antialias text. As an application programmer, if you want anti-aliased text, you're left with one option - render the text yourself against a known background as a bitmap, and send the bitmap to the server to draw. Its slow, and it leads to code living on clients that should live on the server,
As an X server programmer, can you fix this ? Kind of. You can subtly break the protocol, and draw anti-aliased vector fonts when you're asked to draw bitmap fonts. This will probably work most of the time, but the "right thing" to do is to define an extension to the protocol, which is perfectly possible, but here we move from the realm of technical problems into socialogical problems.
For extensions to work in X, both client and server need to know of them and explicitly use them. This works fine with a small set of extenions - such as the shape extension - that are now almost universal, but adding new ones, to support a better rendering model allowing efficient use of "modern" rendering primitives and even (gasp) 3D, has proved very hard.
Partly the blame for this must be layed at the door of the standards bodies that have had de jure control over X - the X consortium and the open group. They have proved vulnerable to political manipulation and prone to premature propogation on standards (such as PEX and Motif) whose sole virtue was that they coule make everyone agree on them. Part of the blame lies with the protocol itself, and the fact that there is no provision for the client to extend the server's capbilities - or compensate for the lack thereof - in an elegant or easily implemented way.
Given that X on commercial Unix is almost dead outside of a few specialist operations and development shops, there are currently, as I think you kind of suggested, for the free software community to grap its de facto control of the standard by the throat and promulgate the extensions that are really needed to make X work, however as yet, this has failed to happen.
Under the circumstances, the higher court's opinion of Judge Jackson's actions don't matter much. The damning part is in the findings of fact, which the appeals courts cannot challenge, they can only review the findings in law. Since the findings of fact essentially say "Microsoft broke US antitrust laws", they have extremely limited room for manouevre.
Similarly, if the higher courts uphold judge jackson's judgement, which they pretty much have to do, they can't change the remedies.
There's be several problems with trying to write native code for Crusoe series devices. I am astonished none of the follow ups have pointed some of these out.
Firstly, Transmeta do not and have said that they will not publish the 'native' intruction set for the VLIW architecture(s). The only way I can see anyone getting around this is by partnering with them to create a run-time compiler for a different instruction set under NDA. It probably counts are core intellectual property. The two existing processors have different architectures anyway, so you instantly lose compatiblity not only with the x86 but also within the Crusoe series.
Secondly, VLIW processors like Crusoe and (quietly) Merced rely on the compiler doing their instruction scheduling. You therefore won't (unless you have a compiler for a brain) be able to write native assember, and will have a huge job cut out for you writing a C compiler. You may run into problems being able to optimise as well as Crusoe's code morpher even with teh best C compiler in the world, as you don't have as much information as it does since its operating at runtime.
Lastly, the instruction set is optimised for emulation, possibly even specifically for x86 emulation. Not only is its own behaviour going to be odd (they've clearly developed the HW and SW components of the CPU to work toghether, so you've effectively only got half of a processor), but important elements of normal CPU behaviour will be missing. For instance, exceptions will be strange to work with the commit/rollback mechanism, and as someone else has said, important hardware features like the MMU and some 'core' peripherals will be missing, since they're implemented in the processor firmware.
I've heard this before, but ctags can't even distinguish between a function's definition and its caller, let alone complicated things like what class it's in.
I'm no big fan of the current notepad-with-a-compile-button species of IDEs, but this is, I think the biggest weakness of plain-old-text programming.
There is no largest prime number. This is one of the very few things about prime numbers that can be proven.
If there were a largest prime number, there would be finite list of primes you could write down. If you took all of these numbers and multiplied them together, then added one, you would get a new prime number.
Re:Google already uses it
on
Who Owns Dmoz?
·
· Score: 2
Googles ads tend to be relevant to the search you performed, and because they're text they don't distract you by blinking. I don't find this offensive, and have even found it helpful.
There was a very early Spectrum game called "General Election", based on trying to get a party through a British general election. Essentially a monopoly-like board game on a computer. Very dull.
But you suggested things like libsafe are unnecessary, because you can grep programs for things that are known to be unsafe.
That isn't true. More complex uses of functions that are *sometimes* unsafe cannot be found in this way, and as the poster points out, that is a fundamental law of nature, not just a requirement for a cleverer perl script.
Technologies like these (copper interconnect, new insulators, new dielectrics) tend to be used in custom ASIC design long before they find their way into CPUs at all.
For example, people were using.18 micron processes to produce signal processing gear for cellphones (especially basestations) years before it turned up in a CPU.
Of course encapsulation existed before OO, as did some kinds of polymorphism. Its only really inheritance that was a unique contribution.
I was hoping you would do something to back up you arguments besides quoting references. You've said nothing to actually justify your assertion that OO languages are less useful than 'multi-paradigm' languages or that anyone really needs to get away from the OO paradigm for some given application. Specifically, I suppose, you would have to show that OO does not achieve its aim of facilitatin low coupling and high coherence leading to better levels of reuse, or that there was some other fatal problem that negated these presumed advantages.
Unless you can do this - or give some idea of how to do this - claiming that OO is "not good enough" is pointless. What is it not good enough for ? Where does it fail ? How slipping into another paradigm actually help ?
Well its clearly not the definition the person you replied to was using, because what they said made no sense under that defition but did if substitue 'static' for 'strong'. This is not an unusual error and is one many people who ought to know better fall into.
To treat Smalltalk as strongly typed you need to decide what you consider to be a type. Is it a class ? an interface ? the latter makes more sense, but has no explicit representation in the language, so its hard to claim the *language* is strongly typed (also, you can call become: or addMessage: which really screws up any claims along these lines). If you can do it for Self, I'll give you a prize.
Incidentally, the problem with OO and static typing is that the static types make it harder to reuse code for purposes not imagined by its original author. For instance if I have a smalltalk class Foo that manipulates object of class Bar but only ever calls two of their methods, I can reuse it to manipulate objects of class Baz by just implementing those two methods.
To do the same thing in Java or C++ the author of Foo would need to have forseen my requirement and provided an interface of pure virtual class that I could extend to declare the fact that I implement those two functions. Coupling inhibiting reuse again.
Strong typing has nothing to do with OO. As the previous poster was using it, strong typing refers to variables having definite types that cannot be violated declared at compile time - thus C++ is strongly typed and Java somewhat more so. Technically this is static typing, but who am I to argue with common usage ? Strictly strong typing refers to objects having a single definitive type that they retain for their entire life - you have a slighty better case using this definition if you can impose a concept of type on languages that have none of their own.
Weakly typed OO languages exist - Self and Smalltalk being the best examples. Smalltalk's classes are treated simply as predefined (and under the hood somewhat priveleged) objects. There is no recognisable concept of type that appears in the syntax or semantics of the language. Self is an even better example as it has no special priveleged class objects at all - object creation and definition is done by copying already existing prototype objects.
It has in fact been done for C, by Boehm (sic?) I think, though it is in theory not safe and may sometimes miss garbage. It uses some simple heuristics to guess which data items are pointers and traces references that way. Some tricks (like XORing pointers) upset it quite badly, but it can help with programs whose memory management is irredeemable (like XFree86). Works for C++ too. Might even work for assembler.
Its quite true that OO does not depend on GC or vice versa, however OO languages without GC have an extra obstacle to overcome - something has to keep track of which instance are and are not in use without making unwarranted assumptions about the behaviour of other modules.
Do you think you could try to be a little more abrasive ? I'm not quite getting the message here. More seriously - I was disappointed with you reply. I hoped you would try to give your reasons for your beliefs about OO.
There's only really one major point in the previous message: You believe that the OO assumption that abstraction is beneficial is incorrect, or at least too strong. Unfortunately you've failed to back this up yourself, so its completely impossible to answer the point. I will of course read Gabriel's book, now I know of its existence, but thats not going to help for the purposes of this conversation. Its really pointless in a forum like this to wave around "authoratitive" references without at least summarising their arguments. *Of course* abstractions that are too general will break software that tries to use them. *Shrug* noone ever claimed all OO programs were good - bad programmers will do the wrong thing in any paradigm. High coherence and low coupling are good because they let the developer think about the system one module at a time (though of course the modules should have been chosen to make up a coherent 'big picture') - this is what OO is meant to facilitate, and you haven't answered this point.
As to generics, Mr Stapanov can say what he pleases, but *you* failed to answer my point. Most OO languages either have generics or weak typing. Its Java, not C++, which is exceptional here. The STL components are *classes* with *virtual functions* some of which are designed to be extended through inheritance. STL did stop people from writing half-arsed collection implementations that required client classes to extend particular superclasses, but that was always just a consequence of C++'s unrooted type hierarchy. Oh look, another example of coupling (albeit one that's now thankfully fixed).
Oh, and the examples of C++ weaknesses I gave are examples of things that encourage high coupling between modules and thus reduce reuse. Your answers were both irrelevant. I don't care about the cost of virtual function tables, because 32 bits per object and a few K per class is not important for most applications, and I was talking about conversions, not dynamic casts. I do care about language features that encourage people to write non-reusable code without good reasons.
I agree that OO and Java are not the be all and end all of anything. However, I definitely don't agree that a 'multi-paradigm' language like C++ is the right way to go. Nor do I agree that 'dumb' programmers use Java and 'smart' programmers want choice. I must admit to not having read "Patterns in Software", but I'm not aware of anyone in the design patterns movement having 'lambasted' OO languages. The classic "Design Patterns" certainly emphasises patterns as a guiding concept in OO design, not as an opposed philosophy, though of course they do criticise certain OO approaches.
OO languages do not constrain programmers to write good programs or produce good designs, but they do encourage OO design, which is beneficial when done well. Of course, the languages introduce new possibilities for error by introducing powerful new features in the form of encapsulation (you have to choose what to encapsulate), subtype polymorphism (it is not always obvious what the type hierarchy should be), and implementation inheritance ('natural' type hierarchies rarely correspond well to reusable implementation).
Nonetheless, OO does fulfill the important requirement of being better than any other method for designing software (and after all, what is the competition ? you can take out implementation inheritance, or add generics, but essentially you still have an object based language). The important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in terms of natural abstractions and make changes with a good understanding of what they're doing. You're more likely to get reusable, maintainable code that way.
Java encourages (you can't force) object orriented design by making it easer, in essence, to do the right thing than the wrong thing. Its much harder - in Java - to write classes with long stretches of procedural code or complicated and messy interdependencies than it is to write clean and simple abstractions. Of course, you still have to be able to design natural and reusable components, or no language can help you. Java does indeed constrain you (and the rest of your development team, which may be an advantage), but it constrains you to do things you probably really wanted to do anyway. I don't know about OO, but productivity gains from Java are real (I'd cite the studies, but I don't have the URL, look at Sun's website).
The designers of C++ claim that the langauge is 'paradigm neutral' and does not force you to program in any particular style. This is not, IMHO, entirely true. Everything about C++ that is not also in C makes the language more object orriented (typical OO languages either have generics or weak typing, BTW, its Java and not C++ which is exceptional in forcing people to cast). It is unusual among OO languages really only in trying to maintain compatibility with C (hence a lot of the complexity - eg. pass by value). It is also hard to design good software for implementation in C++ - to leverage the language well, relatively high coupling between modules is necessary. To pick two random examples: C++ classes actually have to be designed to be subclassed, and the developer must guess which methods and features the client will need to use of override. Also, if I have two type hierarchies and I want to implement a conversion between the two in the 'natural' C++ way (using implicit constructors or cast operators) I *must* contaminate one hierarchy or the other with knowledge of the other's existence. This is not to mention the problems caused as ANSI C++ actually begins to be used in anger - eg. code that throws exceptions and code that uses pointers don't get on at all well.
As others have pointed out, a compiler *cannot* do the kinds of optimisations dynamo does.
Compilers only have the static representation of the program available to them. They have no idea what will be executed at runtime or how frequently. The only way they could ever do this, is to perform a data flow analysis - no faster, less effective and much more complex than actually running the program.
The player's who can buy? If you seriously believe the big pirates have any trouble getting ahold of writers that will copy the keys, you're seriously mistaken. The only people who'llhave any trouble getting hold of such things are private individuals, most of whose copying is either fair use anyway, or would probably not constitute a sale if copying were impossible.
Copying using deCSS is impractical with current technology because their simply is no other random access digital medium big enough to hold a movie.
CSS may been intended as a copy protection system, but in fact the only thing it can ever do effectively is protect the monopoly on the production of DVD players.
There's an important point here which I don't think any of the other follow-ups have picked up on: cross platform user interfaces are hard.
Its not trivial, as many people seem to believe, to "just go down to the native widgets". While the widget sets on different platforms are similar, they differ significantly in many ways, and some (notably Motif) are very limited. This is precisely what the Java AWT attempted, and as we've seen, user interfaces produced this way are limited, dull, and generally clunky to use.
This is exactly why the original Netscape went for completely separate user interface code for every platform. The trouble with that, of course, is that n separate user interfaces are hard to maintain, and inevitably functionality starts to drift into the UI code.
The option Mozilla has adopted - and Swing, most Smalltalk implementations, and almost every other attempt to create X-platform UI have also ended up with - is to draw the user interface in some way completely independant of the platform. Mozilla is particularly interesting in using web-like technologies to do it.
Of course, there is still a problem. People who are especially fond of their native UI get offended (surprised there haven't been any 'it's not like a Mac' posts yet), and its arguably less performant, though I don't see how that can be. If Gecko is fast, surely XPFE is fast too ?
Well "we" may have fought the powers that be, but on the whole "we" (whoever that is) don't matter much. For large coporations, and ISPs and for those trying to provide services of one kind or another (ASPs, if you like the jargon), centralisation is the only way to go.
The more stuff you have on the user's machine the more your support costs, as it breaks, needs to be replaced, etc, etc. When you look inside large companies you see a greater and greater tendency towards web-based and other centralised systems.
Temporary ? Most human-caused ecological disasters have been permanent and catastrophic. Its just the people who were around at the time are not available to talk about it.
Remember that civilization began in the heavily forrested fertile crescent in the middle east. What's there now ? desert. Ever wondered why ? Local climate change due to deforrestation.
Parts of polynesia had similar problems. The polynesians arrived, wiped out the local fauna, and then fell back on cultivating their traditional crops.
Slashdot Mirror
The parent post is quite correct that getting new code onto the server is a question the Berlin team have not yet addressed - though if I remember correctly there are a number of approaches that might work, including adding new widgets as remote CORBA objects. Allowing Java, or better (though probably not appropriate to Berlin) Postscript, code to be downloaded to the server would certainly be a big plus. Probably there are other configuration management issues to tackle in the system (as there are in X).
... Java2D ... on raw hardware" - they already use acceleration where it is available, what more is needed ?
I'm not sure comments on how other people choose to expend their free-time are really appropriate, and Berlin is at the very least interesting, and at best possibly very useful.
I'm not at all sure how one could "use Java as a display server". You could provide remote access (using, say, RMI) to the AWT or Swing, and this has indeed been done for the AWT, and works. Kinda. You still have the same issues with getting new graphical objects from client to server as you do with Berlin. Remoting Java2D would really only give you a "better X", or really a "better ICA" since it has no windowing primitives. Nor am I sure what is meant by "implementing AWT and
Finally, while the design of X has much to commend it, the protocol itself is by no means the last word in how to design a graphics system. It has no support for, for instance, vector based fonts or antialiasing, and these problems do show increasingly as the protocol is used more and more to push bitmaps and nothing else in systems that try to get more out of it than it was designed to provide (eg Englightenment).
Simon
The basic difference between X and Berlin at this level is that the Berlin system stores representations of all graphical objects on the server, whereas X only stores windows. There are swings and roundabouts here, but one of the swings is that, as the parent message points out, that Berlin does repaints on the server. However, the downside of this is that the server's memory usage is dependant on the complexity of the display, and probably higher on average than that of an X server.
This does not have much impact on bandwidth use - all display changes still have to be sent by the client to the server, and these are more frequent by far than window-damage repaints. Oddly, remote UI graphics are not especially bandwidth hungry - both LBX and Citrix's ICA use roughly modemeseue amounts of bandwidth. It does, however, have a positive impact on latencies and Berlin, if done right, should be usable over much higher latency connections than X (like the internet).
Simon
Disclaimer: I work for Citrix, but am not speaking for my employer.
13 states are also litigants, so even in GWB does get the DOJ to drop the case, it will not stop, though it may lose momentum.
I don't see it as inevitable that he will however. There are probably just as many powerful interests (Oracle, AOL etc) pushing for the case to continue as opposing it. His recent comments re what should be illegal under anti-trust not only do not match the current long-standing legislation (which is broader), but also may simply be pandering to the public sympathy MS still has.
Well, I agree with you about weenie winging - especially all this "I've looked at some screenshots, so I know Nautilus/Eazel/Gnome/X/Linux/Unix/Computers suck" stuff that seems to be passing for debate just now.
/. about this). Because of this, applications like Gnome and Enlightenment that try to push the graphical envelope end up sending more or less nothing but bitmaps to the server. This is not efficient of network bandwidth and is a direct consequence of trying to do certain complex things in X.
On the other hand, it is true to some extent that elements of X *are* a problem. Some are cultural problems, and some (shockingly) are real technical problems.
Amongst the technical problems is the fact that the rendering model was not very good even when it was designed (there was a rather good article linked from
Antialiased fonts are a good example, in fact. Since X's text drawing commands only work with things X knows are fonts, and these are defined to be bitmap fonts, X knows nothing of the vector info needed to antialias text. As an application programmer, if you want anti-aliased text, you're left with one option - render the text yourself against a known background as a bitmap, and send the bitmap to the server to draw. Its slow, and it leads to code living on clients that should live on the server,
As an X server programmer, can you fix this ? Kind of. You can subtly break the protocol, and draw anti-aliased vector fonts when you're asked to draw bitmap fonts. This will probably work most of the time, but the "right thing" to do is to define an extension to the protocol, which is perfectly possible, but here we move from the realm of technical problems into socialogical problems.
For extensions to work in X, both client and server need to know of them and explicitly use them. This works fine with a small set of extenions - such as the shape extension - that are now almost universal, but adding new ones, to support a better rendering model allowing efficient use of "modern" rendering primitives and even (gasp) 3D, has proved very hard.
Partly the blame for this must be layed at the door of the standards bodies that have had de jure control over X - the X consortium and the open group. They have proved vulnerable to political manipulation and prone to premature propogation on standards (such as PEX and Motif) whose sole virtue was that they coule make everyone agree on them. Part of the blame lies with the protocol itself, and the fact that there is no provision for the client to extend the server's capbilities - or compensate for the lack thereof - in an elegant or easily implemented way.
Given that X on commercial Unix is almost dead outside of a few specialist operations and development shops, there are currently, as I think you kind of suggested, for the free software community to grap its de facto control of the standard by the throat and promulgate the extensions that are really needed to make X work, however as yet, this has failed to happen.
Under the circumstances, the higher court's opinion of Judge Jackson's actions don't matter much. The damning part is in the findings of fact, which the appeals courts cannot challenge, they can only review the findings in law. Since the findings of fact essentially say "Microsoft broke US antitrust laws", they have extremely limited room for manouevre.
Similarly, if the higher courts uphold judge jackson's judgement, which they pretty much have to do, they can't change the remedies.
There's be several problems with trying to write native code for Crusoe series devices. I am astonished none of the follow ups have pointed some of these out.
Firstly, Transmeta do not and have said that they will not publish the 'native' intruction set for the VLIW architecture(s). The only way I can see anyone getting around this is by partnering with them to create a run-time compiler for a different instruction set under NDA. It probably counts are core intellectual property. The two existing processors have different architectures anyway, so you instantly lose compatiblity not only with the x86 but also within the Crusoe series.
Secondly, VLIW processors like Crusoe and (quietly) Merced rely on the compiler doing their instruction scheduling. You therefore won't (unless you have a compiler for a brain) be able to write native assember, and will have a huge job cut out for you writing a C compiler. You may run into problems being able to optimise as well as Crusoe's code morpher even with teh best C compiler in the world, as you don't have as much information as it does since its operating at runtime.
Lastly, the instruction set is optimised for emulation, possibly even specifically for x86 emulation. Not only is its own behaviour going to be odd (they've clearly developed the HW and SW components of the CPU to work toghether, so you've effectively only got half of a processor), but important elements of normal CPU behaviour will be missing. For instance, exceptions will be strange to work with the commit/rollback mechanism, and as someone else has said, important hardware features like the MMU and some 'core' peripherals will be missing, since they're implemented in the processor firmware.
In short - forget it.
I've heard this before, but ctags can't even distinguish between a function's definition and its caller, let alone complicated things like what class it's in.
I'm no big fan of the current notepad-with-a-compile-button species of IDEs, but this is, I think the biggest weakness of plain-old-text programming.
The maths and mathematical history in GEB is all correct, as far as I am aware.
There is no largest prime number. This is one of the very few things about prime numbers that can be proven.
If there were a largest prime number, there would be finite list of primes you could write down. If you took all of these numbers and multiplied them together, then added one, you would get a new prime number.
Like Linus, you mean ?
Simon
PS. He said, when last asked, that he uses RedHat
Googles ads tend to be relevant to the search you performed, and because they're text they don't distract you by blinking. I don't find this offensive, and have even found it helpful.
There was a very early Spectrum game called "General Election", based on trying to get a party through a British general election. Essentially a monopoly-like board game on a computer. Very dull.
But you suggested things like libsafe are unnecessary, because you can grep programs for things that are known to be unsafe.
That isn't true. More complex uses of functions that are *sometimes* unsafe cannot be found in this way, and as the poster points out, that is a fundamental law of nature, not just a requirement for a cleverer perl script.
Technologies like these (copper interconnect, new insulators, new dielectrics) tend to be used in custom ASIC design long before they find their way into CPUs at all.
.18 micron processes to produce signal processing gear for cellphones (especially basestations) years before it turned up in a CPU.
For example, people were using
Of course encapsulation existed before OO, as did some kinds of polymorphism. Its only really inheritance that was a unique contribution.
I was hoping you would do something to back up you arguments besides quoting references. You've said nothing to actually justify your assertion that OO languages are less useful than 'multi-paradigm' languages or that anyone really needs to get away from the OO paradigm for some given application. Specifically, I suppose, you would have to show that OO does not achieve its aim of facilitatin low coupling and high coherence leading to better levels of reuse, or that there was some other fatal problem that negated these presumed advantages.
Unless you can do this - or give some idea of how to do this - claiming that OO is "not good enough" is pointless. What is it not good enough for ? Where does it fail ? How slipping into another paradigm actually help ?
Well its clearly not the definition the person you replied to was using, because what they said made no sense under that defition but did if substitue 'static' for 'strong'. This is not an unusual error and is one many people who ought to know better fall into.
To treat Smalltalk as strongly typed you need to decide what you consider to be a type. Is it a class ? an interface ? the latter makes more sense, but has no explicit representation in the language, so its hard to claim the *language* is strongly typed (also, you can call become: or addMessage: which really screws up any claims along these lines). If you can do it for Self, I'll give you a prize.
Incidentally, the problem with OO and static typing is that the static types make it harder to reuse code for purposes not imagined by its original author. For instance if I have a smalltalk class Foo that manipulates object of class Bar but only ever calls two of their methods, I can reuse it to manipulate objects of class Baz by just implementing those two methods.
To do the same thing in Java or C++ the author of Foo would need to have forseen my requirement and provided an interface of pure virtual class that I could extend to declare the fact that I implement those two functions. Coupling inhibiting reuse again.
Strong typing has nothing to do with OO. As the previous poster was using it, strong typing refers to variables having definite types that cannot be violated declared at compile time - thus C++ is strongly typed and Java somewhat more so. Technically this is static typing, but who am I to argue with common usage ? Strictly strong typing refers to objects having a single definitive type that they retain for their entire life - you have a slighty better case using this definition if you can impose a concept of type on languages that have none of their own.
Weakly typed OO languages exist - Self and Smalltalk being the best examples. Smalltalk's classes are treated simply as predefined (and under the hood somewhat priveleged) objects. There is no recognisable concept of type that appears in the syntax or semantics of the language. Self is an even better example as it has no special priveleged class objects at all - object creation and definition is done by copying already existing prototype objects.
It has in fact been done for C, by Boehm (sic?) I think, though it is in theory not safe and may sometimes miss garbage. It uses some simple heuristics to guess which data items are pointers and traces references that way. Some tricks (like XORing pointers) upset it quite badly, but it can help with programs whose memory management is irredeemable (like XFree86). Works for C++ too. Might even work for assembler.
Its quite true that OO does not depend on GC or vice versa, however OO languages without GC have an extra obstacle to overcome - something has to keep track of which instance are and are not in use without making unwarranted assumptions about the behaviour of other modules.
Do you think you could try to be a little more abrasive ? I'm not quite getting the message here. More seriously - I was disappointed with you reply. I hoped you would try to give your reasons for your beliefs about OO.
There's only really one major point in the previous message: You believe that the OO assumption that abstraction is beneficial is incorrect, or at least too strong. Unfortunately you've failed to back this up yourself, so its completely impossible to answer the point. I will of course read Gabriel's book, now I know of its existence, but thats not going to help for the purposes of this conversation. Its really pointless in a forum like this to wave around "authoratitive" references without at least summarising their arguments. *Of course* abstractions that are too general will break software that tries to use them. *Shrug* noone ever claimed all OO programs were good - bad programmers will do the wrong thing in any paradigm. High coherence and low coupling are good because they let the developer think about the system one module at a time (though of course the modules should have been chosen to make up a coherent 'big picture') - this is what OO is meant to facilitate, and you haven't answered this point.
As to generics, Mr Stapanov can say what he pleases, but *you* failed to answer my point. Most OO languages either have generics or weak typing. Its Java, not C++, which is exceptional here. The STL components are *classes* with *virtual functions* some of which are designed to be extended through inheritance. STL did stop people from writing half-arsed collection implementations that required client classes to extend particular superclasses, but that was always just a consequence of C++'s unrooted type hierarchy. Oh look, another example of coupling (albeit one that's now thankfully fixed).
Oh, and the examples of C++ weaknesses I gave are examples of things that encourage high coupling between modules and thus reduce reuse. Your answers were both irrelevant. I don't care about the cost of virtual function tables, because 32 bits per object and a few K per class is not important for most applications, and I was talking about conversions, not dynamic casts. I do care about language features that encourage people to write non-reusable code without good reasons.
I agree that OO and Java are not the be all and end all of anything. However, I definitely don't agree that a 'multi-paradigm' language like C++ is the right way to go. Nor do I agree that 'dumb' programmers use Java and 'smart' programmers want choice. I must admit to not having read "Patterns in Software", but I'm not aware of anyone in the design patterns movement having 'lambasted' OO languages. The classic "Design Patterns" certainly emphasises patterns as a guiding concept in OO design, not as an opposed philosophy, though of course they do criticise certain OO approaches.
OO languages do not constrain programmers to write good programs or produce good designs, but they do encourage OO design, which is beneficial when done well. Of course, the languages introduce new possibilities for error by introducing powerful new features in the form of encapsulation (you have to choose what to encapsulate), subtype polymorphism (it is not always obvious what the type hierarchy should be), and implementation inheritance ('natural' type hierarchies rarely correspond well to reusable implementation).
Nonetheless, OO does fulfill the important requirement of being better than any other method for designing software (and after all, what is the competition ? you can take out implementation inheritance, or add generics, but essentially you still have an object based language). The important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in terms of natural abstractions and make changes with a good understanding of what they're doing. You're more likely to get reusable, maintainable code that way.
Java encourages (you can't force) object orriented design by making it easer, in essence, to do the right thing than the wrong thing. Its much harder - in Java - to write classes with long stretches of procedural code or complicated and messy interdependencies than it is to write clean and simple abstractions. Of course, you still have to be able to design natural and reusable components, or no language can help you. Java does indeed constrain you (and the rest of your development team, which may be an advantage), but it constrains you to do things you probably really wanted to do anyway. I don't know about OO, but productivity gains from Java are real (I'd cite the studies, but I don't have the URL, look at Sun's website).
The designers of C++ claim that the langauge is 'paradigm neutral' and does not force you to program in any particular style. This is not, IMHO, entirely true. Everything about C++ that is not also in C makes the language more object orriented (typical OO languages either have generics or weak typing, BTW, its Java and not C++ which is exceptional in forcing people to cast). It is unusual among OO languages really only in trying to maintain compatibility with C (hence a lot of the complexity - eg. pass by value). It is also hard to design good software for implementation in C++ - to leverage the language well, relatively high coupling between modules is necessary. To pick two random examples: C++ classes actually have to be designed to be subclassed, and the developer must guess which methods and features the client will need to use of override. Also, if I have two type hierarchies and I want to implement a conversion between the two in the 'natural' C++ way (using implicit constructors or cast operators) I *must* contaminate one hierarchy or the other with knowledge of the other's existence. This is not to mention the problems caused as ANSI C++ actually begins to be used in anger - eg. code that throws exceptions and code that uses pointers don't get on at all well.
As others have pointed out, a compiler *cannot* do the kinds of optimisations dynamo does.
Compilers only have the static representation of the program available to them. They have no idea what will be executed at runtime or how frequently. The only way they could ever do this, is to perform a data flow analysis - no faster, less effective and much more complex than actually running the program.
The player's who can buy? If you seriously believe the big pirates have any trouble getting ahold of writers that will copy the keys, you're seriously mistaken. The only people who'llhave any trouble getting hold of such things are private individuals, most of whose copying is either fair use anyway, or would probably not constitute a sale if copying were impossible.
Copying using deCSS is impractical with current technology because their simply is no other random access digital medium big enough to hold a movie.
CSS may been intended as a copy protection system, but in fact the only thing it can ever do effectively is protect the monopoly on the production of DVD players.
There's an important point here which I don't think any of the other follow-ups have picked up on: cross platform user interfaces are hard.
Its not trivial, as many people seem to believe, to "just go down to the native widgets". While the widget sets on different platforms are similar, they differ significantly in many ways, and some (notably Motif) are very limited. This is precisely what the Java AWT attempted, and as we've seen, user interfaces produced this way are limited, dull, and generally clunky to use.
This is exactly why the original Netscape went for completely separate user interface code for every platform. The trouble with that, of course, is that n separate user interfaces are hard to maintain, and inevitably functionality starts to drift into the UI code.
The option Mozilla has adopted - and Swing, most Smalltalk implementations, and almost every other attempt to create X-platform UI have also ended up with - is to draw the user interface in some way completely independant of the platform. Mozilla is particularly interesting in using web-like technologies to do it.
Of course, there is still a problem. People who are especially fond of their native UI get offended (surprised there haven't been any 'it's not like a Mac' posts yet), and its arguably less performant, though I don't see how that can be. If Gecko is fast, surely XPFE is fast too ?
Well "we" may have fought the powers that be, but on the whole "we" (whoever that is) don't matter much. For large coporations, and ISPs and for those trying to provide services of one kind or another (ASPs, if you like the jargon), centralisation is the only way to go.
The more stuff you have on the user's machine the more your support costs, as it breaks, needs to be replaced, etc, etc. When you look inside large companies you see a greater and greater tendency towards web-based and other centralised systems.
Simon
Temporary ? Most human-caused ecological disasters have been permanent and catastrophic. Its just the people who were around at the time are not available to talk about it.
Remember that civilization began in the heavily forrested fertile crescent in the middle east. What's there now ? desert. Ever wondered why ? Local climate change due to deforrestation.
Parts of polynesia had similar problems. The polynesians arrived, wiped out the local fauna, and then fell back on cultivating their traditional crops.