I'm not a big fan of abusing Java's interfaces (an interface for each implementation hierarchy), but in a big project that has to be properly documented and strictly specified, this would seem to help.
The interface is after all closer to the specification level, so your documentation can be strictly about the specification. Then you can let the programmers code, document and freeze the implementation independently from the interfaces.
Since an interface doesn't have any implementation sourcecode, writers could be trusted with the files, and since the interface API per se is frozen at design, they can keep modifying the Javadocs without affecting the coders.
If the writers have to modify the API per se and recompile an interface, they are changing the specification (re-design) and of course the coders are forced to adapt their code to those changes.
But otherwise there would be no need to "split the source" and then "merge". All you would have to do is provide the Javadocs for your interfaces (plus a manual based on this, perhaps) and the Javadocs for your implementation (if implementation details are to be exposed, such as efficiency guarantees, etc).
If anything, I would think the split would improve documentation.
They are metaphors, they were meant as metaphors and they are still primarily used as metaphors.
Jargon does not start as jargon, only after it's used has been established in their technical context are they considered the "jargon" or idioms of the field.
Jargon terms have only three origins: - Metaphors: process, kill, zombie, kernel, pipe, thread, batch, stack, etc. - Codes and Acronyms: tcp, lisp, java, pc, minix, perl, etc. - Idiotic Puns: more, less, archie, most shell commands.
Some, like GIMP, UNIX or GNU have mixed origins, but I'll let you decide which origins are present in the mix.
Not only are most computer science terms based on metaphors, very few people expect you to understand them properly without the metaphors. That makes learning concepts more difficult, and makes knowledge incomplete and not-portable.
I don't know if it would be great to have them back as a successful, populous species, but it would be great for science to have a specimen or two alive.
Why?
Because we learn as much from dead things as we pretend we do.
There's a lot more to animal anatomy than bones, and there's a lot more to biology and zoology than anatomy.
We speculate a lot on the behavior of animals based on fossils, but there are limits.
Even with fully functioning, breathing animals we don't know exactly how cats "purrr", can you imagine how little we know of an animal we have never seen alive? How many times have we changed our minds on the diet of a dinosaur, or the way it walked?
Sure, social behavior may be contaminated by learned behavior from its contemporary counterparts. But with enough specimens in different conditions, we could learn even about some of their social patterns (non-learned behavior).
I would think that the purpose and functionality of OO has actually little to do with the purpose and functionality of Emacs and LaTeX.
Of course, most people end up using an Office for the most stupid things, and smart people can make do using Emacs/LaTeX for what most people use an Office suite.
That doesn't mean it's a good idea to do either, or to force people to use tools that are not meant for the job they intend to do.
I'd like to see someone teaching the average secretary to use LaTeX/Emacs for the trivial document production at her job.
That's the target of an Office suite; people who are worried about making a memo readable, spell-checked and pretty in seconds without technical training. Not people who have to worry about precise typesetting, mathematical formulas, complex text manipulation through regexp, etc.
Asking them to use Emacs/LaTex for what they do would be, I suspect, as effective as asking programmers to use Word2K to write code.
It's all about Patent Law, IP contracts and the DMCA.
Sure, science could advance dramatically in days if the research is followed up, but what you don't know is that after centuries of abuse every Engineer in Star Fleet has a clause in his contract that protects his IP rights to every invention made outside a Research Facility.
Did you think Scotty was putting up with Kirk and a ship that's about to explode every 3 seconds for fun?
Right where you see him, the fat bastard has a very aggresive Patent Lawyer charging royalties from every unauthorized use of his expanding list of inventions.
This also means that every invention is created only in emergencies and never used again, in fear that the Enterprise will be sued for reverse-engineering some forgotten idea and violating the DMCA.
I find it troublesome that Declan puts Phil Zimmerman as an example of the technologist enforcing a greater change through software than the politicians through law.
He's right, but he makes the assumption that every geek, or at least a significant number of geeks, are going to be Phil Zimmermans.
He seems to forget that Phil Zimmerman put himself at legal risk, had to face legal consequences, and was technically considered a criminal by the government.
Not every geek has the courage to become a criminal for the sake of ideology, nor should they.
He also seems to forget that the change in the use and legal status of encryption was not brought by PGP alone. It took time, a lot of effort, and pressure from more social factors than Phil Zimmerman alone.
Very big and very important factors helping Zimmerman on that task were lobbying groups by business sectors who considered international strong encryption necessary to protect American Business (TM).
A big and important factor was that the opposition was mostly government bureaucracy. As far as I remember there was no Big Money group lobbying group OPPOSING relaxation of encryption legislation.
Without the lobbying, PGP and actually any unrestricted use of strong encryption would have stayed underground. Your legal international online transactions would have remained relatively unprotected.
No citizen, geek or not, should have to go "underground" and engage in "illegal activities" just to use technology for a legal purpose.
This has serious implications, not the least being that it makes every user a criminal and a target for extortion and government harassment.
That's why "just coding" is not the solution. Coding is necessary, it's the proof of concept that demonstrates which side is in touch with reality, but it is not sufficient. It never was, and I'm surprised Mr. McCullagh forgets that.
You can be both more incisive and factually correct:
any website coded by perl 1337 hackers who spent more time reading slashdot than studying CS is doomed to become an unmaintainable mess. look for programmers whose code is better designed for web use or at least maintainability (be it in perl, php, python, etc).
What would be the impediment to do a Servlet (since you're using CGI) interface and a telnet client in Java?
Not that I have tried so far, but I don't see what the great difficulty would be: interface code would be trivial, client code would be not too difficult either. There are more than a few Telnet classes out there if you don't want to deal with the raw Socket class yourself.
Now, whether the development time would be "negligible" or not, is another matter. For a Servlet-based application, it could very well be.
For a through analysis of the abstract concepts, no.
1) A good book that deals with the real problems ("web development" in this case) will stay up to date for as long as the problem is. The implementation details are incidental to the real value of the book.
Half of my web development books are obsolete, they use Tomcat 3.x/JSP 1.0/Servlets 1.x code and examples, and things have changed dramatically in that area.
Yet those are the same ones I actually use, because I'm not consulting books about APIs or specs, I'm reading books about software development.
A better example is perhaps "Design Patterns". I consider it a book that NEEDS to be skimmed over; that's how you read and use it. No single line of code has helped me in that book so far, but I consider it invaluable.
From what I remember of "The Art of Computer Programming", it's technologically irrelevant and obsolete, yet many consider it's invaluable to help understand technology because Itanium-assembler code is not the issue.
2) To most people a monitor is an inferior surface to read, and even for some who are comfortable with it (like me) it's just not as flexible as a book: we have learned to detect patterns over multiple pages, even multiple chapters, and we haven't learned to do it with the scroll bar. For some reason, we seem to be more efficient with 3-4 open books on our desk than 3-4 books on our "desktop", sharing psychological space with our software applications.
This could be solved with electronic paper, but many still feel the need for paper books.
While software makes it easier to look for things you already know you're looking for, in ways software is good at looking for, paper still lets humans do the kind of searching they are best at: browsing through the unknown.
3) You can look in a book for an alternative statement of the same concept.
It's called an "index", it's normally at the end of the page, and it tells you where the concept is mentioned/explained/used.
Hyperlinks are nothing more than the bastard child and logical extension of indexes and references. That's what makes them so insanely useful.
Now, if you mean you can't look for alternative statements by doing a search in Google, well, that's called research. It's been done ever since there were books, and it's the reason why the Dewey system was such a big deal back then.
Conclusion:
Electronic text is more convenient for some things (directed searches, instant references, etc) but it still doesn't offer some important advantages of the paper-world.
Besides cost, there is no logical reason, however, not to have both versions of the text in a newly produced text.
Even the most generalized, theory-oriented book would benefit from hyperlinking and searchable text, and some updated material. Providing both versions is the sensible solution.
But assuming that costs restrict the publication to only one kind of media, there are books better suited to e-text (most O'reilly books, essentially technical manuals) and there are books better suited to paper (a good Data Structures or Software Engineering book).
I guess it depends on whether you're meant to read the book, or to "consult" it.
Until all information currently stored in printed form is digitized, catalogued, and cross-referenced, arguing that digital libraries are more efficient makes no sense.
As a long-term ideal, sure. You can print out the digitally stored material on demand, for human consumption (or finally get that electronic paper thing to work).
But right now, a paper-less college isolates itself from most scholar works, reference material and general culture. It may still offer the basic technical training, but a college that doesn't provide a holistic education is not a college.
That doesn't mean you couldn't use the technology to dramatically reduce costs and improve the printed books' preservation.
Centralizing the storage of printed material and using inter-library loans, along with online access to digital records, to reduce costs is something that makes a lot of sense. Many books just are not constantly demanded by the student body.
That's only as long as you dramatically improve the efficiency and availability of interlibrary loans, and keep a decent amount of materiala available on-demand in the library: a latency of 2-3 days to check basic references could be deadly in some research.
As long as I went to college, I checked out books at least once per month, 5-6 per batch... until the last semester because I had a small conflict concerning library fees (late books were marked as lost).
The point is you may not have used the library, but a lot of people do. Not every student uses the computer lab, yet it is vital for some of us. Did you visit the art museum often (if your college has one)? Most people never do, but you can't have an art/humanities faculty without one.
Heck, I never put one foot in the sports arena at my university, but that doesn't give me the right to say it's useless for college education.
Storing printed works may be more efficient in digital format. Presentation is another matter: try to get any school or business to dump all their printers. Not going to happen.
But it doesn't mean merging is necessary, or a good idea at all.
C# solved the "boxing" and "unboxing" problem its own way, and I guess that's what inspired the author to propose the merge, but I don't think that's the simpler, best solution for the language.
It is my inexperienced opinion that he pointed something better (from the point of view of a programmer that wants to know when he's dealing with primitives or with an object) when he said it wouldn't be much more complicated than the + operator for String:
- Why not "overload" the arithmetic operators for the container classes?
This would be part of the merging process, but it would be 95% of what's really needed, and I'm still trying to figure out why they did it for String and not for Integer.
I can still now that "int a" will be forever an int primitive, and "Integer b" will forever be an Integer object, and will still get a compiler error if I mix them up... but "a + b" will give me sensible results.
The other 5% of the "need" for merging comes from Collections and their use of Object. But I still don't see why this should force us to turn everything into Objects.
Why not solve this with convenience methods in AbstractCollection and/or static methods in the Collection/Array classes?
Static methods would probably imply less work and be a bit more consistent. Static methods for adding large arrays of primitives (and retrieving them) from a Collection solve many of the Object/dichotomy problems.
The problem is that a method for adding/retrieving individual elements does not "belong" there. Collections.addInt(Collection c, int a) would do the work but reads a bit awkward.
Since most of the trivial common work for a Collection is already on the AbstractCollection, having some primitive-oriented "get" methods (like in JDBC) would be feasible and perhaps sensible.
My main gripe with this would be that I'm not sure this should be a change in the Collection interface, so as to not make it annoying to implement from scratch. But probably it should.
I would assume the main reason not to do this software-only, Tivo-only, is to prevent hacking.
Nielsen is taken very seriously as a source of ratings for the media. I'm certain they have some specialized hardware in their boxes to prevent tampering with the statistics.
If they do, the only easy way to "hack" the system to artificially rate your shows would be just to sit down and watch the damn things (or leave the TV on). Be non-representative. That assuming you have the damn box in the first place.
But then they could throw your numbers out if they are suspicious (36-hours with the TV on Battlebots reruns? Doesn't this guy ever sleep?).
On the other hand, if you let every Tivo be a Nielsen box, software only, how much time would it take for some geek to hack the system? Get a Linux box to send fake ratings through the network to get Cowboy Bebop on NBC?
Heck, even without hacking, a network executive could order 2000 Tivo boxes, put them in a basement, opt them in to Nielsen and program them according to the networks' agenda.
Maybe because he's only going to play them for the few weeks he's in Europe with his laptop.
Maybe he doesn't play that many computer games, or maybe he has a PC at home and that's his gaming machine.
Either way, if he doesn't have any games for the Mac, and he wants to play some games on the Mac for some hours but he doesn't want to pay 50 bucks for a 2-week entertainment value that's he's never going to touch again, why not get some free games and delete them later?.
I think Apple's WebObjects did a decent job with Java in that respect.
The problem is that the.NET tools are more polished, and the J2EE tools are lacking. The advantage of Java, right now, is the J2EE de facto standard... it's already doing what the companies want it to do, and they already have an investment in it, and there's no reason not to have the equivalent of a VS.NET for J2EE that works without propietary dependencies.
There seems to be (from a layman's point of view) a relatively big movement in the cognitive sciences claiming that human reason is inherently tied to perception and embodiment.
Particularly, this school claims that humans do not just base the basic structures of their logic on their sensorial perceptions (Damasio's "Descartes' Error"), but that they reuse the logic they develop to process perception, to process higher-level logic and language per se (Johnson and Lakoff's "Philosophy in the Flesh").
For example: the human mind, with complex instinctive and learned algorithms to deal with movement and position, would map causal reasoning to changes in movement and position and use the same algorithms (through the same hardware) to deal with it.
What would be the implications of such embodiment of reason on AI? Specifically, if a robot were given basic sensorial perceptions to approximate a human, motor ability, the logic to deal with these two, and the ability to map and reuse this logic for other purposes... would this make it better at "language AI" (approximate human processing of language)?
But I have to say the MSFT tools are really impressive, precisely because you don't have to choose between using the tools and designing and writing the program yourself.
Jumping back and forth between the code and the GUI is a breeze, and the code auto-generated by the GUI is amazingly clean, easy to modify by hand.
But it's the simple idea of #region what I have found makes the greatest difference in coding. I expect to see similar support for these in other tools, and I hope in other languages/platforms.
As a matter of fact, what I like about Visual Studio.NET has nothing to do with "Microsoft plan", or locking yourself out of your own source code, or limiting what you can do with your code. You can work in as low a level you want and never touch a wizard/GUI-builder. They're just simple ideas that help you to write CODE faster, easier, AND better.
There's no reason for other tools not to be able to copy VS.NET functionalities and provide decent IDEs for Java and other platforms. I fully expect them to do so, because I'm a Java programmer. As a result of.NET, I expect the Java development tools dramatically, and I suspect the same will happen with other languages.
"Sucks" is vague, indeed, but it doesn't mean it's non-constructive. It usually indicates a general lack of quality that, if no further clarification is given, can only be solved by replacing the source of the problem altogether.
For example:
- "This movie sucks" would, indeed, be non-constructive for the movie, but it could be constructive for the movie-going experience of the viewer who can go and watch a movie that "does not suck".
- "The acting in this movie sucks" would indicate that the suckness of the movie has its source in the acting. The movie would probably not suck if the actors were removed, therefore this is a constructive argument for the movie. By replacing the actors, the suckness of the movie is decreased.
That said, "FreeCiv's graphics suck" is clearly a constructive argument, if it is correct. By replacing the graphics altogether, the suckness would be removed more efficiently than by attempting to fix that which sucks too much to be fixed.
I say if it is correct because I am not aware of the current suckness level of FreeCiv's graphics. I know that at some point, they sucked majestically.
It was still my favorite Linux game, but the graphics sucked at life. Replacing them was such an obviously good idea that there seemed to exist many different efforts on doing precisely that.
Although I'm always eager to mock french ethnocentrism, this is silly:
METRIC
Everybody uses metric.
The only people still measuring things in feet, cubits, elephants or stones are USians, UKians, and some stone-age tribes spread throughout the globe.
And even the UKians show the intellectual ability to multiply and divide by 10 when they need to. Particularly when they send things to space.
LANGUAGE
At least they are aware there are other languages, beyond the names of food in your local "Taco Bell".
"MONTREALL": what are you talking about?
If you want something quirky to mock about the french, try their number/counting system. Just try writing numbers as they are dictated by a french person.
Slashdot Mirror
I'm not a big fan of abusing Java's interfaces (an interface for each implementation hierarchy), but in a big project that has to be properly documented and strictly specified, this would seem to help.
The interface is after all closer to the specification level, so your documentation can be strictly about the specification. Then you can let the programmers code, document and freeze the implementation independently from the interfaces.
Since an interface doesn't have any implementation sourcecode, writers could be trusted with the files, and since the interface API per se is frozen at design, they can keep modifying the Javadocs without affecting the coders.
If the writers have to modify the API per se and recompile an interface, they are changing the specification (re-design) and of course the coders are forced to adapt their code to those changes.
But otherwise there would be no need to "split the source" and then "merge". All you would have to do is provide the Javadocs for your interfaces (plus a manual based on this, perhaps) and the Javadocs for your implementation (if implementation details are to be exposed, such as efficiency guarantees, etc).
If anything, I would think the split would improve documentation.
They are metaphors, they were meant as metaphors and they are still primarily used as metaphors.
Jargon does not start as jargon, only after it's used has been established in their technical context are they considered the "jargon" or idioms of the field.
Jargon terms have only three origins:
- Metaphors: process, kill, zombie, kernel, pipe, thread, batch, stack, etc.
- Codes and Acronyms: tcp, lisp, java, pc, minix, perl, etc.
- Idiotic Puns: more, less, archie, most shell commands.
Some, like GIMP, UNIX or GNU have mixed origins, but I'll let you decide which origins are present in the mix.
Not only are most computer science terms based on metaphors, very few people expect you to understand them properly without the metaphors. That makes learning concepts more difficult, and makes knowledge incomplete and not-portable.
No, actually the voicebox is not the source of the sound.
That's about as much as is known.
It is suspected the vibration of an artery is what causes the sound. But it's not really known.
I meant:
Because we DON'T learn as much from death things as we pretend we do.
I don't know if it would be great to have them back as a successful, populous species, but it would be great for science to have a specimen or two alive.
Why?
Because we learn as much from dead things as we pretend we do.
There's a lot more to animal anatomy than bones, and there's a lot more to biology and zoology than anatomy.
We speculate a lot on the behavior of animals based on fossils, but there are limits.
Even with fully functioning, breathing animals we don't know exactly how cats "purrr", can you imagine how little we know of an animal we have never seen alive? How many times have we changed our minds on the diet of a dinosaur, or the way it walked?
Sure, social behavior may be contaminated by learned behavior from its contemporary counterparts. But with enough specimens in different conditions, we could learn even about some of their social patterns (non-learned behavior).
I would think that the purpose and functionality of OO has actually little to do with the purpose and functionality of Emacs and LaTeX.
Of course, most people end up using an Office for the most stupid things, and smart people can make do using Emacs/LaTeX for what most people use an Office suite.
That doesn't mean it's a good idea to do either, or to force people to use tools that are not meant for the job they intend to do.
I'd like to see someone teaching the average secretary to use LaTeX/Emacs for the trivial document production at her job.
That's the target of an Office suite; people who are worried about making a memo readable, spell-checked and pretty in seconds without technical training. Not people who have to worry about precise typesetting, mathematical formulas, complex text manipulation through regexp, etc.
Asking them to use Emacs/LaTex for what they do would be, I suspect, as effective as asking programmers to use Word2K to write code.
It's all about Patent Law, IP contracts and the DMCA.
Sure, science could advance dramatically in days if the research is followed up, but what you don't know is that after centuries of abuse every Engineer in Star Fleet has a clause in his contract that protects his IP rights to every invention made outside a Research Facility.
Did you think Scotty was putting up with Kirk and a ship that's about to explode every 3 seconds for fun?
Right where you see him, the fat bastard has a very aggresive Patent Lawyer charging royalties from every unauthorized use of his expanding list of inventions.
This also means that every invention is created only in emergencies and never used again, in fear that the Enterprise will be sued for reverse-engineering some forgotten idea and violating the DMCA.
I think that his point was not that Google didn't work for those searches, but that the pr0n people figured Google out.
But I might be wrong...
"A tatoo on your ass, now THAT lasts forever! :-)
As it turned out, she felt the same way, so we took a route that was appropriate."
Now, I have to ask... Did you really intend to write those two sentences together?
I find it troublesome that Declan puts Phil Zimmerman as an example of the technologist enforcing a greater change through software than the politicians through law.
He's right, but he makes the assumption that every geek, or at least a significant number of geeks, are going to be Phil Zimmermans.
He seems to forget that Phil Zimmerman put himself at legal risk, had to face legal consequences, and was technically considered a criminal by the government.
Not every geek has the courage to become a criminal for the sake of ideology, nor should they.
He also seems to forget that the change in the use and legal status of encryption was not brought by PGP alone. It took time, a lot of effort, and pressure from more social factors than Phil Zimmerman alone.
Very big and very important factors helping Zimmerman on that task were lobbying groups by business sectors who considered international strong encryption necessary to protect American Business (TM).
A big and important factor was that the opposition was mostly government bureaucracy. As far as I remember there was no Big Money group lobbying group OPPOSING relaxation of encryption legislation.
Without the lobbying, PGP and actually any unrestricted use of strong encryption would have stayed underground. Your legal international online transactions would have remained relatively unprotected.
No citizen, geek or not, should have to go "underground" and engage in "illegal activities" just to use technology for a legal purpose.
This has serious implications, not the least being that it makes every user a criminal and a target for extortion and government harassment.
That's why "just coding" is not the solution. Coding is necessary, it's the proof of concept that demonstrates which side is in touch with reality, but it is not sufficient. It never was, and I'm surprised Mr. McCullagh forgets that.
You can be both more incisive and factually correct:
any website coded by perl 1337 hackers who spent more time reading slashdot than studying CS is doomed to become an unmaintainable mess. look for programmers whose code is better designed for web use or at least maintainability (be it in perl, php, python, etc).
There you go.
What would be the impediment to do a Servlet (since you're using CGI) interface and a telnet client in Java?
Not that I have tried so far, but I don't see what the great difficulty would be: interface code would be trivial, client code would be not too difficult either. There are more than a few Telnet classes out there if you don't want to deal with the raw Socket class yourself.
Now, whether the development time would be "negligible" or not, is another matter. For a Servlet-based application, it could very well be.
For a technical reference, yes.
For a through analysis of the abstract concepts, no.
1) A good book that deals with the real problems ("web development" in this case) will stay up to date for as long as the problem is. The implementation details are incidental to the real value of the book.
Half of my web development books are obsolete, they use Tomcat 3.x/JSP 1.0/Servlets 1.x code and examples, and things have changed dramatically in that area.
Yet those are the same ones I actually use, because I'm not consulting books about APIs or specs, I'm reading books about software development.
A better example is perhaps "Design Patterns". I consider it a book that NEEDS to be skimmed over; that's how you read and use it. No single line of code has helped me in that book so far, but I consider it invaluable.
From what I remember of "The Art of Computer Programming", it's technologically irrelevant and obsolete, yet many consider it's invaluable to help understand technology because Itanium-assembler code is not the issue.
2) To most people a monitor is an inferior surface to read, and even for some who are comfortable with it (like me) it's just not as flexible as a book: we have learned to detect patterns over multiple pages, even multiple chapters, and we haven't learned to do it with the scroll bar. For some reason, we seem to be more efficient with 3-4 open books on our desk than 3-4 books on our "desktop", sharing psychological space with our software applications.
This could be solved with electronic paper, but many still feel the need for paper books.
While software makes it easier to look for things you already know you're looking for, in ways software is good at looking for, paper still lets humans do the kind of searching they are best at: browsing through the unknown.
3) You can look in a book for an alternative statement of the same concept.
It's called an "index", it's normally at the end of the page, and it tells you where the concept is mentioned/explained/used.
Hyperlinks are nothing more than the bastard child and logical extension of indexes and references. That's what makes them so insanely useful.
Now, if you mean you can't look for alternative statements by doing a search in Google, well, that's called research. It's been done ever since there were books, and it's the reason why the Dewey system was such a big deal back then.
Conclusion:
Electronic text is more convenient for some things (directed searches, instant references, etc) but it still doesn't offer some important advantages of the paper-world.
Besides cost, there is no logical reason, however, not to have both versions of the text in a newly produced text.
Even the most generalized, theory-oriented book would benefit from hyperlinking and searchable text, and some updated material. Providing both versions is the sensible solution.
But assuming that costs restrict the publication to only one kind of media, there are books better suited to e-text (most O'reilly books, essentially technical manuals) and there are books better suited to paper (a good Data Structures or Software Engineering book).
I guess it depends on whether you're meant to read the book, or to "consult" it.
Until all information currently stored in printed form is digitized, catalogued, and cross-referenced, arguing that digital libraries are more efficient makes no sense.
As a long-term ideal, sure. You can print out the digitally stored material on demand, for human consumption (or finally get that electronic paper thing to work).
But right now, a paper-less college isolates itself from most scholar works, reference material and general culture. It may still offer the basic technical training, but a college that doesn't provide a holistic education is not a college.
That doesn't mean you couldn't use the technology to dramatically reduce costs and improve the printed books' preservation.
Centralizing the storage of printed material and using inter-library loans, along with online access to digital records, to reduce costs is something that makes a lot of sense. Many books just are not constantly demanded by the student body.
That's only as long as you dramatically improve the efficiency and availability of interlibrary loans, and keep a decent amount of materiala available on-demand in the library: a latency of 2-3 days to check basic references could be deadly in some research.
As long as I went to college, I checked out books at least once per month, 5-6 per batch... until the last semester because I had a small conflict concerning library fees (late books were marked as lost).
The point is you may not have used the library, but a lot of people do. Not every student uses the computer lab, yet it is vital for some of us. Did you visit the art museum often (if your college has one)? Most people never do, but you can't have an art/humanities faculty without one.
Heck, I never put one foot in the sports arena at my university, but that doesn't give me the right to say it's useless for college education.
Storing printed works may be more efficient in digital format. Presentation is another matter: try to get any school or business to dump all their printers. Not going to happen.
But it doesn't mean merging is necessary, or a good idea at all.
C# solved the "boxing" and "unboxing" problem its own way, and I guess that's what inspired the author to propose the merge, but I don't think that's the simpler, best solution for the language.
It is my inexperienced opinion that he pointed something better (from the point of view of a programmer that wants to know when he's dealing with primitives or with an object) when he said it wouldn't be much more complicated than the + operator for String:
- Why not "overload" the arithmetic operators for the container classes?
This would be part of the merging process, but it would be 95% of what's really needed, and I'm still trying to figure out why they did it for String and not for Integer.
I can still now that "int a" will be forever an int primitive, and "Integer b" will forever be an Integer object, and will still get a compiler error if I mix them up... but "a + b" will give me sensible results.
The other 5% of the "need" for merging comes from Collections and their use of Object. But I still don't see why this should force us to turn everything into Objects.
Why not solve this with convenience methods in AbstractCollection and/or static methods in the Collection/Array classes?
Static methods would probably imply less work and be a bit more consistent. Static methods for adding large arrays of primitives (and retrieving them) from a Collection solve many of the Object/dichotomy problems.
The problem is that a method for adding/retrieving individual elements does not "belong" there. Collections.addInt(Collection c, int a) would do the work but reads a bit awkward.
Since most of the trivial common work for a Collection is already on the AbstractCollection, having some primitive-oriented "get" methods (like in JDBC) would be feasible and perhaps sensible.
My main gripe with this would be that I'm not sure this should be a change in the Collection interface, so as to not make it annoying to implement from scratch. But probably it should.
I would assume the main reason not to do this software-only, Tivo-only, is to prevent hacking.
Nielsen is taken very seriously as a source of ratings for the media. I'm certain they have some specialized hardware in their boxes to prevent tampering with the statistics.
If they do, the only easy way to "hack" the system to artificially rate your shows would be just to sit down and watch the damn things (or leave the TV on). Be non-representative. That assuming you have the damn box in the first place.
But then they could throw your numbers out if they are suspicious (36-hours with the TV on Battlebots reruns? Doesn't this guy ever sleep?).
On the other hand, if you let every Tivo be a Nielsen box, software only, how much time would it take for some geek to hack the system? Get a Linux box to send fake ratings through the network to get Cowboy Bebop on NBC?
Heck, even without hacking, a network executive could order 2000 Tivo boxes, put them in a basement, opt them in to Nielsen and program them according to the networks' agenda.
Maybe because he's only going to play them for the few weeks he's in Europe with his laptop.
Maybe he doesn't play that many computer games, or maybe he has a PC at home and that's his gaming machine.
Either way, if he doesn't have any games for the Mac, and he wants to play some games on the Mac for some hours but he doesn't want to pay 50 bucks for a 2-week entertainment value that's he's never going to touch again, why not get some free games and delete them later?.
I think Apple's WebObjects did a decent job with Java in that respect.
.NET tools are more polished, and the J2EE tools are lacking. The advantage of Java, right now, is the J2EE de facto standard... it's already doing what the companies want it to do, and they already have an investment in it, and there's no reason not to have the equivalent of a VS.NET for J2EE that works without propietary dependencies.
The problem is that the
I was going to write a through and complex argument about common logical errors (Dragonball is, sadly, Anime but not all Anime is Dragonball).
But then I realized all I had to do to refute this was to tell the troll to go see Perfect Blue, WHICH IS LINKED IN THE ARTICLE.
A troll about Anime could have been done so much better...
I have a better definition for .NET that Microsoft might seriously consider:
" It's like Java, but pretty. "
There seems to be (from a layman's point of view) a relatively big movement in the cognitive sciences claiming that human reason is inherently tied to perception and embodiment.
Particularly, this school claims that humans do not just base the basic structures of their logic on their sensorial perceptions (Damasio's "Descartes' Error"), but that they reuse the logic they develop to process perception, to process higher-level logic and language per se (Johnson and Lakoff's "Philosophy in the Flesh").
For example: the human mind, with complex instinctive and learned algorithms to deal with movement and position, would map causal reasoning to changes in movement and position and use the same algorithms (through the same hardware) to deal with it.
What would be the implications of such embodiment of reason on AI? Specifically, if a robot were given basic sensorial perceptions to approximate a human, motor ability, the logic to deal with these two, and the ability to map and reuse this logic for other purposes... would this make it better at "language AI" (approximate human processing of language)?
I don't know about the HMTL-down-to-DB stuff.
.NET has nothing to do with "Microsoft plan", or locking yourself out of your own source code, or limiting what you can do with your code. You can work in as low a level you want and never touch a wizard/GUI-builder. They're just simple ideas that help you to write CODE faster, easier, AND better.
.NET, I expect the Java development tools dramatically, and I suspect the same will happen with other languages.
But I have to say the MSFT tools are really impressive, precisely because you don't have to choose between using the tools and designing and writing the program yourself.
Jumping back and forth between the code and the GUI is a breeze, and the code auto-generated by the GUI is amazingly clean, easy to modify by hand.
But it's the simple idea of #region what I have found makes the greatest difference in coding. I expect to see similar support for these in other tools, and I hope in other languages/platforms.
As a matter of fact, what I like about Visual Studio
There's no reason for other tools not to be able to copy VS.NET functionalities and provide decent IDEs for Java and other platforms. I fully expect them to do so, because I'm a Java programmer. As a result of
"Sucks" is vague, indeed, but it doesn't mean it's non-constructive. It usually indicates a general lack of quality that, if no further clarification is given, can only be solved by replacing the source of the problem altogether.
For example:
- "This movie sucks" would, indeed, be non-constructive for the movie, but it could be constructive for the movie-going experience of the viewer who can go and watch a movie that "does not suck".
- "The acting in this movie sucks" would indicate that the suckness of the movie has its source in the acting. The movie would probably not suck if the actors were removed, therefore this is a constructive argument for the movie. By replacing the actors, the suckness of the movie is decreased.
That said, "FreeCiv's graphics suck" is clearly a constructive argument, if it is correct. By replacing the graphics altogether, the suckness would be removed more efficiently than by attempting to fix that which sucks too much to be fixed.
I say if it is correct because I am not aware of the current suckness level of FreeCiv's graphics. I know that at some point, they sucked majestically.
It was still my favorite Linux game, but the graphics sucked at life. Replacing them was such an obviously good idea that there seemed to exist many different efforts on doing precisely that.
Although I'm always eager to mock french ethnocentrism, this is silly:
METRIC
Everybody uses metric.
The only people still measuring things in feet, cubits, elephants or stones are USians, UKians, and some stone-age tribes spread throughout the globe.
And even the UKians show the intellectual ability to multiply and divide by 10 when they need to. Particularly when they send things to space.
LANGUAGE
At least they are aware there are other languages, beyond the names of food in your local "Taco Bell".
"MONTREALL": what are you talking about?
If you want something quirky to mock about the french, try their number/counting system. Just try writing numbers as they are dictated by a french person.