Oh wait! There is no science of software yet. And that is because the dragon of money has blinded and made witches and warlocks to create majic potents. Potents that give them power over the ignorant. If you sail out there, you'll fall off the edge of the world if you make it past the sea dragons....
Isn't that what you keep trying to tell me?
No, what I'm trying to tell you is that there is a science of software, which apparently you haven't investigated at all. You're focusing on the shortcomings of a relatively immature "industry" without looking at what the scientists are doing, much of which will drive what happens over the next 5, 10, and 50 years, as it has done to date.
Industry often tries to ignore the science, for reasons of its own; science usually wins in the end, because it's hard to ignore reality for long periods of time. What I'm trying to tell you, is that you shouldn't ignore the science.
I think you'd have better luck starting from scratch and comming up with a different way to preceive gravity in order to solve problems with the theory.
That's kind of my point. There are multiple theories of gravity. That's why I suggested philosophy of science as a worthwhile field of study - it might give you some perspective.
Like physical theories, when it comes to software models, most models are essentially really "views" when you get down to it, i.e. they inherently embody a particular way of looking at the problem in question. A comprehensive model can certainly be widely applied, and that's what you're claiming for your model. But if you think that's the only way of looking at it, I can safely say that you're wrong.
How do you install an app designed for Java technology without first installing JRE?
By installing a version that's been compiled to native code using a tool like the GNU Compiler for Java (GCJ)? Truth is, I haven't tried this, but it has the potential to work, since it provides a libgcj which implements the runtime, which could presumably be statically linked if you really cared about one file more or less.
How do you install a C app without first installing libc?
By installing a version that's been statically linked to a version of libc? Besides, libc is present on "all" systems, and is only a single file, so doesn't quite present the issues that installing a JRE does. A JRE is an independent program that has to be configured correctly in order to be able to run, it's not simply a file that has to be present.
You can't reasonably deny that requiring a JRE to run on top of does create extra distribution hassle which can translate to a barrier to entry for users.
Math is a subset from the spectrum of available abstractions. Would you like to deny this?
Not at all. However, the article in question is using established principles in logic and mathematics to assess the complexity of software development. It has nothing to do with constraining computers or the abstractions they use; it's more like using physics to describe phenomena we observe - it may be only one possible abstraction, but it's one we don't know how to violate. So the point is simply that there is solid evidence that developing software is a tough problem, and you won't solve the problem by railing against the computer industry and claiming that you alone have the solution.
I certainly don't think that users of computers should have to learn anything at all about computer science. However, you seem to be attempting to go beyond what users usually do, creating an apparently ambitious software framework. As such, you're no longer simply a user, whether you admit it or not; and as such, if you ignore other efforts in similar areas, you're simply making your own life more difficult and not doing anything to diminish your chances of failure.
Along those lines, you've repeatedly indicated that you consider your VIC to be some kind of absolute truth - "natural logic", "cannot avoid using", etc. Yet you seem to understand that no abstraction is all-encompassing - you alluded to that when you said "Math is a subset from the spectrum of available abstractions." Don't fall into the trap of thinking that VIC is the only way of looking at the problem you've chosen to explore. In fact, as a flexibility exercise, I'd suggest starting from scratch and coming up with a completely different way of looking at the problem. If you can't do it, it may mean that you're stuck in a rut. If you can do it, you're likely to find that your original model will be strengthened by the experience.
You've objected to the idea that you need to learn about computer science; how far do you extend that approach? For example, another field of study I can recommend, outside computer science but certainly relevant to it, is that of philosophy of science. It's worth learning and understanding how scientific theories are developed and how they evolve. Kuhn's "Structure of Scientific Revolutions" makes a good starting point. What applies to scientific theories applies equally to almost any abstract model. Formal thinking about such things can help avoid unproductive blind alleys.
But in all of these programming lanuguages, the list of programming concepts is by far, a great deal smaller
Although probably not as small as you think, based on your limited experience of programming languages and computer science. In a sense, programming encompasses the whole of mathematics, and functional programming exploits this fact. In another sense, programming is mathematics - as demonstrated by the lambda calculus, and by the Church-Turing thesis - notably, a postulate of mathematical logic rather than computer science as such.
The article on/. today about evolution and the Linux kernel (quite relevant to the discussion we've been having) included an interesting quote by Alan Cox on the linux-kernel mailing list, to the effect that engineering doesn't need science, that brick walls were being built before we understood how concrete worked. But as one of the/. postings pointed out, that led to problems, a famous example being that of the perceived need at one time for enormous "flying buttresses" to stop large cathedrals from falling apart.
There are plenty of equivalents to flying buttresses in existing computer systems; but to avoid them, and learn how to do things that don't need them, things that allow you to scale to higher levels of abstraction, you really need to learn about the fundamentals of the field. If you don't, well, again, I can only wish you the best of luck...
> I wonder how much "money" has been "donated" to
> the SETI project in this way?
Don't give the IRS any ideas. They're thuglike enough as it
Um, this would be a tax break for the people who run SETI on their PCs - you'd get to claim a donation. Of course, SETI would end up with a mammoth tax bill on all the "income" they get in the form of CPU cycles.
I appreciate your response. I'm not going argue with you point for point, but I will clarify a few things.
The reason I object to the term "software crisis" is because those who use it almost invariably go on to suggest "solutions" to this crisis which don't recognize basic realities of the underlying situation. You're doing exactly the same thing.
A paper was recently discussed here on Slashdot that gives an interesting take on the subject, and some excellent insights:
Mathematical Limits to Software Estimation. One interesting observation quoted in the paper is "The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line". Many people, apparently including yourself, would like to deny this; but until it is acknowledged, those who refuse to acknowledge it will continue to perceive a "software crisis", and continue to pursue solutions which don't ever achieve what they want, because, as has also been famously observed in the software industry, there is no silver bullet. That seminal paper says, "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any--no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware."
Before I go any further, I should qualify what I'm talking about. There are many classes of applications that are pretty much solved problems, because they have been developed over and over, and software frameworks have been developed which make it much easier to churn out variations on that particular kind of application. No-one is suggesting that no improvements in software productivity can be made - over time, the range of problems which are well-solved will certainly increase. However, the issue is that of dealing with new problems. And new problems arise more frequently than you might imagine. When it comes to simple business form-based applications, for example, the basics of such applications were essentially solved by the 1980's. However, any application written in the 1980s would have been written for environments which are now obsolete. Greater abstraction was nearly impossible back then, because the hardware simply didn't have the necessary resources. So the evolution of computers and software as a field itself creates new problems, as just one example.
The fields is still incredibly young and immature, there's no question of that. In just the last five years, things have fallen into place that were never possible or practical before, and that trend will continue for the forseeable future.
On its commercial side, plenty of "lying" takes place - it's called marketing. But there are millions of honest people, myself amongst them, who are doing our best to implement best practices and further the state of the art.
You're trying to do that too, which I applaud, but I don't applaud your attitude. Since I don't know you, I don't know what background has led you to be so antagonistic to the computer "industry". The industry is really an incredibly large and diverse ecosystem, which only superficially moves with one mind. The many languages you were complaining about earlier are a reflection of all the people who are trying hard to improve levels of abstraction and make computing a better place.
All of this has very little to do with the specific project you're apparently working on.
There is no rule of knowledge or of putting things together that says I need to study all written works ever existing in order to be smart enough to be able to put things together.
There is, in fact, a common-sense rule that's so widespread that it has a name: "reinventing the wheel". Another common sense rule is that it's dangerous to ignore a large body of work in the field in which you're attempting to innovate: can you really afford to dismiss the work of the large number of smart people that have gone before you? Are you saying that you don't need to know about prior art in order to advance the state of the art? There's another "rule of knowledge" that boils down to a single word: hubris.
I'm going to leave it at that. I wish you luck in your endeavours. If you're actually developing code, you will eventually learn some truths about software development, even if it has to be the hard way. Some reading and research could save you from a lot of dead ends.
In another message, you pointed me to your web page.
Actually, I had looked at your pages prior to writing the previous message, to make sure I wasn't missing something. I don't see anything to contradict what I was saying. In fact, there are some great examples of hand-waving on your pages: "doing stuff" qualifies as a perfect one.
All of the real problems that computer languages are designed to solve pretty much fall into the category of "doing stuff". Your nine steps don't seem to be much more than a shell architecture, or taken to their logical conclusion, a design for an operating system that has a more streamlined and integrated user interface model. Plan 9 comes to mind. Good for you.
However, this has nothing to do with solving the problems addressed by even the simplest computer language, except in exactly the sense I mentioned: every program consists of "input stuff", "do stuff", "process stuff". You've identified nine such steps - so what? Many more have been identified in work on these kinds of subjects, but it doesn't do anything to simplify real programs in any significant way, since the real work is what's done within the steps. This sort of analysis amounts to little more than an application framework, and in this case, not a particularly rich one.
I even went so far as to read some of your writings about patents. Grand visions are great and fun to play with, but it helps to have some understanding of the issues you're brainstorming about. I get the distinct impression that your formal background in these fields is limited. You might benefit from reading some of the material which I mention in this article. Some great research has been done on the sort of things you're talking about, and to ignore it would be foolish. You've written about the "failure of computer science", but you clearly don't know much computer science, so don't seem to be qualified to make such a claim.
Related to the material I mention in the above-linked message, you might find SCSH (Scheme shell) relevant to your work on VIC. Scheme's hygenic macro capability and support for developing higher-level languages within Scheme lends itself quite nicely to this sort of work - if you want to be able to create and manipulate abstractions, Scheme provides an excellent language to do that in. Learning Scheme is also a wonderful doorway to advanced directions in current language research.
You've made reference to computer science and related fields being elitist - but given the free availability of so much research and educational writing, the only qualification for entry is the ability to understand. If you don't have that, that doesn't make the field elitist, it just means that you need to seriously consider whether this sort of work is really what you're suited to. If I wanted to be a carpenter yet was incapable of visualizing or dealing with 3D forms, so that the items I built collapsed, what would your advice to me be? Would I be justified in suggesting that carpentry is elitist, that carpenters are imposing arbitrary requirements on the field, and that I ought to be able to build things without knowing any of the boring and petty details of carpentry?
---
"The mark of a truly intelligent person is the ability to introspect realistically."
I didn't create or define the term "software crisis"
No, but you used it as though you believed it. In my experience, now that it's no longer the '60s or '70s, the phrase gets thrown around by people who know little about software development, usually to sell a product or idea.
Translation simply takes whatever you have written and converts it into the optimum bit sequence for the machine to deal with.
Or for that matter, Translation from whatever form to whatever target form that is defined. Like Human to human Translations (i.e. English voice input to german audio/spoken output.)
The translation mechanics are going to be the same.
You might want to read Joel Spolsky's piece on "Architecture Astronauts". Suggesting that all translation from any language to any other language involves the same translation mechanics, to me simply indicates that you've never actually done any work or studying in this field, and are indulging in armchair speculation. Any abstraction at that level will be essentially useless to the task of actually translating the material in question.
Take a look at what's involved in rewriting code in a functional language to a compiled form - an area that's enjoyed a lot of academic attention - and compare that to tools which translate human languages. The commonality there is minimal, at the level of stratospheric overviews like "get input; translate input; produce output". Architecture astronauting indeed! Dare I point out that all computation follows this pattern - "translating" a problem into a solution - so once your universal translation mechanics have been developed, we'll never have to write another line of code? "O great translation mechanics, what is the answer to the question of life, the universe, and everything?" Sounds good, let me know when you're done!
With all this in mind, what are all these "Lightweight Languages", but examples of how many ways you can create a custom vocabulary, syntax and translator that outputs 0's and 1's not always in the optimum sequence?
You completely miss the point. If you want to address your so-called software crisis - which is only a crisis when you have unrealistic expectations, based on ignorance or denial of the issues being faced - then you need to provide humans with languages that allow them to express programs in powerful ways, that make programming easier and more reliable. Focusing on the 1's and 0's completely misses the fact that the challenges lie at the level at which the humans controlling the machines operate.
Academia has produced many innovations in these areas. All modern mainstream languages can benefit from these "new" language technologies (some of which are actually decades old). The LL1 workshop was about communicating between those who have developed sophisticated and powerful ways of dealing with language problems, and those who have a record of having implemented languages that are popular with humans - languages that are used not because of mandate from on high, but because they're perceived as easy to use and also powerful, and thus desirable to use.
An additional interesting element here is that the mainstream "Lightweight Lanugages", like Perl and Python, have a better track record than the big commercial languages of incorporating these ideas - witness the fact that Perl and Python support advanced capabilities such as closures and continuations, whereas other recent languages, like Java, have limited to nonexistent support for such things.
A collaboration between the authors of mainstream lightweight languages, and academic language researchers, opens the possibility to accelerate language development in a sorely needed way - instead of innovations taking literally decades to make their way from academia to the mainstream (e.g. the way object-orientation did), this lead time could be reduced to mere years.
In addition, via lightweight languages, these features would be delivered in a form more palatable to the audience consuming them. Lightweight languages tend to recognize the pragmatic needs of their users, as opposed to imposing restrictions based on aesthetic constraints such as "elegance".
In summary, the plethora of lightweight languages is a simple reflection of a dynamic and fast-evolving ecosystem, an absolute requirement for further progress in the extremely complex endeavour of humans programming machines.
...especially since real languages frequently have to do things that don't make for terribly fascinating research.
Actually, I think this is flat wrong. Can you think of an example? Just about every aspect that current "real" languages implement has been researched to death - and then some.
You don't get to the cutting edge of programming lanugage implementation by wasting your time reading the many years of esoteric research published on the subject
If you're a professional language designer - and I know a few - and you don't do this, you're pretty much doomed to failure, because someone who knows what they're doing is going to come along and eat your lunch. Java is a case in point - one of the designers was Guy Steele, co-inventor of Scheme. He knew what he was doing, and although Java is chock-full of interesting and questionable compromises, it still blows away many other "real" languages.
Isn't it ironic that Isn't it Ironic isn't ironic?
If so, then Isn't it Ironic is a rare example of meta-irony in art (or pop).
And isn't it ironic that Isn't it Ironic, by being meta-ironic rather than simply ironic, further confused people about what is and isn't ironic?
The research is there for the taking!!
on
Lightweight Languages
·
· Score: 4, Interesting
I am asking because I don't know. My suspicion, however, is that most of this knowledge is locked in high-priced peer-reviewed journals, overpriced textbooks, and papers distributed among an elite group, rather than being released freely to the community of developers who work on free software.
You couldn't be further from the truth. Someone's already mentioned CiteSeer. I've read and downloaded hundreds of papers from there. Google is great for tracking down papers, too.
Another nice resource is library.readscheme.org. It's Scheme-specific, but Scheme is the root of much research about programming languages and the underlying concepts - it pretty much spawned the field of functional programming.
The biggest barrier to entry for this sort of stuff is your own existing knowledge. There's no pill you can take to pick it all up overnight. You have to work hard at it. This is the real reason to go to a real universities - not to learn how to program in the language du jour, but to learn about what some very smart people have already figured out over decades, centuries, millenia, and to learn how to think like those people.
There aren't many shortcuts here. It doesn't help to be told that there's a simple solution to the problem you're working on, if it involves a network of deep concepts you've never heard of and are totally unfamiliar with. To take some examples from functional programming: closures, continuations, continuation passing style, fold operators, polymorphic type inference... If you don't know what all those things mean, and can't use them in your code, you're unnecessarily limiting yourself and denying yourself leverage that can help get big, complicated things done more quickly, with less fuss.
One way to start out is to learn some advanced languages. Scheme is a good starting point because there's so much tutorial literature for it. You can pick up the computer science concepts as you go along. Read Structure and Interpretation of Computer Programs (SICP) and How to Design Programs (HTDP). Join the ACM.
There's so much stuff out there, go look for it, and apply yourself!
The lightest computer mathematically proven to be equivalent to any other lanuage is the Turing machine,
This depends on how you define it. Lambda calculus is a contender for the same title, and in fact has largely superseded the Turing Machine as a model for computation.
If your metric is the size of the compiler, a Turing machine might win on current hardware - but that's at least in part because standard hardware has a similar architecture to a Turing machine. Someone should build a lambda calculus CPU... (No, Lisp chips don't qualify.)
Lambda calculus is certainly easier for humans to program in, and is more expressive in that it supports functions and named parameters. So I would say LC is the lightest, most powerful language that's easily usable by humans.
That'd be gamma rays. Microwaves would just cook your flesh, which certainly could stop you from having kids, but you'd probably notice something was up.
I'm not going to spend the time to look this up, but my memory is that there have been some real, documented cases of people picking up audible radio signals with the metal fillings in their teeth. I know that this story has urban legend status, but I thought it was based on some real cases, possibly using different alloys than what's used these days.
Perhaps someone else can jump in and expand on this or correct me...
Without Neuromancer, Slashdot wouldn't exist today; Linux wouldn't; the dot-com boom that paid for most of our college educations and/or BMWs wouldn't have existed.
I'm a big Neuromancer, Gibson, Stephenson etc. fan, but I think your statement is way too strong. Neuromancer might have provided a social context for some subcultures, as you suggest, but I fail to see how, say, Linux wouldn't have existed without Neuromancer.
In general, I think authors are often given too much credit for both "predicting" and inventing things in their work. The canonical example is Clarke's communication satellites. That may very well have been a real invention, which he might even have patented. Most work in books, though, is nowhere near as original as that. What the best speculative authors mostly do amount to thought experiments which integrate and extrapolate from current trends. In some cases, such as Neuromancer, this is done well enough that the result ends up with strong echoes of something that subsequently happens. This doesn't mean that Neuromancer caused those things. It can mean that it influenced the way many people thought about them, though.
I would think in many situations, universities could play both sides of the fence: make systems available as open source, but charge money to license code to companies that want to package it without source, in proprietary products (the SleepyCat approach that was discussed here recently).
This approach has a better chance of working for universities than it does for ordinary commercial enterprises, for at least two reasons:
The sort of software universities produce is more likely to be the kind of code that will be integrated into other systems, which lends itself to a dual licensing approach. Universities aren't selling shrinkwrapped software to consumers: they're selling more basic technology to companies that want to exploit it commercially. This could be perfectly suited to a dual licensing approach. Legitimate businesses, for the most part, are unlikely to try to base products on software that they don't have rights to.
Universities don't rely on software licensing for their entire livelihood, so if an open source strategy happens to result in somewhat lower revenues, they can handle it. However, open source may be one of the best and cheapest ways of "advertising" a university's software products, so these factors could balance out.
Besides, this is exactly the sort of issue on which we should look to universities to lead the way. Open source is an important form of cooperation, and its heritage is the very academic freedom and open sharing of information pioneered by universities. There are benefits to this cooperation that may not be completely in conflict with the profit motive; however, the truth of that claim can only be verified by those with sufficient vision to look beyond the next quarter's results. Universities are one of the few organizations which have both the vision and financial ability to do that. MIT's recent decision to make its course material freely available over the web is an example of this.
The people who spend that time and money only to crash immediately are simply impatient and overconfident.
There is excellent simulator software available, such as RealFlight Deluxe and CSM. If you learn to fly a helicopter in one of these, flying one in real life will be much easier and safer.
When first flying a real R/C heli, you use training gear which cushions landings. Initial learning should be done with the pitch of the rotors set so that the heli physically cannot lift off the ground, but the student can nevertheless experiment with the controls and learn to hover without getting far enough off the ground to do any damage to the heli.
Done properly, it can be learned without mishaps. I confess to having a couple of incidents early on with my heli - trashed rotor blades by hitting a tree, and separately got stuck in a tree due to a loose servo linkage (an oversight during maintenance). And certainly, as you become more advanced and are flying for real, accidents will happen. Depending on your heli, an average minor accident - such as trashed rotors and perhaps a few bent or cracked bits - might cost $50 - $100 to repair.
The problem that many people run into is not researching it or getting advice or training. They go into it with the attitude "how hard could it be?", and they soon find out! It takes knowledge which needs to be learned, and if you make little or no effort to learn, you will fail.
Re:What should be required to back up a story?
on
Message from Kabul
·
· Score: 2
Frankly, that's a pretty heavy burden of evidence to place on any journalist and especially here on Slash-(We'll post obvious product advertising literature sent from company email addresses)-dot.
You're confusing issues here. Katz is claiming something factual, which I'm questioning based on apparent contradictions in allegedly factual statements he made. The posting of links to undigested press releases on/. is not making a false claim about facts, especially if the editor simply quotes and attributes a submission. If Katz had actually quoted some or all of the email in question, that would have gone a long way towards at least allowing some determination of its likely authenticity. Basically, as it stands, we have to trust Katz to have correctly assessed whether or not this was a hoax. Having read some of Katz's writings, I don't have sufficient faith in his critical thinking abilities to trust his assessment, given the limited solid information he provided.
I'd be curious what sort of evidentiary standard reporters are generally held to at upstanding newspapers and magazines.
Perhaps the fact that you're not familiar with this sort of thing is why we're having this discussion. Upstanding news sources have professional fact-checkers and editors on staff, who are alert for basic issues like the ones we're discussing here - suspicious and contradictory facts based on a tenuous source - and much more - things like etiquette, proper attribution, corroborating evidence, consistency, etc. Real journalists certainly have to deal with hoaxes, and that's one of the things that fact-checkers deal with.
Of course, it goes without saying that/. has no such formal process, beyond the individual efforts of the editors who post stories. Katz in particular suffers badly from not having an editor or fact-checker going over his work, and he really isn't good enough to go it alone. In fact, the only piece I ever read by Katz which I thought was well done was in Brill's Content, a (now-defunct?) print magazine, in which I am almost certain Katz was edited, possibly quite heavily. Either that, or he had to stick to a length constraint, and the discipline must have been good for him.
Re:Not to sound like an asshole, but...
on
Message from Kabul
·
· Score: 2
No! I won't go around taking surveys on people's happiness worldwide!
That's fine, but if others wish to do so and act on what they find, sitting in your armchair complaining about people helping other people is rather ludicrous.
You mean the tiny portion of the world that hasn't already moved here. Everyone wants to be American.
That's an overstatement, but it's kind of my point. The reason people want to move to America is because it offers a relatively high degree of religious, economic, and political freedom. But America props up governments which don't allow this, to suit its oil interests (e.g. Saudi Arabia), and fosters internal rebellion when it harms their enemies (Afghanistan and the Soviet Union), but it doesn't necessarily actually help to improve the situation in the countries it ostensibly "helps". In more recent years, since the collapse of the Soviet Union, policy has improved, but it still ultimately derives from a time when the US's policy goals were very different. It needs revamping, and time and again it has been demonstrated that isolationism and non-involvement are not the answer.
Actually, I think the direction in which U.S. policy is now developing is positive - some of the things I'm talking about are being more actively considered, such as the establishment of a stable government in Afghanistan. This is based on experience with mistakes in the past.
The last time we got international backing for anything (before 9/11) was when the Axis Powers were kicking ass worldwide.
It depends how you define it. For example, the US had United Nations support for the actions against Iraq after the invasion of Kuwait, and NATO support (at least) for Kosovo. Perhaps you're suggesting that this support was not sufficiently great, financially or in terms of military resources provided. However, if the U.S. had a clearer policy that went beyond its own direct interests, it would more easily be able to obtain real support from other countries.
Note that going beyond the "direct interests" of the U.S. doesn't necessarily imply being purely
humanitarian or altruistic. Rather, it recognizes that these issues are complex and intertwining, and can have very long-term implications. It may be unwise to take too narrow a view based only on the most obvious short-term payoff or lack thereof.
Re:Not to sound like an asshole, but...
on
Message from Kabul
·
· Score: 3, Insightful
What business is it of ours how women are treated in Afghanistan?
It may not be any business of yours, but I'm making it my business. You can try to stop me, but you won't do so with words.
If your only issue is whether the people in these places want change, that's an easy question to answer: they do, go visit one of these countries sometime and ask.
If you were truly correct that the people in these societies liked the conditions they lived under, it would be a different matter. The fact is, though, most of them don't; however, brutal police states, corrupt governments, and lack of resources stops most of them from doing anything about it.
I've travelled and lived in Africa, and travelled in the Middle East, and what you often see is similar to what used to happen in the Soviet Union: people do the things people do anyway, if they can get away with it, but they do it underground and at serious risk to their lives and freedom. You may not care about this, but having lived in environments like this, I do.
And, despite your belief that "putting our nose in somebody else's business" got us into this, one can make a credible argument for the opposite being true: the U.S. has remained too hands-off in its foreign policy, only getting involved when it has a clear, direct strategic interest in a particular situation. The reasons for this foreign policy date back to World War II and Vietnam. However, this may not be in the the US's own interest. It means that from the point of view of people in other countries, US involvement is capricious and unpredictable, leading to resentment when the US does or doesn't get involved in a situation where others think it should or shouldn't.
A policy based more clearly on things like human rights interest could actually go a long way towards improving America's reputation in the rest of the world, and would not necessarily cost significantly more money, since America could certainly get international backing and cooperation for such a policy.
Slashdot Mirror
Isn't that what you keep trying to tell me?
No, what I'm trying to tell you is that there is a science of software, which apparently you haven't investigated at all. You're focusing on the shortcomings of a relatively immature "industry" without looking at what the scientists are doing, much of which will drive what happens over the next 5, 10, and 50 years, as it has done to date.
Industry often tries to ignore the science, for reasons of its own; science usually wins in the end, because it's hard to ignore reality for long periods of time. What I'm trying to tell you, is that you shouldn't ignore the science.
That's kind of my point. There are multiple theories of gravity. That's why I suggested philosophy of science as a worthwhile field of study - it might give you some perspective.
Like physical theories, when it comes to software models, most models are essentially really "views" when you get down to it, i.e. they inherently embody a particular way of looking at the problem in question. A comprehensive model can certainly be widely applied, and that's what you're claiming for your model. But if you think that's the only way of looking at it, I can safely say that you're wrong.
By installing a version that's been compiled to native code using a tool like the GNU Compiler for Java (GCJ)? Truth is, I haven't tried this, but it has the potential to work, since it provides a libgcj which implements the runtime, which could presumably be statically linked if you really cared about one file more or less.
How do you install a C app without first installing libc?
By installing a version that's been statically linked to a version of libc? Besides, libc is present on "all" systems, and is only a single file, so doesn't quite present the issues that installing a JRE does. A JRE is an independent program that has to be configured correctly in order to be able to run, it's not simply a file that has to be present.
You can't reasonably deny that requiring a JRE to run on top of does create extra distribution hassle which can translate to a barrier to entry for users.
Not at all. However, the article in question is using established principles in logic and mathematics to assess the complexity of software development. It has nothing to do with constraining computers or the abstractions they use; it's more like using physics to describe phenomena we observe - it may be only one possible abstraction, but it's one we don't know how to violate. So the point is simply that there is solid evidence that developing software is a tough problem, and you won't solve the problem by railing against the computer industry and claiming that you alone have the solution.
I certainly don't think that users of computers should have to learn anything at all about computer science. However, you seem to be attempting to go beyond what users usually do, creating an apparently ambitious software framework. As such, you're no longer simply a user, whether you admit it or not; and as such, if you ignore other efforts in similar areas, you're simply making your own life more difficult and not doing anything to diminish your chances of failure.
Along those lines, you've repeatedly indicated that you consider your VIC to be some kind of absolute truth - "natural logic", "cannot avoid using", etc. Yet you seem to understand that no abstraction is all-encompassing - you alluded to that when you said "Math is a subset from the spectrum of available abstractions." Don't fall into the trap of thinking that VIC is the only way of looking at the problem you've chosen to explore. In fact, as a flexibility exercise, I'd suggest starting from scratch and coming up with a completely different way of looking at the problem. If you can't do it, it may mean that you're stuck in a rut. If you can do it, you're likely to find that your original model will be strengthened by the experience.
You've objected to the idea that you need to learn about computer science; how far do you extend that approach? For example, another field of study I can recommend, outside computer science but certainly relevant to it, is that of philosophy of science. It's worth learning and understanding how scientific theories are developed and how they evolve. Kuhn's "Structure of Scientific Revolutions" makes a good starting point. What applies to scientific theories applies equally to almost any abstract model. Formal thinking about such things can help avoid unproductive blind alleys.
But in all of these programming lanuguages, the list of programming concepts is by far, a great deal smaller
Although probably not as small as you think, based on your limited experience of programming languages and computer science. In a sense, programming encompasses the whole of mathematics, and functional programming exploits this fact. In another sense, programming is mathematics - as demonstrated by the lambda calculus, and by the Church-Turing thesis - notably, a postulate of mathematical logic rather than computer science as such.
The article on /. today about evolution and the Linux kernel (quite relevant to the discussion we've been having) included an interesting quote by Alan Cox on the linux-kernel mailing list, to the effect that engineering doesn't need science, that brick walls were being built before we understood how concrete worked. But as one of the /. postings pointed out, that led to problems, a famous example being that of the perceived need at one time for enormous "flying buttresses" to stop large cathedrals from falling apart.
There are plenty of equivalents to flying buttresses in existing computer systems; but to avoid them, and learn how to do things that don't need them, things that allow you to scale to higher levels of abstraction, you really need to learn about the fundamentals of the field. If you don't, well, again, I can only wish you the best of luck...
> I wonder how much "money" has been "donated" to
Don't give the IRS any ideas. They're thuglike enough as it> the SETI project in this way?
Um, this would be a tax break for the people who run SETI on their PCs - you'd get to claim a donation. Of course, SETI would end up with a mammoth tax bill on all the "income" they get in the form of CPU cycles.
...my Microstatic Dweebelizer works just fine, thank you!
The reason I object to the term "software crisis" is because those who use it almost invariably go on to suggest "solutions" to this crisis which don't recognize basic realities of the underlying situation. You're doing exactly the same thing.
A paper was recently discussed here on Slashdot that gives an interesting take on the subject, and some excellent insights: Mathematical Limits to Software Estimation. One interesting observation quoted in the paper is "The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line". Many people, apparently including yourself, would like to deny this; but until it is acknowledged, those who refuse to acknowledge it will continue to perceive a "software crisis", and continue to pursue solutions which don't ever achieve what they want, because, as has also been famously observed in the software industry, there is no silver bullet. That seminal paper says, "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any--no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware."
Before I go any further, I should qualify what I'm talking about. There are many classes of applications that are pretty much solved problems, because they have been developed over and over, and software frameworks have been developed which make it much easier to churn out variations on that particular kind of application. No-one is suggesting that no improvements in software productivity can be made - over time, the range of problems which are well-solved will certainly increase. However, the issue is that of dealing with new problems. And new problems arise more frequently than you might imagine. When it comes to simple business form-based applications, for example, the basics of such applications were essentially solved by the 1980's. However, any application written in the 1980s would have been written for environments which are now obsolete. Greater abstraction was nearly impossible back then, because the hardware simply didn't have the necessary resources. So the evolution of computers and software as a field itself creates new problems, as just one example.
The fields is still incredibly young and immature, there's no question of that. In just the last five years, things have fallen into place that were never possible or practical before, and that trend will continue for the forseeable future.
On its commercial side, plenty of "lying" takes place - it's called marketing. But there are millions of honest people, myself amongst them, who are doing our best to implement best practices and further the state of the art.
You're trying to do that too, which I applaud, but I don't applaud your attitude. Since I don't know you, I don't know what background has led you to be so antagonistic to the computer "industry". The industry is really an incredibly large and diverse ecosystem, which only superficially moves with one mind. The many languages you were complaining about earlier are a reflection of all the people who are trying hard to improve levels of abstraction and make computing a better place.
All of this has very little to do with the specific project you're apparently working on.
There is no rule of knowledge or of putting things together that says I need to study all written works ever existing in order to be smart enough to be able to put things together.
There is, in fact, a common-sense rule that's so widespread that it has a name: "reinventing the wheel". Another common sense rule is that it's dangerous to ignore a large body of work in the field in which you're attempting to innovate: can you really afford to dismiss the work of the large number of smart people that have gone before you? Are you saying that you don't need to know about prior art in order to advance the state of the art? There's another "rule of knowledge" that boils down to a single word: hubris.
I'm going to leave it at that. I wish you luck in your endeavours. If you're actually developing code, you will eventually learn some truths about software development, even if it has to be the hard way. Some reading and research could save you from a lot of dead ends.
Actually, I had looked at your pages prior to writing the previous message, to make sure I wasn't missing something. I don't see anything to contradict what I was saying. In fact, there are some great examples of hand-waving on your pages: "doing stuff" qualifies as a perfect one.
All of the real problems that computer languages are designed to solve pretty much fall into the category of "doing stuff". Your nine steps don't seem to be much more than a shell architecture, or taken to their logical conclusion, a design for an operating system that has a more streamlined and integrated user interface model. Plan 9 comes to mind. Good for you.
However, this has nothing to do with solving the problems addressed by even the simplest computer language, except in exactly the sense I mentioned: every program consists of "input stuff", "do stuff", "process stuff". You've identified nine such steps - so what? Many more have been identified in work on these kinds of subjects, but it doesn't do anything to simplify real programs in any significant way, since the real work is what's done within the steps. This sort of analysis amounts to little more than an application framework, and in this case, not a particularly rich one.
I even went so far as to read some of your writings about patents. Grand visions are great and fun to play with, but it helps to have some understanding of the issues you're brainstorming about. I get the distinct impression that your formal background in these fields is limited. You might benefit from reading some of the material which I mention in this article. Some great research has been done on the sort of things you're talking about, and to ignore it would be foolish. You've written about the "failure of computer science", but you clearly don't know much computer science, so don't seem to be qualified to make such a claim.
Related to the material I mention in the above-linked message, you might find SCSH (Scheme shell) relevant to your work on VIC. Scheme's hygenic macro capability and support for developing higher-level languages within Scheme lends itself quite nicely to this sort of work - if you want to be able to create and manipulate abstractions, Scheme provides an excellent language to do that in. Learning Scheme is also a wonderful doorway to advanced directions in current language research.
You've made reference to computer science and related fields being elitist - but given the free availability of so much research and educational writing, the only qualification for entry is the ability to understand. If you don't have that, that doesn't make the field elitist, it just means that you need to seriously consider whether this sort of work is really what you're suited to. If I wanted to be a carpenter yet was incapable of visualizing or dealing with 3D forms, so that the items I built collapsed, what would your advice to me be? Would I be justified in suggesting that carpentry is elitist, that carpenters are imposing arbitrary requirements on the field, and that I ought to be able to build things without knowing any of the boring and petty details of carpentry?
---
"The mark of a truly intelligent person is the ability to introspect realistically."
No, but you used it as though you believed it. In my experience, now that it's no longer the '60s or '70s, the phrase gets thrown around by people who know little about software development, usually to sell a product or idea.
Translation simply takes whatever you have written and converts it into the optimum bit sequence for the machine to deal with.
Or for that matter, Translation from whatever form to whatever target form that is defined. Like Human to human Translations (i.e. English voice input to german audio/spoken output.)
The translation mechanics are going to be the same.
You might want to read Joel Spolsky's piece on "Architecture Astronauts". Suggesting that all translation from any language to any other language involves the same translation mechanics, to me simply indicates that you've never actually done any work or studying in this field, and are indulging in armchair speculation. Any abstraction at that level will be essentially useless to the task of actually translating the material in question.
Take a look at what's involved in rewriting code in a functional language to a compiled form - an area that's enjoyed a lot of academic attention - and compare that to tools which translate human languages. The commonality there is minimal, at the level of stratospheric overviews like "get input; translate input; produce output". Architecture astronauting indeed! Dare I point out that all computation follows this pattern - "translating" a problem into a solution - so once your universal translation mechanics have been developed, we'll never have to write another line of code? "O great translation mechanics, what is the answer to the question of life, the universe, and everything?" Sounds good, let me know when you're done!
You completely miss the point. If you want to address your so-called software crisis - which is only a crisis when you have unrealistic expectations, based on ignorance or denial of the issues being faced - then you need to provide humans with languages that allow them to express programs in powerful ways, that make programming easier and more reliable. Focusing on the 1's and 0's completely misses the fact that the challenges lie at the level at which the humans controlling the machines operate.
Academia has produced many innovations in these areas. All modern mainstream languages can benefit from these "new" language technologies (some of which are actually decades old). The LL1 workshop was about communicating between those who have developed sophisticated and powerful ways of dealing with language problems, and those who have a record of having implemented languages that are popular with humans - languages that are used not because of mandate from on high, but because they're perceived as easy to use and also powerful, and thus desirable to use.
An additional interesting element here is that the mainstream "Lightweight Lanugages", like Perl and Python, have a better track record than the big commercial languages of incorporating these ideas - witness the fact that Perl and Python support advanced capabilities such as closures and continuations, whereas other recent languages, like Java, have limited to nonexistent support for such things.
A collaboration between the authors of mainstream lightweight languages, and academic language researchers, opens the possibility to accelerate language development in a sorely needed way - instead of innovations taking literally decades to make their way from academia to the mainstream (e.g. the way object-orientation did), this lead time could be reduced to mere years.
In addition, via lightweight languages, these features would be delivered in a form more palatable to the audience consuming them. Lightweight languages tend to recognize the pragmatic needs of their users, as opposed to imposing restrictions based on aesthetic constraints such as "elegance".
In summary, the plethora of lightweight languages is a simple reflection of a dynamic and fast-evolving ecosystem, an absolute requirement for further progress in the extremely complex endeavour of humans programming machines.
Actually, I think this is flat wrong. Can you think of an example? Just about every aspect that current "real" languages implement has been researched to death - and then some.
You don't get to the cutting edge of programming lanugage implementation by wasting your time reading the many years of esoteric research published on the subject
If you're a professional language designer - and I know a few - and you don't do this, you're pretty much doomed to failure, because someone who knows what they're doing is going to come along and eat your lunch. Java is a case in point - one of the designers was Guy Steele, co-inventor of Scheme. He knew what he was doing, and although Java is chock-full of interesting and questionable compromises, it still blows away many other "real" languages.
If so, then Isn't it Ironic is a rare example of meta-irony in art (or pop).
And isn't it ironic that Isn't it Ironic, by being meta-ironic rather than simply ironic, further confused people about what is and isn't ironic?
You couldn't be further from the truth. Someone's already mentioned CiteSeer. I've read and downloaded hundreds of papers from there. Google is great for tracking down papers, too.
Another nice resource is library.readscheme.org. It's Scheme-specific, but Scheme is the root of much research about programming languages and the underlying concepts - it pretty much spawned the field of functional programming.
The biggest barrier to entry for this sort of stuff is your own existing knowledge. There's no pill you can take to pick it all up overnight. You have to work hard at it. This is the real reason to go to a real universities - not to learn how to program in the language du jour, but to learn about what some very smart people have already figured out over decades, centuries, millenia, and to learn how to think like those people.
There aren't many shortcuts here. It doesn't help to be told that there's a simple solution to the problem you're working on, if it involves a network of deep concepts you've never heard of and are totally unfamiliar with. To take some examples from functional programming: closures, continuations, continuation passing style, fold operators, polymorphic type inference... If you don't know what all those things mean, and can't use them in your code, you're unnecessarily limiting yourself and denying yourself leverage that can help get big, complicated things done more quickly, with less fuss.
One way to start out is to learn some advanced languages. Scheme is a good starting point because there's so much tutorial literature for it. You can pick up the computer science concepts as you go along. Read Structure and Interpretation of Computer Programs (SICP) and How to Design Programs (HTDP). Join the ACM. There's so much stuff out there, go look for it, and apply yourself!
This depends on how you define it. Lambda calculus is a contender for the same title, and in fact has largely superseded the Turing Machine as a model for computation.
If your metric is the size of the compiler, a Turing machine might win on current hardware - but that's at least in part because standard hardware has a similar architecture to a Turing machine. Someone should build a lambda calculus CPU... (No, Lisp chips don't qualify.)
Lambda calculus is certainly easier for humans to program in, and is more expressive in that it supports functions and named parameters. So I would say LC is the lightest, most powerful language that's easily usable by humans.
That'd be gamma rays. Microwaves would just cook your flesh, which certainly could stop you from having kids, but you'd probably notice something was up.
Perhaps someone else can jump in and expand on this or correct me...
...whether we can imagine a Beowulf cluster of these?
You may as well question, I dunno, the flavor of Applejacks or something!
I'm a big Neuromancer, Gibson, Stephenson etc. fan, but I think your statement is way too strong. Neuromancer might have provided a social context for some subcultures, as you suggest, but I fail to see how, say, Linux wouldn't have existed without Neuromancer.
In general, I think authors are often given too much credit for both "predicting" and inventing things in their work. The canonical example is Clarke's communication satellites. That may very well have been a real invention, which he might even have patented. Most work in books, though, is nowhere near as original as that. What the best speculative authors mostly do amount to thought experiments which integrate and extrapolate from current trends. In some cases, such as Neuromancer, this is done well enough that the result ends up with strong echoes of something that subsequently happens. This doesn't mean that Neuromancer caused those things. It can mean that it influenced the way many people thought about them, though.
This approach has a better chance of working for universities than it does for ordinary commercial enterprises, for at least two reasons:
Besides, this is exactly the sort of issue on which we should look to universities to lead the way. Open source is an important form of cooperation, and its heritage is the very academic freedom and open sharing of information pioneered by universities. There are benefits to this cooperation that may not be completely in conflict with the profit motive; however, the truth of that claim can only be verified by those with sufficient vision to look beyond the next quarter's results. Universities are one of the few organizations which have both the vision and financial ability to do that. MIT's recent decision to make its course material freely available over the web is an example of this.
HKEY_CURRENT_USER/Software/Microsoft/Command Processor/CompletionChar
To a REG_DWORD value of 0x9. This works on WinNT 4; other versions may vary.
There is excellent simulator software available, such as RealFlight Deluxe and CSM. If you learn to fly a helicopter in one of these, flying one in real life will be much easier and safer.
When first flying a real R/C heli, you use training gear which cushions landings. Initial learning should be done with the pitch of the rotors set so that the heli physically cannot lift off the ground, but the student can nevertheless experiment with the controls and learn to hover without getting far enough off the ground to do any damage to the heli.
Done properly, it can be learned without mishaps. I confess to having a couple of incidents early on with my heli - trashed rotor blades by hitting a tree, and separately got stuck in a tree due to a loose servo linkage (an oversight during maintenance). And certainly, as you become more advanced and are flying for real, accidents will happen. Depending on your heli, an average minor accident - such as trashed rotors and perhaps a few bent or cracked bits - might cost $50 - $100 to repair.
The problem that many people run into is not researching it or getting advice or training. They go into it with the attitude "how hard could it be?", and they soon find out! It takes knowledge which needs to be learned, and if you make little or no effort to learn, you will fail.
You're confusing issues here. Katz is claiming something factual, which I'm questioning based on apparent contradictions in allegedly factual statements he made. The posting of links to undigested press releases on /. is not making a false claim about facts, especially if the editor simply quotes and attributes a submission. If Katz had actually quoted some or all of the email in question, that would have gone a long way towards at least allowing some determination of its likely authenticity. Basically, as it stands, we have to trust Katz to have correctly assessed whether or not this was a hoax. Having read some of Katz's writings, I don't have sufficient faith in his critical thinking abilities to trust his assessment, given the limited solid information he provided.
I'd be curious what sort of evidentiary standard reporters are generally held to at upstanding newspapers and magazines.
Perhaps the fact that you're not familiar with this sort of thing is why we're having this discussion. Upstanding news sources have professional fact-checkers and editors on staff, who are alert for basic issues like the ones we're discussing here - suspicious and contradictory facts based on a tenuous source - and much more - things like etiquette, proper attribution, corroborating evidence, consistency, etc. Real journalists certainly have to deal with hoaxes, and that's one of the things that fact-checkers deal with.
Of course, it goes without saying that /. has no such formal process, beyond the individual efforts of the editors who post stories. Katz in particular suffers badly from not having an editor or fact-checker going over his work, and he really isn't good enough to go it alone. In fact, the only piece I ever read by Katz which I thought was well done was in Brill's Content, a (now-defunct?) print magazine, in which I am almost certain Katz was edited, possibly quite heavily. Either that, or he had to stick to a length constraint, and the discipline must have been good for him.
That's an overstatement, but it's kind of my point. The reason people want to move to America is because it offers a relatively high degree of religious, economic, and political freedom. But America props up governments which don't allow this, to suit its oil interests (e.g. Saudi Arabia), and fosters internal rebellion when it harms their enemies (Afghanistan and the Soviet Union), but it doesn't necessarily actually help to improve the situation in the countries it ostensibly "helps". In more recent years, since the collapse of the Soviet Union, policy has improved, but it still ultimately derives from a time when the US's policy goals were very different. It needs revamping, and time and again it has been demonstrated that isolationism and non-involvement are not the answer.
Actually, I think the direction in which U.S. policy is now developing is positive - some of the things I'm talking about are being more actively considered, such as the establishment of a stable government in Afghanistan. This is based on experience with mistakes in the past.
It depends how you define it. For example, the US had United Nations support for the actions against Iraq after the invasion of Kuwait, and NATO support (at least) for Kosovo. Perhaps you're suggesting that this support was not sufficiently great, financially or in terms of military resources provided. However, if the U.S. had a clearer policy that went beyond its own direct interests, it would more easily be able to obtain real support from other countries.
Note that going beyond the "direct interests" of the U.S. doesn't necessarily imply being purely humanitarian or altruistic. Rather, it recognizes that these issues are complex and intertwining, and can have very long-term implications. It may be unwise to take too narrow a view based only on the most obvious short-term payoff or lack thereof.
It may not be any business of yours, but I'm making it my business. You can try to stop me, but you won't do so with words.
If your only issue is whether the people in these places want change, that's an easy question to answer: they do, go visit one of these countries sometime and ask.
If you were truly correct that the people in these societies liked the conditions they lived under, it would be a different matter. The fact is, though, most of them don't; however, brutal police states, corrupt governments, and lack of resources stops most of them from doing anything about it.
I've travelled and lived in Africa, and travelled in the Middle East, and what you often see is similar to what used to happen in the Soviet Union: people do the things people do anyway, if they can get away with it, but they do it underground and at serious risk to their lives and freedom. You may not care about this, but having lived in environments like this, I do.
And, despite your belief that "putting our nose in somebody else's business" got us into this, one can make a credible argument for the opposite being true: the U.S. has remained too hands-off in its foreign policy, only getting involved when it has a clear, direct strategic interest in a particular situation. The reasons for this foreign policy date back to World War II and Vietnam. However, this may not be in the the US's own interest. It means that from the point of view of people in other countries, US involvement is capricious and unpredictable, leading to resentment when the US does or doesn't get involved in a situation where others think it should or shouldn't.
A policy based more clearly on things like human rights interest could actually go a long way towards improving America's reputation in the rest of the world, and would not necessarily cost significantly more money, since America could certainly get international backing and cooperation for such a policy.