I will attempt to explain myself a little better (while the boss isn't looking). Maybe nightmare was a little strong, but there are still far simpler (yet as functioal) ways of archieving the same result. Let's start with the basic documentation examples:
Problem #1: Ignoring the setPriority() call, this is identical in functionality to Debug.warn("com.foo", "Low fuel level.") [a static method], but requires extra source and binary space. Even if you have a static instance of a Category, the effect is the same: the category associates a string name with a "channel" of log output.
Why does this make a different? Clarity. Brevity. Simplicity. And it effects the use of aspect debugging: It is often useful to have log or trace statements associated not with a class or method, but the logical routine (which is a set of function calls to achieve some abstract result).
For example: Say I have a banking application (for an ATM) and one of the routines is "draw money". This is a clearly definable routine, and runs through many methods. Some methods are dedicated to "draw money", even though they are in different classes and different packages. When debugging, I wish to easily trace the path of the "draw money" routine (read: "grep 'draw money' debug.log).
Categories (and log4j in general) do not simplify this activity.
Hierarchical categories are of some benefit, but mostly they make it easier to determine what areas of code should have logging enabled or disabled.
The suggested use of categories in the documentation introduces unnecessary redundancy: the class name is already known, yet used to create a unique category and assist in enabling or disabling logging based on class/package hierarchies.
Take this scenario: In a multithreaded application I have several packages and dozens of classes. I have isolated a bug to one of ten methods across three classes, which are called by each other in some order. I want to reconfigure my logging output to display only debug statements from these methods, and then only when they are in a thread with a particular name.
This may seem to be a very specific problem, but there are more general cases of use for logging and especially remote debugging of live applications.
For its size and complexity log4j cannot simplify some of the logging tasks I consider "basic", forcing me to add extra lines of code I don't want to see. Taking one line out of a 10 line method makes it one line more readable... and in a team development scenario where maintainance is important, I find that very significant.
I know this isn't a great dissertation on the evils of log4j, but its a start;) As I'm typing this I'm savaging my bandwidth with the 2.18Mb download of log4j-1.1.2 ; has it struct anyone that this is awefully big for logging software...?
Although I have not followed the process carefully, I have looked into both log4j and the JSR specification, and find both to be, well, less than ideal.
First, I am going to assume that the author(s) of log4j made representations on the relevent JSR, and didn't just keep quiet until it closed. The points they have brought up (in this article and in the log4j docs) are very true, and the JSR is certainly an inferior API.
However, Java is becoming increasingly bulked up with useless functionality. While debugging/logging is far from useless, the API presented by log4j is (in binary size) heavy, and IMNSHO a nightmare to use.
The idea of creating types to represent categories, used in both APIs, is a classic example of object overkill. Instead of simplifying code to make it easier to maintain, both these systems add an unnecessary amount of compilation to keep track of the category (amongst other things).
The ideal debug/log system should take a single line to invoke, and not have additional overheads.
Instead of striving for ultimate functionality in a less-than-perfect world, Java should be aiming for a small but effecient and highly usable core set of classes, and leave the bloatware to third-party libraries.
We still have and need a market for third-party software, and it is only through the innovation of extending a simple core that we can grow good software.
The JRE has bloated now from 5.5Mb to 8.8Mb. I've already had to develop two projects in C++ because I can make the distribution less than 650kb and not have to hastle (remote) customers to download and install the JRE... this is worsening the problem.
Sun is on a mission to create the Ultimate Set of APIs, and call it Java. The "community" is on a mission to get everything they don't want to do themselves shoved into an Ultimate Library. Somewhere we need experienced, knowledgable experts who work in industry with languages, people, design and requirements, to moderate the whole process.
This unfortunately is not good enough. Replacing an old DLL with a new one can break things.
Too often the new DLL corrects old bugs for which a program had to use a workaround, which causes the workaround to fail. Alternatively the new DLL can change functionality subtly or introduce new bugs, causing the same problems.
The ONLY option for true compatibility is to have multiple, separate DLLs, and dynamically link against the correct one.
This does, however, cripple the OO capabilities inherent in the OS: if you update DLLs like MSVCRT, you can cause L&F changes to all apps, keeping the system updated and consistent in L&F. BUT you do this at the risk of introducing the problems given above.
This entire discussion fails to draw attention to the distinctions between computer science, software engineering, programming and coding. Every argument here centres around coding - who has the best language, why their penis is bigger than yours, and the size of their porn collection. Let's start with some clarification.
Computer science is about the theory of computing. It starts with the rules of logic and the basic constructs of an automaton (be it finite, context-free or turing). It is concerned with the study and development of methodologies for the use and advancement of computing: this means algorithms, logical constructs and design techniques.
Software engineering is concerned with the design and implementation of real-world systems. It requires a working knowledge of design and the capabilities of algorithms and languages. It also requires project management and prediction skills, and some analytical capability.
Programming is the practice of implementing from a design. It is studied along with computer science, to provide a means for emperical investigation of the scientific concepts.
Coding is jargon for programming, but in a specific sense: coding does not follow the rigours of accepted methodology, and always has a particular technical goal, such as performance, binary size, or stability.
So, what language should be used to teach computer science? None. The science does not require a language. In fact it is hindered by languages. There is NO language that features all of the constructs available in theory. To select a language is to restrict the field of study -- imaging an Astronomy course only contemplating the visible universe!
Most courses teach applied computer science, which is a balance of scientific theory and practical elements in the form of programming. To combine these, a decision must be made on the intent of the practice.
The usual intent is to display the scientific theories in action. To do this it makes sense to use the most clear (not necessarily concise) language available. Most lecturers still describe program logic in pseudocode, which is most similar to BASIC or Pascal, and is simple enough for most English speaking persons to understand the intent.
To study methodologies, a language which employs the methodology should be used. This said, one would have to learn many different languages during a short course of study! The de facto methodology (for better or worse) at the moment is Object Oriented Analysis and Design (OOAD), so it makes sense to spend the most time studying the reasons for and benefits of OOAD. This also means the language to be used for study should make support OOAD.
The issues of stability, performance and binary size depend on the language in use. Such language-specific issues should not be the concern of anyone but coders. There are, however, generalisations of these issues that affect all classes of computer developers. Practices such as parameter bound checking, memory allocation and deallocation, and algorithm optimization all make sense in a computer science curriculum.
So where does that leave us? The language should be clear, support OOAD (at least), and be ammeanable to the presentation of more complex concepts.
There is one more requirement for a science or engineering subject: the student must, through the course, learn how to learn. The course must not teach them all they need to know, but give them a ground from which they can expand, plus the knowledge of how to find the resources for expansion.
All of this considered, Java and C++ are on a par.
Java's power and attraction lies in its clarity, simplicity, and clearly documented API. It is pure OO, and cannot be used to display non-OO concepts. Its carefully structured syntax and runtime platform make it ideal for studying good OO design, implementing complex architectures, studying algorithms, and especially considering the design-level effects of multi-threaded applications. Java's ability to introspect and dynamically instantiate classes gives it a power not found in most compiled languages, including C++; a power sufficient to dramatically change the design of an application.
C++ on the other hand sports parametised types, operator overloading, a massive but relatively poorly (compared to Java) documented library, the ability to make non-OO programs, and a much closer-to-basics view of the computer. Its complexity over Java allows better study of important language-design issues such as multiple inheritence, overloading and overriding. Explicit consideration of memory management is required, as well as a strong understanding of the concepts of pointers and references.
Were I to set a curriculum for university level study, I would choose to study both of these languages. The question of whether to study design or low-level implementation first is a touchy one, but my inclination would be towards studying and using Java for two years, and then making a more in-depth study of Java and comparison to C++ (while learning and studying C++ and language concepts) for one year. Thus Java would be used for implementation long before the complexities of language theory are fully explained ; at the point that this happens, two vastly different (in function) languages are compared and contrasted.
For school level courses, I would certainly recommend Java. These students may or may not progress to study computer science at university, and should be given a grounding not in the micro view of bits and gates, but the macro view of designing and implementing a functional (albeit basic) application. This sort of knowledge will stand them in good stead for general computer use, including macro programming to simplify tasks with common applications, and even programming using RAD environments. The "real" computer scientists (and programmers) can study the "real" stuff later on.
You are correct. Programming is an iterative process. Hence the reason for OOP and division of responsibility.
By allocating 40% of your time to analysis, you know what your software is expected to do. At the end of the day, it will do more. Users are like that. But 90% of your functionality is there. Another 40% of your time goes into design. Sure you have to account for the "10% unknown functionality", but you code is modular, so extension is easy. And you're left with some time to implement, knowing that 70% of statistics are made up on the spot...
As for forseeing problems... you're bang on the nose: we can't. Again, this is why we use OO. You see those cute little object diagrams we draw to whittle away the time, they are all documented in word processors (written using OO techniques, by the by), and every module/object has a clause stating how it handles, or expects callers to handle, enexpected errors...
...fortunately OO languages have try/catch logic, so you can HAVE unexpected errors, and not just throw out a valuable core dump for the user to analyse with the miriad of technical skills and copious free time.
So when you do find something unexpected during implementation, which always happens, you run back to the whiteboard and read what it says, and send back the appropriate exception. No design changes, no mess, no fuss... unless you screwed up the design in the first place, in which case you probably want to get some lessons so that you know what you are talking about (since its evident that you don't).
Why not try a language that encourages you to write small amounts of code that can be tested in isolation, and then makes it easy to combine that tested code in different ways with little modification.
Gee... let's see now... how about Visual Basic? Its got a nice editor where we can cut and paste functions! Oh wait, no - functions mean modularity... hell, you could even pass a pointer as the first argument to a function, and have it point to a data structure with all sorts of cool information -- that's getting dangerously close to OO ; just add some inheritence and a dash of polymorphism and you're there! How about a nice monolithic (old-style) Perl script... nothing modular there... nice and easy. Just write what you want and Cut 'n Paste it together... oops, you can't do that on a VT100 can you? Ack.
Despite its bad reviews on Amazon, Mastering Java 2 is an excellent resource for beginner to export.
It starts assuming you are familiar with programming concepts, but not with Java, and covers the bases from there. The first 8 chapters or so are dedicated to the groundwork: Java syntax, objects, concepts, all the way through to threading. There is extensive coverage of the AWT and (IIRC) Swing, and a good rundown on IO streams later in the book. It also introduces RMI, CORBA and other technologies enough to impart some understanding so you can get going on your own or with 'net references.
Another aspect of this argument, which is ignored by the article: the human factor.
Humanity is becoming universally more concerned with freedom and equality. There is growing discontent with the perpetual monitoring to which we are subjected, and with the ability of a few with political or (especially) economic power to dictate the nature of progress and change.
The power of communication has historically changed the balance of power in favour of the masses. The Internet is set to make this happen again. The DotCom revolution was a mostly failed attempt at economic revolution in this manner - but it did prove that communication allows the (relatively) poor to compete with the rich and powerful on nearly equal footing.
During the last centuary we have taken back more power than most ever believed possible - we have little reason to believe we are finished with that process.
The other side of the human factor is the people factor. People have a natural tendency to deal with other people. Several studies have shown that people do not want to deal with machines in most circumstances, and do not want machines to become "more like people". It has been made clear that people in general will not accept computers that are their equals, only their servants.
A computer that monitors you, senses you mood and so on, is at least your equal, possibly your superior. I can't speak for everyone, but most people I know get really tense when they are constantly pre-empted by someone else. Sometimes, even if you WANT coffee, you don't want a particular person to make it... because they ALWAYS offer you coffee when you want it, and it irks that someone knows you that intimately. That is human nature.
How many of you SCREAM when you get a voice answering system? Its just a facade behind which people without responsibility can hide, until you find the time and the right sequence of numbers to track down a real person who can assist you. Machines are an excuse for irresponsibility: the computer is down, its not programmed to do that, i can't do that it won't let me, it was a computer fault, and so on. A person can't hide from an error, but an electronic system can always take the blame without it ever being shifted onto a human(*).
(*) Except a technition/programmer, but they are never available to customers, and will only be shat out by managers in private.
You can't accurately predict the future without considering the human factor. It is a pointless exercise. James Martin is an acknowledged guru in prediction - that makes what he says a prime candidate for self-fulfilling prophecy. BECAUSE he said it, companies will race to do it, and consumers will be more likely to swallow it. Don't you love the "Expert Shtick"?
No... a TV that automatically picks up programs you enjoy will, given the current world trends, report that back to the network. Along with info about the adverts you like and dislike. And you end up with a DoubleClick position; the ability to target advertising at people who can't resist it.
So now the networks have a complete profile of your viewing habbits, and what adverts you will accept (and hence your tendencies towards products). How long before the government wants access to those profiles, to look for "typical child abusers and organised crime"?
"Down the wrong path". Care to expound on the meaning of that phrase? While many juvenile delinquents go on to be useful members of society, the bulk of fraud (which directly affects the financial welfare of thounsands of people) is committed by good-as-gold personnel who have proved their skill, reliability and value.
Teenage suicide is often pointed at as a "good reason" to monitor children. Pity. Constant evaluation / assessment is the direct cause of the sort of teenage pressure that causes depression, and desperate behaviour (read: criminal rebellion, self injury, suicide).
Besides, where do we draw the line on the "wrong path"? The public perception of "right path" is the suburban teenager who goes to school and works hard... and takes a couple of drugs, has a couple of sexual relationships. Wrong is the computer geek goth, who's active interest in debauchery, child porn, and anarchy through destroy global networks must be prevented at all costs. Besides, its not normal to dress in black all the time. Ravers are, of course, okay. They only engage in orgies and do drugs, and a normal, well-adjusted teenagers, who only occasionally OD and will generally go on to be normal, well-adjusted parents who will be wife beaters and child abusers. (Okay, not necessarily, but its just as possible as any other population group).
You can only determine "wrong path" based on public perception - there is no independent, scientific criteria for "wrong path". Suddenly we could find non-Christian religions, long hair, homosexuality, or intelligent political comment being the "wrong path".
No. Monitor is NOT acceptable under any normal circumstance.
Arrays aren't all they are cracked up to be. The first thing to consider is that every consideration for a relative position involves a calculation: X = X + 1 to look at the tile to the right, for example. The second thing to consider is that the entire array must reside in memory (or you can use nasty caching algorithms).
An alternative is to use an object scenario where each tile is an object (okay, I'm not actually advocating an OBJECT object here, just a discrete instance of a data structure). There are separate fields for left/right/up/down/above/below, to allow for a dynamically sized and shaped, truely 3D map. In effect this is a 6-way linked list. Although your storage overhead is higher (since you store pointers), you can more easily swap pieces of the map into and out of memory.
The bounds checking is precalculated to some extent, in that there is simply no link for absolute boundaries. You can easily do funky stuff link linking the "move right" for one tile to a non-adjacent tile, effectively creating a "teleport" zone, without special logic. A "map within a map" scenario is fairly easy too - a whole lot of tile have their right side (say) linked to the left side of a single tile, so that moving right would "exit" to a larger map (think Wasteland). A few additions to the tile data structure can control the logic in a more fine-grained manner, to apply only to certain units or local/global conditions.
Conditions themselves can be made more modular - a weather condition for example can be represented as a layer linked above the ground level tile.
Units comprise a separate yet linked structure. All units are placed in one huge linked list. This list must be parsed at every tick to account for unit actions. Each unit then forms part of three other doubly-linked lists: the team (side, faction, whatever), group, and map. In other words, the unit will be linked in to the map, above the ground layer (or below, if applicable). Moving the unit will change its linking in the map. Regrouping, defection and all the rest should be obvious.
Under this system, a unit is in fact a tile, but with additional information. That is to say the unit must be compatible with the tile data structure (in object terms a subclass or implementor of the map tile interface).
It always amazes me how supposedly qualified and skilled people can ask questions before making any effort to do background research. Not only does it show an inability to solve problems, but also prevents the questioner from supplying all the relevant information.
I could be mistaken, but you seem to be referring to Isometric Mapping, which is a 2D, not a 3D technique. A little Googlification of that keyword should produce more interesting stuff. this article discusses formats for a map file, and this one considers data structures and memory.
Of course, the most important question is: how are you going to USE the data? Your choice of a data structure must be based on data use, especially in a real-time game where effeciency is important. Memory requirements will become a third factor for consideration.
In general when dealing with isometric maps, you model a flyweight multilayer grid. This means the basic map is broken into a 2D grid of tiles (rectangular or hexagonal), each tile is split into several ordered layers, and the information about each tile is for the most part shared with all other tiles of the same nature (the flyweight design pattern).
The most common question about data structures is whether to use a 3-dimensional array (tile-x, tile-y, layer) or to a 2-dimensional array (tile-x, tile-y) with the tile itself holding an array of layer information.
When working with very few layers, or in a situation where the information in a particular layer must be accessessed in an iterative fashion, the 3-d array tends to be better. For many layers, or a case where the information for a particular layer does not need to be filtered out as a separate grid, a 2-d map with dynamic data structures for the layer information will keep memory requirements down, and follow good design principles (don't keep multiple data structures in sync - split the data into objects).
Good luck... now go and do your own work before asking more questions.
Sadly, and as stupid as it may seem, disseminating copies of "The Law" is illegal (without appropriate permissions) in most countries. Printing and publishing the laws is Big Business and the government contracts to do so are worth a Lot Of Money... so while everyone is supposed to have free (public) access to the laws (say, at your local library), copying them is a different matter.
I've also had an experience along these lines. Several years back I was trying to get a web development company off the ground, and was in the running for a huge contract with a multinational wanting to share data publically, as well as design information over a VPN. Security was obviously paramount.
It came down to two proposals in the end, and the competitor figured out who I was, and attacked my proposal by going after me: they cited lack of experience, expertise, backup, and all the rest, basing their agument on the fact that they were a large ISP and I want representing a newly-formed corporation with few employees.
So six months later rumours were going around in the hacker community that a certain company had suffered a major hacking incident - possibly NOT a leet or script kiddie, meaning industrial espionage considering the data they apparently got hold of. Guess who...?
Quite by chance I happened to meet with an IT representative of the company while visiting a client some weeks later. Although unofficially, they admitted that they had made a bad decision, and apologised - for what it was worth. Of course, they also made it clear that politically they couldn't change their minds.
This is unfortunately the mindset of many companies - live with a mistake and cover it up, rather than admit to a mistake and correct it. Heck - even MS is taking the latter route (bye Clippy!).
Once you've lost a contract, don't consider going after it anymore. If they come back to you, that's fine - but even that can lead to rumours flying from competitors, which is a Bad Idea (TM). My that's just my 2c worth...
There are a couple of systems that already exist. XwingML builds Java Swing interfaces from an XML specification. XUL is a similar XML-based markup supported by Mozilla. XForms is the W3C's draft standard for the next generation of web forms.
Most particularly you may want to look at UIML, which is intended as a cross-(viewing-)platform markup, supporting PCs, PDAs, etc. There is a Java viewer, and the new version seems to have some renderers for WML and HTML, but a text renderer should be possibe (if not already available).
There are several other lesser-known XML-to-GUI toolkits, such as KUIL and AUIT. Most of these are implemented in Java and map the Java Swing classes into XML (as with XwingML).
I think this is the critical point in the argument: many people argue that code is an art form, and therefore protected as "expressive speech". While code CAN be an art form, just as English CAN be an art form (poetry, drama, etc), code is primarily a means of communication.
A computer program is the communication of an algorithmic solution. In the ideal case, the program can be acted on by a computer to realise the solution - but pseudo-code or even gramatically incorrect (uncompilable) code communicates a concept accurately between experts in the field (of computer science).
If computers could act on "pure English" programs, would an English description of the deCSS algorithm be unacceptable? IS an English description unacceptable? If we approach a programming language as a means of communication (not specific to instructing the operation of a machine), we can show how ludicrous the arguments are.
I think the logic is that there is always some doubt, unless the accused confesses to the crime. Hence the "reasonable doubt" principle. If caught with burglary tools, the intent to commit the crime is more obvious, and intent is always a factor that makes for easier conviction and more serious penalties.
Why and how is a computer program expressive speech?
A computer program expresses a logical, algorithmic solution to a problem.
Background:
A computer is primarily a device of automation, used to simplify repetitive or calculation intensive tasks. It has, over time, evolved into a more general purpose tool, with applications in entertainment.
The purpose of software is to control the hardware of a computer, to execute a particular task. As such, software is the solution to the problem of "mechanical" automation of the task. Some software is supporting in nature, providing for the interpretation of more complex commands: operating systems and language runtime platforms are good examples.
Computer programs would be written in "plain English", except that, given current theories of software, we have not yet overcome the complexity of allowing a computer to act based on a language as varied as a spoken language: in English in particular there are numerous exceptions to the grammar rules, and the vocabulary exceeds 140000 words.
Conversely, a computer program could be written in mathematical notition. There is even software that acts as a runtime platform to interpret mathematical notation and simplify or solve equations. Were all computer to rely exclusively on this notation however, computers would be limited (by their language) to be mere mathematical solving machines.
In order to allow for the development of more complex tasks, languages matching the complexity of the task were required. Creating a language is itself a complex task, and so computer languages have evolved to match the complexity of contemporary demands, while not themselves being too complex to implement using older generation languages.
A computer language is thus a language in all respects, having a grammar and vocabulary. The significant difference from spoken languages is that the rules and vocabulary of a computer language are typically smaller and more rigid, allowing an automaton (arguably simpler than a human being) to act on them.
Beyond the application of computer languages to computers, they have evolved to be an effecient mechamism of communication between scientists involved in algorithmic solutions. "Pseudo-code" is a notation taught at most Universities, which is familiar to "a computer language" and would be mistaken for "a computer language" by a lay-man, yet no computer or software exists to interpret it.
This pseudo-code is used to communicate to another person the essence of an algorithmic solution, and is occasionally used beyond the walls of computer science. In mathematics, for example, the Sigma (sum of) notation is often explained as (for example in the case of E(1,10)X^2) "Start with zero, and for each value of X from 1 to 10, add the square of X." Depending on the expert in question, this could be considered "pseudo-code", or alternatively rewritten as:
Y = 0
for each X from 1 to 10
Y = Y + square of X
This is true "pseudo-code", and could conceivable be implemented as a (computer-understandable) language.
Were there no computer available to interpret a "computer program", yet it still communicated meaningful information to another person, would it be considered "speech"?
Can it then follow that pseudo-code should be considered "speech", or should there be a difference because it may be possible to implement software to "understand" pseudo-code?
Will English (or any other spoken language) be restricted if software is developed to allow a computer to be fully instructed in that language?
If not (since it is a spoken language) will a language such as Latin (or Elven or Klingon) be restricted if computers are make able to understand it (since these are not considered spoken languages, but are occasionally used for written communication).
If, given the above questions/thoughts pseudo-code is to be allowed, how can a distinction be drawn between pseudo-code and "real code", given that many scientists adapt pseudo-code to look more like any particular computer language with which they are familiar?
If I leave precise, written instructions (in English) for duplicating a tape (music or movie), knowing that the receiver of the instructions most likely does not know how to do so, am I responsible for copyright infringement? Is the written instruction responsible? Is the language (English) responsible? Or is the recipient responsible if (and only if) (s)he uses the instructions to duplicate the tape illegally?
To conclude: A computer program is a description of a solution to an algorithmic problem, described in a language with a restricted grammar and vocabulary. Many other sciences have their own languages (notations, names, symbols) for communicating effectively between experts in the field. A computer program has the capability of being able to be interpretted and acted upon by a computer, allowing the solution to be realised. Scientific, engineering and financial notations have various instruments which can act upon the notations; some even have limited algorithmic capability. In each case the solution is realised by communicating with a device, in a language which is acceptable, and used, for more general communication.
Bypass #1: Disable JavaScript. Bypass #2: Read the source code, download the image directly from the URL. Bypass #3: Take a screenshot and cut out the image you want.
Your problem isn't the 80% female over 35 audience. Its the single 15 year old linux kiddie who knows how to rip out the content, and distribute it to the 80% female over 35 audience for free (or a lot less than you charge).
...and no, the DCMA does not protect against cut & paste - that's the job of Copyright. The plug-in decrypts the information (legally) and displays it -- *then* it gets copied.
Let's not stop there:) Screenshot + OCR would do wonders for retrieving most anything you can display "securely" on a screen. Diagrams of course could be handled by a screenshot alone. I'm sure we could do that in X with a couple of piped commands and about 15 seconds worth of viewing time...
Umm.. no, you can't. Well you CAN, but their mail server won't receive the mail for your domain. It certainly won't do virtual domain hosting, or direct all mails @the.domain to your e-mail account, whatever. For that, which means anything to do with an MX record point at a mail server, the mail server admin has to agree and configure the server appropriately.
So it comes down to: alter SMTP to support (arbitary) forwarding, or alter capatalism to get an ISP to accept mail to your virtual domain at no (low) cost. Hmmm.
Most IM systems under development could be extended to avoid spam without too much trouble. The problem is that these systems all use a centralised server/service, making your communication reliant on a single service, organisation, addressing system, whatever.
We have a perfectly valid architecture for messaging... its called e-mail. Why aren't we extending e-mail servers to handle instant messaging (IAMOF SMTP already has IM capabilities of sorts in the SOML and SAML commands).
Its about time people thought of integration and simplification, rather than running off and writing newer and more complex protocols to force yet another icon/program onto my already cluttered desktop.
Java is ugly, sometimes, if you're doing things the language wasn't meant to do. Reflection is primarily a means to access compiled classes at runtime, and while it can be used to invoke methods dynamically, its certainly not meant to. If you want it to look pretty, make a library function. That's the only reason it looks pretty in other languages.
Gloves seem somewhat outdated in a strange way. They never caught on, and are a little cumbersome for day-to-day activity (ever tried typing in gloves?). But what about something smaller? MEMS technology is developing better and smaller solutions every day - and accelerometers could be an answer.
Instead of putting a glove on your hand, how about sticking a small IR/Bluetooth/802.11/whatever MEMS device to the back of your hand, and go for it. Wave your hand around, and have the sensors track the motion in 3D. I'm fairly certain that in time (if not already) the sensors will be sensitive and reliable enough for you to be able to select screen items by "pressing" them.
This would be a wonderful way to go for interfaces (for selection, at least, not text input), as it would work with a device of any size, and is totally portable.
Slashdot Mirror
I will attempt to explain myself a little better (while the boss isn't looking). Maybe nightmare was a little strong, but there are still far simpler (yet as functioal) ways of archieving the same result. Let's start with the basic documentation examples:
Category cat = Category.getInstance("com.foo");
cat.setPriority(Priority.INFO);
cat.warn("Low fuel level.");
Problem #1: Ignoring the setPriority() call, this is identical in functionality to Debug.warn("com.foo", "Low fuel level.") [a static method], but requires extra source and binary space. Even if you have a static instance of a Category, the effect is the same: the category associates a string name with a "channel" of log output.
Why does this make a different? Clarity. Brevity. Simplicity. And it effects the use of aspect debugging: It is often useful to have log or trace statements associated not with a class or method, but the logical routine (which is a set of function calls to achieve some abstract result).
For example: Say I have a banking application (for an ATM) and one of the routines is "draw money". This is a clearly definable routine, and runs through many methods. Some methods are dedicated to "draw money", even though they are in different classes and different packages. When debugging, I wish to easily trace the path of the "draw money" routine (read: "grep 'draw money' debug.log).
Categories (and log4j in general) do not simplify this activity.
Hierarchical categories are of some benefit, but mostly they make it easier to determine what areas of code should have logging enabled or disabled.
The suggested use of categories in the documentation introduces unnecessary redundancy: the class name is already known, yet used to create a unique category and assist in enabling or disabling logging based on class/package hierarchies.
Take this scenario: In a multithreaded application I have several packages and dozens of classes. I have isolated a bug to one of ten methods across three classes, which are called by each other in some order. I want to reconfigure my logging output to display only debug statements from these methods, and then only when they are in a thread with a particular name.
This may seem to be a very specific problem, but there are more general cases of use for logging and especially remote debugging of live applications.
For its size and complexity log4j cannot simplify some of the logging tasks I consider "basic", forcing me to add extra lines of code I don't want to see. Taking one line out of a 10 line method makes it one line more readable ... and in a team development scenario where maintainance is important, I find that very significant.
I know this isn't a great dissertation on the evils of log4j, but its a start ;) As I'm typing this I'm savaging my bandwidth with the 2.18Mb download of log4j-1.1.2 ; has it struct anyone that this is awefully big for logging software ...?
Although I have not followed the process carefully, I have looked into both log4j and the JSR specification, and find both to be, well, less than ideal.
First, I am going to assume that the author(s) of log4j made representations on the relevent JSR, and didn't just keep quiet until it closed. The points they have brought up (in this article and in the log4j docs) are very true, and the JSR is certainly an inferior API.
However, Java is becoming increasingly bulked up with useless functionality. While debugging/logging is far from useless, the API presented by log4j is (in binary size) heavy, and IMNSHO a nightmare to use.
The idea of creating types to represent categories, used in both APIs, is a classic example of object overkill. Instead of simplifying code to make it easier to maintain, both these systems add an unnecessary amount of compilation to keep track of the category (amongst other things).
The ideal debug/log system should take a single line to invoke, and not have additional overheads.
Instead of striving for ultimate functionality in a less-than-perfect world, Java should be aiming for a small but effecient and highly usable core set of classes, and leave the bloatware to third-party libraries.
We still have and need a market for third-party software, and it is only through the innovation of extending a simple core that we can grow good software.
The JRE has bloated now from 5.5Mb to 8.8Mb. I've already had to develop two projects in C++ because I can make the distribution less than 650kb and not have to hastle (remote) customers to download and install the JRE ... this is worsening the problem.
Sun is on a mission to create the Ultimate Set of APIs, and call it Java. The "community" is on a mission to get everything they don't want to do themselves shoved into an Ultimate Library. Somewhere we need experienced, knowledgable experts who work in industry with languages, people, design and requirements, to moderate the whole process.
Twylite
This unfortunately is not good enough. Replacing an old DLL with a new one can break things.
Too often the new DLL corrects old bugs for which a program had to use a workaround, which causes the workaround to fail. Alternatively the new DLL can change functionality subtly or introduce new bugs, causing the same problems.
The ONLY option for true compatibility is to have multiple, separate DLLs, and dynamically link against the correct one.
This does, however, cripple the OO capabilities inherent in the OS: if you update DLLs like MSVCRT, you can cause L&F changes to all apps, keeping the system updated and consistent in L&F. BUT you do this at the risk of introducing the problems given above.
This entire discussion fails to draw attention to the distinctions between computer science, software engineering, programming and coding. Every argument here centres around coding - who has the best language, why their penis is bigger than yours, and the size of their porn collection. Let's start with some clarification.
Computer science is about the theory of computing. It starts with the rules of logic and the basic constructs of an automaton (be it finite, context-free or turing). It is concerned with the study and development of methodologies for the use and advancement of computing: this means algorithms, logical constructs and design techniques.
Software engineering is concerned with the design and implementation of real-world systems. It requires a working knowledge of design and the capabilities of algorithms and languages. It also requires project management and prediction skills, and some analytical capability.
Programming is the practice of implementing from a design. It is studied along with computer science, to provide a means for emperical investigation of the scientific concepts.
Coding is jargon for programming, but in a specific sense: coding does not follow the rigours of accepted methodology, and always has a particular technical goal, such as performance, binary size, or stability.
So, what language should be used to teach computer science? None. The science does not require a language. In fact it is hindered by languages. There is NO language that features all of the constructs available in theory. To select a language is to restrict the field of study -- imaging an Astronomy course only contemplating the visible universe!
Most courses teach applied computer science, which is a balance of scientific theory and practical elements in the form of programming. To combine these, a decision must be made on the intent of the practice.
The usual intent is to display the scientific theories in action. To do this it makes sense to use the most clear (not necessarily concise) language available. Most lecturers still describe program logic in pseudocode, which is most similar to BASIC or Pascal, and is simple enough for most English speaking persons to understand the intent.
To study methodologies, a language which employs the methodology should be used. This said, one would have to learn many different languages during a short course of study! The de facto methodology (for better or worse) at the moment is Object Oriented Analysis and Design (OOAD), so it makes sense to spend the most time studying the reasons for and benefits of OOAD. This also means the language to be used for study should make support OOAD.
The issues of stability, performance and binary size depend on the language in use. Such language-specific issues should not be the concern of anyone but coders. There are, however, generalisations of these issues that affect all classes of computer developers. Practices such as parameter bound checking, memory allocation and deallocation, and algorithm optimization all make sense in a computer science curriculum.
So where does that leave us? The language should be clear, support OOAD (at least), and be ammeanable to the presentation of more complex concepts.
There is one more requirement for a science or engineering subject: the student must, through the course, learn how to learn. The course must not teach them all they need to know, but give them a ground from which they can expand, plus the knowledge of how to find the resources for expansion.
All of this considered, Java and C++ are on a par.
Java's power and attraction lies in its clarity, simplicity, and clearly documented API. It is pure OO, and cannot be used to display non-OO concepts. Its carefully structured syntax and runtime platform make it ideal for studying good OO design, implementing complex architectures, studying algorithms, and especially considering the design-level effects of multi-threaded applications. Java's ability to introspect and dynamically instantiate classes gives it a power not found in most compiled languages, including C++; a power sufficient to dramatically change the design of an application.
C++ on the other hand sports parametised types, operator overloading, a massive but relatively poorly (compared to Java) documented library, the ability to make non-OO programs, and a much closer-to-basics view of the computer. Its complexity over Java allows better study of important language-design issues such as multiple inheritence, overloading and overriding. Explicit consideration of memory management is required, as well as a strong understanding of the concepts of pointers and references.
Were I to set a curriculum for university level study, I would choose to study both of these languages. The question of whether to study design or low-level implementation first is a touchy one, but my inclination would be towards studying and using Java for two years, and then making a more in-depth study of Java and comparison to C++ (while learning and studying C++ and language concepts) for one year. Thus Java would be used for implementation long before the complexities of language theory are fully explained ; at the point that this happens, two vastly different (in function) languages are compared and contrasted.
For school level courses, I would certainly recommend Java. These students may or may not progress to study computer science at university, and should be given a grounding not in the micro view of bits and gates, but the macro view of designing and implementing a functional (albeit basic) application. This sort of knowledge will stand them in good stead for general computer use, including macro programming to simplify tasks with common applications, and even programming using RAD environments. The "real" computer scientists (and programmers) can study the "real" stuff later on.
You are correct. Programming is an iterative process. Hence the reason for OOP and division of responsibility.
By allocating 40% of your time to analysis, you know what your software is expected to do. At the end of the day, it will do more. Users are like that. But 90% of your functionality is there. Another 40% of your time goes into design. Sure you have to account for the "10% unknown functionality", but you code is modular, so extension is easy. And you're left with some time to implement, knowing that 70% of statistics are made up on the spot...
As for forseeing problems ... you're bang on the nose: we can't. Again, this is why we use OO. You see those cute little object diagrams we draw to whittle away the time, they are all documented in word processors (written using OO techniques, by the by), and every module/object has a clause stating how it handles, or expects callers to handle, enexpected errors...
...fortunately OO languages have try/catch logic, so you can HAVE unexpected errors, and not just throw out a valuable core dump for the user to analyse with the miriad of technical skills and copious free time.
So when you do find something unexpected during implementation, which always happens, you run back to the whiteboard and read what it says, and send back the appropriate exception. No design changes, no mess, no fuss ... unless you screwed up the design in the first place, in which case you probably want to get some lessons so that you know what you are talking about (since its evident that you don't).
Why not try a language that encourages you to write small amounts of code that can be tested in isolation, and then makes it easy to combine that tested code in different ways with little modification.
Gee ... let's see now ... how about Visual Basic? Its got a nice editor where we can cut and paste functions! Oh wait, no - functions mean modularity ... hell, you could even pass a pointer as the first argument to a function, and have it point to a data structure with all sorts of cool information -- that's getting dangerously close to OO ; just add some inheritence and a dash of polymorphism and you're there! How about a nice monolithic (old-style) Perl script ... nothing modular there ... nice and easy. Just write what you want and Cut 'n Paste it together... oops, you can't do that on a VT100 can you? Ack.
Despite its bad reviews on Amazon, Mastering Java 2 is an excellent resource for beginner to export.
It starts assuming you are familiar with programming concepts, but not with Java, and covers the bases from there. The first 8 chapters or so are dedicated to the groundwork: Java syntax, objects, concepts, all the way through to threading. There is extensive coverage of the AWT and (IIRC) Swing, and a good rundown on IO streams later in the book. It also introduces RMI, CORBA and other technologies enough to impart some understanding so you can get going on your own or with 'net references.
Another aspect of this argument, which is ignored by the article: the human factor.
Humanity is becoming universally more concerned with freedom and equality. There is growing discontent with the perpetual monitoring to which we are subjected, and with the ability of a few with political or (especially) economic power to dictate the nature of progress and change.
The power of communication has historically changed the balance of power in favour of the masses. The Internet is set to make this happen again. The DotCom revolution was a mostly failed attempt at economic revolution in this manner - but it did prove that communication allows the (relatively) poor to compete with the rich and powerful on nearly equal footing.
During the last centuary we have taken back more power than most ever believed possible - we have little reason to believe we are finished with that process.
The other side of the human factor is the people factor. People have a natural tendency to deal with other people. Several studies have shown that people do not want to deal with machines in most circumstances, and do not want machines to become "more like people". It has been made clear that people in general will not accept computers that are their equals, only their servants.
A computer that monitors you, senses you mood and so on, is at least your equal, possibly your superior. I can't speak for everyone, but most people I know get really tense when they are constantly pre-empted by someone else. Sometimes, even if you WANT coffee, you don't want a particular person to make it ... because they ALWAYS offer you coffee when you want it, and it irks that someone knows you that intimately. That is human nature.
How many of you SCREAM when you get a voice answering system? Its just a facade behind which people without responsibility can hide, until you find the time and the right sequence of numbers to track down a real person who can assist you. Machines are an excuse for irresponsibility: the computer is down, its not programmed to do that, i can't do that it won't let me, it was a computer fault, and so on. A person can't hide from an error, but an electronic system can always take the blame without it ever being shifted onto a human(*).
(*) Except a technition/programmer, but they are never available to customers, and will only be shat out by managers in private.
You can't accurately predict the future without considering the human factor. It is a pointless exercise. James Martin is an acknowledged guru in prediction - that makes what he says a prime candidate for self-fulfilling prophecy. BECAUSE he said it, companies will race to do it, and consumers will be more likely to swallow it. Don't you love the "Expert Shtick"?
No ... a TV that automatically picks up programs you enjoy will, given the current world trends, report that back to the network. Along with info about the adverts you like and dislike. And you end up with a DoubleClick position; the ability to target advertising at people who can't resist it.
So now the networks have a complete profile of your viewing habbits, and what adverts you will accept (and hence your tendencies towards products). How long before the government wants access to those profiles, to look for "typical child abusers and organised crime"?
"Down the wrong path". Care to expound on the meaning of that phrase? While many juvenile delinquents go on to be useful members of society, the bulk of fraud (which directly affects the financial welfare of thounsands of people) is committed by good-as-gold personnel who have proved their skill, reliability and value.
Teenage suicide is often pointed at as a "good reason" to monitor children. Pity. Constant evaluation / assessment is the direct cause of the sort of teenage pressure that causes depression, and desperate behaviour (read: criminal rebellion, self injury, suicide).
Besides, where do we draw the line on the "wrong path"? The public perception of "right path" is the suburban teenager who goes to school and works hard ... and takes a couple of drugs, has a couple of sexual relationships. Wrong is the computer geek goth, who's active interest in debauchery, child porn, and anarchy through destroy global networks must be prevented at all costs. Besides, its not normal to dress in black all the time. Ravers are, of course, okay. They only engage in orgies and do drugs, and a normal, well-adjusted teenagers, who only occasionally OD and will generally go on to be normal, well-adjusted parents who will be wife beaters and child abusers. (Okay, not necessarily, but its just as possible as any other population group).
You can only determine "wrong path" based on public perception - there is no independent, scientific criteria for "wrong path". Suddenly we could find non-Christian religions, long hair, homosexuality, or intelligent political comment being the "wrong path".
No. Monitor is NOT acceptable under any normal circumstance.
Arrays aren't all they are cracked up to be. The first thing to consider is that every consideration for a relative position involves a calculation: X = X + 1 to look at the tile to the right, for example. The second thing to consider is that the entire array must reside in memory (or you can use nasty caching algorithms).
An alternative is to use an object scenario where each tile is an object (okay, I'm not actually advocating an OBJECT object here, just a discrete instance of a data structure). There are separate fields for left/right/up/down/above/below, to allow for a dynamically sized and shaped, truely 3D map. In effect this is a 6-way linked list. Although your storage overhead is higher (since you store pointers), you can more easily swap pieces of the map into and out of memory.
The bounds checking is precalculated to some extent, in that there is simply no link for absolute boundaries. You can easily do funky stuff link linking the "move right" for one tile to a non-adjacent tile, effectively creating a "teleport" zone, without special logic. A "map within a map" scenario is fairly easy too - a whole lot of tile have their right side (say) linked to the left side of a single tile, so that moving right would "exit" to a larger map (think Wasteland). A few additions to the tile data structure can control the logic in a more fine-grained manner, to apply only to certain units or local/global conditions.
Conditions themselves can be made more modular - a weather condition for example can be represented as a layer linked above the ground level tile.
Units comprise a separate yet linked structure. All units are placed in one huge linked list. This list must be parsed at every tick to account for unit actions. Each unit then forms part of three other doubly-linked lists: the team (side, faction, whatever), group, and map. In other words, the unit will be linked in to the map, above the ground layer (or below, if applicable). Moving the unit will change its linking in the map. Regrouping, defection and all the rest should be obvious.
Under this system, a unit is in fact a tile, but with additional information. That is to say the unit must be compatible with the tile data structure (in object terms a subclass or implementor of the map tile interface).
Twylite
It always amazes me how supposedly qualified and skilled people can ask questions before making any effort to do background research. Not only does it show an inability to solve problems, but also prevents the questioner from supplying all the relevant information.
I asked Google a couple of questions and came up with GameDev.net and GameDeveloper.net, and especially the game design category at dmoz.org. Needless to say these link to a wealth of information on the topic.
I could be mistaken, but you seem to be referring to Isometric Mapping, which is a 2D, not a 3D technique. A little Googlification of that keyword should produce more interesting stuff. this article discusses formats for a map file, and this one considers data structures and memory.
Of course, the most important question is: how are you going to USE the data? Your choice of a data structure must be based on data use, especially in a real-time game where effeciency is important. Memory requirements will become a third factor for consideration.
In general when dealing with isometric maps, you model a flyweight multilayer grid. This means the basic map is broken into a 2D grid of tiles (rectangular or hexagonal), each tile is split into several ordered layers, and the information about each tile is for the most part shared with all other tiles of the same nature (the flyweight design pattern).
The most common question about data structures is whether to use a 3-dimensional array (tile-x, tile-y, layer) or to a 2-dimensional array (tile-x, tile-y) with the tile itself holding an array of layer information.
When working with very few layers, or in a situation where the information in a particular layer must be accessessed in an iterative fashion, the 3-d array tends to be better. For many layers, or a case where the information for a particular layer does not need to be filtered out as a separate grid, a 2-d map with dynamic data structures for the layer information will keep memory requirements down, and follow good design principles (don't keep multiple data structures in sync - split the data into objects).
Good luck ... now go and do your own work before asking more questions.
Twylite
Some researchers have found it may be possible to produce antimatter using femtosecond lasers. Take a look Here.
Also, for those who didn't understand the linked article too well, there is a nice article on Lycos.
Sadly, and as stupid as it may seem, disseminating copies of "The Law" is illegal (without appropriate permissions) in most countries. Printing and publishing the laws is Big Business and the government contracts to do so are worth a Lot Of Money ... so while everyone is supposed to have free (public) access to the laws (say, at your local library), copying them is a different matter.
So much for capatalism...
I've also had an experience along these lines. Several years back I was trying to get a web development company off the ground, and was in the running for a huge contract with a multinational wanting to share data publically, as well as design information over a VPN. Security was obviously paramount.
It came down to two proposals in the end, and the competitor figured out who I was, and attacked my proposal by going after me: they cited lack of experience, expertise, backup, and all the rest, basing their agument on the fact that they were a large ISP and I want representing a newly-formed corporation with few employees.
So six months later rumours were going around in the hacker community that a certain company had suffered a major hacking incident - possibly NOT a leet or script kiddie, meaning industrial espionage considering the data they apparently got hold of. Guess who ...?
Quite by chance I happened to meet with an IT representative of the company while visiting a client some weeks later. Although unofficially, they admitted that they had made a bad decision, and apologised - for what it was worth. Of course, they also made it clear that politically they couldn't change their minds.
This is unfortunately the mindset of many companies - live with a mistake and cover it up, rather than admit to a mistake and correct it. Heck - even MS is taking the latter route (bye Clippy!).
Once you've lost a contract, don't consider going after it anymore. If they come back to you, that's fine - but even that can lead to rumours flying from competitors, which is a Bad Idea (TM). My that's just my 2c worth...
There are a couple of systems that already exist. XwingML builds Java Swing interfaces from an XML specification. XUL is a similar XML-based markup supported by Mozilla. XForms is the W3C's draft standard for the next generation of web forms.
Most particularly you may want to look at UIML, which is intended as a cross-(viewing-)platform markup, supporting PCs, PDAs, etc. There is a Java viewer, and the new version seems to have some renderers for WML and HTML, but a text renderer should be possibe (if not already available).
There are several other lesser-known XML-to-GUI toolkits, such as KUIL and AUIT. Most of these are implemented in Java and map the Java Swing classes into XML (as with XwingML).
I think this is the critical point in the argument: many people argue that code is an art form, and therefore protected as "expressive speech". While code CAN be an art form, just as English CAN be an art form (poetry, drama, etc), code is primarily a means of communication.
A computer program is the communication of an algorithmic solution. In the ideal case, the program can be acted on by a computer to realise the solution - but pseudo-code or even gramatically incorrect (uncompilable) code communicates a concept accurately between experts in the field (of computer science).
If computers could act on "pure English" programs, would an English description of the deCSS algorithm be unacceptable? IS an English description unacceptable? If we approach a programming language as a means of communication (not specific to instructing the operation of a machine), we can show how ludicrous the arguments are.
Please see my full comment #661.
I think the logic is that there is always some doubt, unless the accused confesses to the crime. Hence the "reasonable doubt" principle. If caught with burglary tools, the intent to commit the crime is more obvious, and intent is always a factor that makes for easier conviction and more serious penalties.
Why and how is a computer program expressive speech?
A computer program expresses a logical, algorithmic solution to a problem.
Background:
A computer is primarily a device of automation, used to simplify repetitive or calculation intensive tasks. It has, over time, evolved into a more general purpose tool, with applications in entertainment.
The purpose of software is to control the hardware of a computer, to execute a particular task. As such, software is the solution to the problem of "mechanical" automation of the task. Some software is supporting in nature, providing for the interpretation of more complex commands: operating systems and language runtime platforms are good examples.
Computer programs would be written in "plain English", except that, given current theories of software, we have not yet overcome the complexity of allowing a computer to act based on a language as varied as a spoken language: in English in particular there are numerous exceptions to the grammar rules, and the vocabulary exceeds 140000 words.
Conversely, a computer program could be written in mathematical notition. There is even software that acts as a runtime platform to interpret mathematical notation and simplify or solve equations. Were all computer to rely exclusively on this notation however, computers would be limited (by their language) to be mere mathematical solving machines.
In order to allow for the development of more complex tasks, languages matching the complexity of the task were required. Creating a language is itself a complex task, and so computer languages have evolved to match the complexity of contemporary demands, while not themselves being too complex to implement using older generation languages.
A computer language is thus a language in all respects, having a grammar and vocabulary. The significant difference from spoken languages is that the rules and vocabulary of a computer language are typically smaller and more rigid, allowing an automaton (arguably simpler than a human being) to act on them.
Beyond the application of computer languages to computers, they have evolved to be an effecient mechamism of communication between scientists involved in algorithmic solutions. "Pseudo-code" is a notation taught at most Universities, which is familiar to "a computer language" and would be mistaken for "a computer language" by a lay-man, yet no computer or software exists to interpret it.
This pseudo-code is used to communicate to another person the essence of an algorithmic solution, and is occasionally used beyond the walls of computer science. In mathematics, for example, the Sigma (sum of) notation is often explained as (for example in the case of E(1,10)X^2) "Start with zero, and for each value of X from 1 to 10, add the square of X." Depending on the expert in question, this could be considered "pseudo-code", or alternatively rewritten as:
Y = 0
for each X from 1 to 10
Y = Y + square of X
This is true "pseudo-code", and could conceivable be implemented as a (computer-understandable) language.
Were there no computer available to interpret a "computer program", yet it still communicated meaningful information to another person, would it be considered "speech"?
Can it then follow that pseudo-code should be considered "speech", or should there be a difference because it may be possible to implement software to "understand" pseudo-code?
Will English (or any other spoken language) be restricted if software is developed to allow a computer to be fully instructed in that language?
If not (since it is a spoken language) will a language such as Latin (or Elven or Klingon) be restricted if computers are make able to understand it (since these are not considered spoken languages, but are occasionally used for written communication).
If, given the above questions/thoughts pseudo-code is to be allowed, how can a distinction be drawn between pseudo-code and "real code", given that many scientists adapt pseudo-code to look more like any particular computer language with which they are familiar?
If I leave precise, written instructions (in English) for duplicating a tape (music or movie), knowing that the receiver of the instructions most likely does not know how to do so, am I responsible for copyright infringement? Is the written instruction responsible? Is the language (English) responsible? Or is the recipient responsible if (and only if) (s)he uses the instructions to duplicate the tape illegally?
To conclude: A computer program is a description of a solution to an algorithmic problem, described in a language with a restricted grammar and vocabulary. Many other sciences have their own languages (notations, names, symbols) for communicating effectively between experts in the field. A computer program has the capability of being able to be interpretted and acted upon by a computer, allowing the solution to be realised. Scientific, engineering and financial notations have various instruments which can act upon the notations; some even have limited algorithmic capability. In each case the solution is realised by communicating with a device, in a language which is acceptable, and used, for more general communication.
Bypass #1: Disable JavaScript. Bypass #2: Read the source code, download the image directly from the URL. Bypass #3: Take a screenshot and cut out the image you want.
Lots of protection there.
Your problem isn't the 80% female over 35 audience. Its the single 15 year old linux kiddie who knows how to rip out the content, and distribute it to the 80% female over 35 audience for free (or a lot less than you charge).
...and no, the DCMA does not protect against cut & paste - that's the job of Copyright. The plug-in decrypts the information (legally) and displays it -- *then* it gets copied.
Let's not stop there :) Screenshot + OCR would do wonders for retrieving most anything you can display "securely" on a screen. Diagrams of course could be handled by a screenshot alone. I'm sure we could do that in X with a couple of piped commands and about 15 seconds worth of viewing time ...
Umm .. no, you can't. Well you CAN, but their mail server won't receive the mail for your domain. It certainly won't do virtual domain hosting, or direct all mails @the.domain to your e-mail account, whatever. For that, which means anything to do with an MX record point at a mail server, the mail server admin has to agree and configure the server appropriately.
So it comes down to: alter SMTP to support (arbitary) forwarding, or alter capatalism to get an ISP to accept mail to your virtual domain at no (low) cost. Hmmm.
Most IM systems under development could be extended to avoid spam without too much trouble. The problem is that these systems all use a centralised server/service, making your communication reliant on a single service, organisation, addressing system, whatever.
We have a perfectly valid architecture for messaging ... its called e-mail. Why aren't we extending e-mail servers to handle instant messaging (IAMOF SMTP already has IM capabilities of sorts in the SOML and SAML commands).
Its about time people thought of integration and simplification, rather than running off and writing newer and more complex protocols to force yet another icon/program onto my already cluttered desktop.
Java is ugly, sometimes, if you're doing things the language wasn't meant to do. Reflection is primarily a means to access compiled classes at runtime, and while it can be used to invoke methods dynamically, its certainly not meant to. If you want it to look pretty, make a library function. That's the only reason it looks pretty in other languages.
Gloves seem somewhat outdated in a strange way. They never caught on, and are a little cumbersome for day-to-day activity (ever tried typing in gloves?). But what about something smaller? MEMS technology is developing better and smaller solutions every day - and accelerometers could be an answer.
Instead of putting a glove on your hand, how about sticking a small IR/Bluetooth/802.11/whatever MEMS device to the back of your hand, and go for it. Wave your hand around, and have the sensors track the motion in 3D. I'm fairly certain that in time (if not already) the sensors will be sensitive and reliable enough for you to be able to select screen items by "pressing" them.
This would be a wonderful way to go for interfaces (for selection, at least, not text input), as it would work with a device of any size, and is totally portable.
My 2c on the work of hi-tech.