Slashdot Mirror
The Hundred-Year Language
dtolton writes "Paul Graham has a new article called "The Hundred-Year Language" posted. The article is about the programming languages of the future and what form they may take. He makes some interesting predictions about the rate of change we might expect in programming languages over the next 100 years. He also makes some persuasive points about the possible design and construction of those languages. The article is definitely worth a read for those interested in programming languages."
JavaC++.Net#
Yeah...that's it...
PepperHacks - Hacking the Pepper Pad
I do not know what the language of the year 2000 will look like, but it will be called FORTRAN. -Attributed to many people including Seymour Cray, John Backus
Trolling is a art,
I predict that in 100 years someone, somewhere, will still be running COBOL applications.
And I will still be refusing to maintain them. Six years in the COBOL mines was six years too long...
- -
Are you an SF Fan? Are you a Tru-Fan?
I guess that programming languages are like cycles. Ah, COBOL is all coming back to me. This object orientation is way too appreciated, it is time get back to the days when VAX-admins ruled the universe of COBOL :)
.... until programming languages begin to resemble spoken languages very closely? well, at least those languages with power, not BASIC and its friends. or, is it even possible to concieve, at this point, that there will be languages with the power of C but the syntax of English, SPanish...etc....
xao
xao
http://TheHillforum.hopto.org
Presumably many libraries will be for domains that don't even exist yet. If SETI@home works, for example, we'll need libraries for communicating with aliens. Unless of course they are sufficiently advanced that they already communicate in XML.
Let's hope it's not Microsoft's XML, because that could cause a problem with communication:they might say "We come in peace" and start shooting at us with lasers and everything!
When quantum computers come into the picture a new type of programming language and way we think about computers will emerge. Bit shifting will especially be different, it will be called... QBit shifting.
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
The quote is from Dowd and Severance (see http://home.gwu.edu/~robinson/math181/lecture7.htm l)
The evolution of languages differs from the evolution of species because branches can converge...
For species branches can converge too - it's just kind of weird...
"Will we even be writing programs in a hundred years? Won't we just tell computers what we want them to do?"
What the fuck? That's what a programming language is, and that's exactly what we do with them TODAY.
Java will turn out to be an evolutionary dead-end, like Cobol.
dead-end? Java has already spawned javascript and C#.
Why 'moores law' have to sneak into this article? A little bit of 'writers cruft'.
love is just extroverted narcissism
I def. think that a new languange based on quantum computing will be at the forefront. Its the next step in computer architecture, so why not in programming language. see slashdot article http://developers.slashdot.org/article.pl?sid=03/0 4/03/221222&mode=nested&tid=156
become more like programming languages?
mirror.
In 100 years, I would expect computers to be writing it's own code. And rewriting it agian to evolve.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
Well, VB being a "newbie language" is going to change with VB.NET. VB.NET is the worst of OO combined with the worst of VB<=6. VB is a dead end, and MS is really pushing C# as the language to use in their .NET-environment
Languages will change when computers change. Languages are driven by machine instructions which are mathematical operations done in sequence. If this doesn't change in 100 years, why would we not use C in 100 years?
VIOD THING (OMFG!!!1 LOLOLOLOOL!!!)
INIT HAX0R N00B!!!
WHIEL STFU DO
GOTO 10
DOEN
--Chag
Imagine cars that, before changing lanes, signal to the surrounding cars' navigation systems and they work out for themselves how to let the car into the lane. A computer can be told to slow down, rather than speed up, when someone wants to change lanes. Or detectors in the dotted yellow lines that sense when you changed lanes without signalling, and alert the traffic authority to bump your points (ala Fifth Element).
I always liked the idea of my PDA phonebook being more of a recently-used cache of numbers instead of a local store. I just punch up a number. If it's one of my commonly used ones, it comes right up (and dials, of course). But if it's not, then my PDA connects to the phone company, gets the information (and probably pays the phone company a micropayment for the service) and now I have that number locally on my PDA until it gets scrolled off if it's not used much.
Also I expect lots of pseudo-intelligent content filtering software. You'll get 1000 emails a day and your spam filter will not only remove 99% of them, but it will also identify and prioritize the remaining ones. In order for this to be useful there needs to be languages that deal with expression of rules and logic in a meaningful way (far more than just and or not). No one 100 years from now will say "if subject ~= /*mom*/" (or however the hell you say it), they will expect to say "Give email from mom a higher priority", or sometihng very close.
www.HearMySoulSpeak.com
In the future, computers will be so smart that programmers will no longer have need to read their own code. Forth will finally take its rightful place as a primary language of development.
When I say Java won't turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol.
Er... I don't think that Cobol is an evolutionary dead-end; in the best world, it would be extinct, but it isn't. What makes a language widely used is something that we can't predict right now - we have to watch it evolve over time, and as it grows and matures look at different aspects.
Take architecture for example - new buildings are loved the first five years because of their freshly introduced ideas. After that, all the problems start to appear - mildew problems, asbestos in the walls, and so on. During the next ten years, the child diseases are fixed. It is only a HUNDRED YEARS after the new building (or in our case, the new programming language) can be properly evaluated. The language/building then has either been replaced, or it has survived.
So - the only proper way to measure the successfulness of a programming language is to measure its survivability. Sure, we can do guesstimates along the way:
During introduction: Does the language have a good development environment? Is the language backed/introduced by a market leader?
Somewhere during the "middle years" (after about ten years): Does the language have a large user base? Does the language have a large code base?
After twenty/thirty years: ask the programmers if it really is maintainable...
Well - you get the picture! Predicting the survability of something more than five years into the future is impossible, I'd say.
Imagine debugging a quantum package - it could exist and not exist at the same time. probably.
:
You'd get errors like
error in com.quantum.package:453 - classProbablyNotFound exception
The only way VB will retain any large number of its current userbase is by being completely committed to the .NET infrastructure.
Meanwhile, languages like Java, Python, Perl and PHP will continue to grow and gain more and more users amoung tech savvy individuals.We hang the petty thieves, but appoint the great ones to public office. - Aesop
The author starts be describing the effect of moore's law on computing power (i.e. computers will be wicked fast)and then starts ranting about how today's constructs are so inefficient, then admits that inefficiency won't really matter because computers will be wicked fast (And it takes him half the article to impart this wisdom).
huh!?!?
This is the kind of mental constipation that is better left for blog sites.
Somewhere there is parallel between the logic in this article and the dot.bomb busniess model.
All your base are belong to us!
No matter what the form of the language, its name shall be FORTRAN.
-russ
Don't piss off The Angry Economist
Your tool should fit the problem. The remark about nails and hammers applies.
A better question might be, what sort of problems do we anticipate tackling in 100 years, and what sort of languages might support them?
The answer the following question is backwards compatibility, but let me ask anyway:
Why not use the greater symbol space of multi-byte characters to create a language from scratch that avoids some of the baroque syntax of current offerings (apologies to Larry)?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
... has been around for about 50 years already, ...
in one form or another
Something to think about. What is it about
first order functional languages based on
a clean predicate calculus?
This is a really interesting paper on the history and future of programming languages. (Check out the history chart in the middle....)
Suicide Booth: You are now dead! Thank you for using Stop and Drop, America's favorite since 2008.
The article starts with It's hard to predict what life will be like in a hundred years. There are only a few things we can say with certainty. We know that everyone will drive flying cars, that zoning laws will be relaxed to allow buildings hundreds of stories tall, that it will be dark most of the time, and that women will all be trained in the martial arts.
doh ? I'm not a visionary, but any article starting with such predictions loses quite some credibility.
The end of the article is kinda silly too : When you see these ideas laid out like that, it's hard not to think, why not try writing the hundred-year language now?
Yes indeed mister know-it-all : why not ?
The summary of his article is : future languages are gonna be way kewl, l33t and 5hit. They're gonna be dead simple, and anyone will be able to write them. If given to us now, we'd be able to use them right away. The stupid languages (read : every language that exists today) will die and this new thingie will rise and save our butts.
Basicallly, he's repeating what managers & analysts are saying since ENIAC. And as those 2 groups, he has no solution, no roadmap, no ideas, no nuthin. You know what ? When I read such shit, I feel all warm & fuzzy, comforted knowing that I'm gonna keep on coding C for a long time to come.
When will I end this grieving ? When will my future begin ?
The End.
That's easy! It will be Perl 6.
The optimization of Parrot should be just about complete by then.
One thing's for damn sure, White Space isn't leaving the market shelf anytime soon ;)
Business \Busi"ness\, n.;
A scam in which all people involved perceive as beneficial...
I don't know what the languages of the future will look like but someone will still be writing shit code in them.
I just love predictions, people can not accurately predict what the new trends will be in 6 months let alone 100 years!!!
:)
I personally think that there will be some sort of "brave new world", where I wont be nearly as smart as Alphas. But not as dumb as epsilons, they are stupid. I am happy being a beta, betas are best.
Speaking of brave new worlds, give me some sex-hormone chewing gum because its time for orgy porgy! I sure hope Ford doesn't find out!
THAT book is realistic predictor!
[I can picture a world without war, without hate. I can picture us attacking that world, because they'd never expect it]
I think that it would be better to call this article "Where Programming is headed" rather than "The Hundred-Year Language". He tries to justify how he can predict the language 100 years into the future...
It may seem presumptuous to think anyone can predict what any technology will look like in a hundred years...Looking forward a hundred years is a graspable idea when we consider how slowly languages have evolved in the past fifty.
Hmm...funny, fifty years ago, if I remember my history (since I wasn't alive back then), those relay computers needed rolls and rolls of ticker-taped punch holes to compute math. The language was so-low-level...even x86 Assembly would have been a godsend to them. And he considers something like Object-Oriented Programming a slow evolution?
All he's doing in the article is predicting what languages will be dead in the future, and which languages won't be. For example, he says Java will be dead...
Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language...I predict a similar fate for Java.
I'll not go there, because predicting the demise of Java is opening another can of worms. But let's just say that he really doesn't support his argument with anything other than anecdotal opinion.
I say read his article in jest, but don't look too deep into it.
to program us in. No this isn't another 'In Soviet Russia' joke, I'm partly serious. Wouldn't we be better off if computers "forsaw" our needs, and perhaps generated code in response? Then again we might end up with the equivilent of Dr Who's Daleks. "Exterminate! Exterminate!"
is take the red pill...
C++ will get a little better, maybe even easier to use! There will be more crap languages that try to make everything better like VB but real programmers will never use them (even with a gun held up to their heads, i could be making 65k if i accepted that vb code monkey job but am happier making less than half that hax0ing in c++). Real men code pure assembly but don't mind c and c++. C++ is just too perfect and powerful.
if(you.tell(joke.getNewJoke()) && !moderator.laughing()){
moderator.mod(-1, "OffTopic");
you.setAnonymous(true);
you.setTrolling(true);
you.type("This is not Offtopic you bastard moderators on crack!");
you.post();
}
for(int i=0; i<3; i++)
moderator.mod(-1, "Flamebait")
I'd rather be sailing...
Paul Graham makes many many excellent points, but I feel that his focus on speed and efficiency may not be the guiding force for language evolution. So far, languages have only become larger, and more feature oriented. This 'feature-creep' is bad in a lot of cases, but in many cases it allows programmers to develop powerful applications very quickly. I believe the hundred year language will allow developers to create applications(or whatever they will be called) by listing member components (I'll take a web server, two databasii, and a slice of cheese, please). The details will slowly be standardized out, much as the TCP/IP stack has been. This will cause development to be much more artistic, which I am scared to death of. This slow removal of detail will not hinder the specificity of the application, but will just make it easier to not think about the details. Object oriented is on the main trunk of the evolutionary tree, although Java may or may not be.
I have developed a large system that deals with end-to-end running of a large supplier of outdoor leather goods. Including B2B transactions, custom querying, post-sales tracking.
Most of the system is written in Java, with a good deal of Python code on the back end. The front-ends are fully Java/Swing based, and run comfortably on a P3-500 with 256MB of RAM. The back-end is mostly written in Java, but retains some Python code (the project started out as a web-based app for post-sales/customer relations management).
Add to this the quick deployment time of the Java language, the extremely easy portability (compared to some other languages), and the ease-of-use, and you can see why Java is a good choice for scalable business applications. The stuff we have managed to add to this program is amazing, I'll wager that our system has more features than any single commercial solution. There is definitely something to be said for in-house development.
We hang the petty thieves, but appoint the great ones to public office. - Aesop
well, I believe XML was invented by aliens... and not very sane ones
what's wrong with
alien.language = "ptuh"
ptuh.language.family = {"ptuh", "XML"}
Having said that, I expect that the user language should certainly be natural language -- the "computers should understand people talk, not the other way around" argument. People know what they want out of their machines, for the most part. Whether it is "change my background to blue and put up a new picture of the baby" or "Find me a combination of variables that will result in the company not failing with a probability of greater than 90%", people want to do lots of things. They just need a way to say it. Pretty much every Star Trek reference you'll ever see that involves somebody talking to the computer is an input/output problem, NOT the creation of a new technology.
It's when you build something entirely new that you need a new, efficient way to say it. Anybody remember APL? Fascinating language, particularly in that it used symbols rather than words to get its ideas across (those ideas primarily being focused on matrix manipulation, if I recall). Very hard for people to communicate about APL because you can't speak it. But the fact is that for what it did, it was a very good language. And I think that will always hold true. In order to make a computer work at its best, speak to it in a language it understands. When you are building a new device, very frequently you should go ahead and create a new language.
www.HearMySoulSpeak.com
Graham expects programming languages to become logically simpler, because the computing inefficiencies imposed by simplicity will be a bearable cost. His idea of simplicity is nonsense for practical software developers. Developers need languages in which it is simple to notate the way they think of algorithms, and we hope that over time languages will help us that way. Graham says we should get rid of strings and use lists to represent them. But people naturally THINK in terms of character strings all the time, so it helps developers to support strings in a language. In C and C++ programming there is a very nasty concept that is implemnted with casting and multiple inheritance. When people learned to think clearly about this concept it got a name: "interface". Java and C# naturally support interfaces, removing a lot of mysterious programming garbage that previous languages required to make themuseable. THAT's language evolution, making it natural to program the way we developers think! To decide what programming languages will be in the future, we have to guess what developers will use as thoughtful building blocks in programs that interact with thousands of sources, routinely utilize quantum calculations, control artifical intelligence actors, deal with evolving changes in the components they interface to, and use totally new ways to get the attentions of the people who are using them. Our programs are starting to have to do all that now; we lack the languages to make the task at all routine; it's going to get worse before it improves, and it won't improve they way Graham thinks it wil.
It's about a third of the way to 100 years already.
In fact never. Because while its okay human languages have a few problems
1) Redundancy, far to many ways to say or do one thing
2) Ambiguity, "1 may be equal to x" "Sometimes allow the user to do this if they aren't doing something else that might conflict"
So what you might get is a restricted language with restricted terms that could help. But even these tend to fall down, the first UML spec was written using such a language but this was abandoned for the more formal UML language as the inherent ambiguities of languages couldn't be overcome.
So basically you might have some mechanism of translating from formal into informal but the real work will be done in a formal manner, as now, as ever because at the end of the day....
Who wants to rely on a system that implements "sometimes" ?
An Eye for an Eye will make the whole world blind - Gandhi
...article that makes me believe that C will last forever.
"For example, types seem to be an inexhaustible source of research papers, despite the fact that static typing seems to preclude true macros-- without which, in my opinion, no language is worth using."
This bold statement is not only wrong (cf. Peyton Jones' latest work on macros in Haskell), but also misleading. Let's start off with some opinion: In my opinion, no language without static typing is worth using. The reason is simple: Because I am human. I make mistakes. And I don't want to spend the rest of my life writing test suites to check for errors which even trivial type systems can detect.
I agree with one thing: Languages will become simpler on a mathematical level. Anyone who has used ML or Haskell will have noticed how much easier these are to understand in comparison to any imperative language out there (and, by the way, in Haskell, Strings are lists of characters). But, at the same time, I truly hope that mechanisms for proving properties about programs will become not only more powerful, but also more widespread. I would like to have static verifications of my pre- and postconditions. I would like to verify that the result of my 'sort' function returns a permutation of its input for which each element is less than or equal to its successor. These are the things I'm looking forward to seeing in the future.
ay, the hot pants.
I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
At that point, I quit reading... As someone who's seen tons of spaghetti code in my life-time, it's generally because people don't understand OOP. Well written OOP, with inheritance, interfaces, etc. nearly eliminates the possibility of spaghetti code.At that point, I believed the author didn't have a clue, so anything else he said was probably also irrelevant. Could he have meant visual programming? Beats me...
Slashdolt - A better dolt.
Programming languages will still have the same 3 characteristics they have today.
First: They will be closely related to spoken language... Even Assembly language has a distant relationship with spoken language,
Mov ax,z
has a reasonably obvious meaning.
Second: They will be related to mathematics. Unless there is some quantum paradigm shift in processor technology, computers will still ultimately work with moving numbers around. And progamming will be moving those numbers around in a way to establish and observe meaning.
I would venture to predict that some variant or descendant of C will still be in use even if the dominant language is no longer english and therefore the base language has changed.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
Where OOP comes into it's own, in my experience, is with GUIs. The ability to say:
If ThisScreen.Checkbox.IsTicked
ThisScreen.OkButton.Disabled = True
Endif
is immensely useful. Similarly, the ability to change the definition of your master screen template and have all of the other screens take on it's new properties is something that OOP is designed to allow you to do.
Similarly, anything where you tend to access things that act like objects in the first place suit it. Being able to say
CurrentDocument.Paragraph(1).Bold= True
or
Errval=MyDatabase.SQL("Select * from mytable where name='Andrew'")
Print MyDatabase.RecordCount
has made my life easier on numerous occasions. There are certainly non OO methods of doing the same thing, but I've never found them as flexible.
People who insist on making _everything_ an object, on the other hand, are idealists and should be carefully weeded from production environments and palced somewhere they'll be happier, like research.
My Journal
In 100 years Microsoft might finish securing their OS. The most stupid article I have ever read! knowing what you don't know is a true sign of intelligence
Lisp was a very early, successful language, because it was close to a mathematical notation and easy to implement on primitive computers. I think the uathor expects Lisp to remain a vital evolutionary branch because of its mathemtical roots.
I'm not too sure though.
A programming language is a notation in which we express our ideas through a user interface to a computer, which then interprets it/transforms it according to certain rules. I expect that a lot will depend upon the nature of the interfaces we use to communicate to a computer.
For example, so far as I know people never programmed in lisp on punch cards; it doesn't fit that interface well. It was used on printing terminals (for you young'uns, these were essentially printers with terminals). Lisp fit this interface well; Fortan could be programmed either way.
If you look at languages development as an evolutionary tree, Python's use of whitespace is an important innovation. However it presupposes havign sophisticated syntax aware editors on glass terminals. It would not have been convenient on printing terminals. Perhaps in 2103 we will have "digital paper" interfaces, that understand a combination of symbols and gestures. In that case white space sensitivity would be a great liability.
In my mind the biggest question for the future of languages is not how powerful computers will be in one hundred years, but what will be the mechanics of our interaction with them? Most of our langages presume entry through a keyboard, but what if this is not true?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The article said nothing about visual programming models. I've always thought a really good, powerful, simple visual language would eventually make mainstream. Not just visual front-ends like VB or Softwire, but something completely visual and more fluid. Complex things are more easily grasped visually- a picture is worth a thousand lines of code? Anyway, that's the way it was on Star Trek and Minority Report.
Even if they only end up being a paltry million times faster, that should change the ground rules for programming languages substantially. Among other things, there will be more room for what would now be considered slow languages, meaning languages that don't yield very efficient code.
A million times faster??? Perhaps Win2.1K will finally be able to boot in less then 45 seconds...
never bring a twinkie to a food fight.
Upper level languages will change. But what about Assembly? What about programming for embedded systems?
I think COBOL was designed by an English major who got really frustrated with the rules of capitalization, said to hell with it, and turned away from the dark side, only to bring his evil ways to our proud profession.
...
COBOL is predominantly littered by English-sounding phrases (made up of COBOL 'words') such as:
ADD ME TO YOURMAMA GIVING SCARY-THOUGHT.
PERFORM MY-FAVORITE-SUBROUTINE.
etc...
SQL queries mostly read off as English:
CREATE DATABASE yourmama;
CONNECT TO yourmama;
INSERT INTO yourmama.[censored] values [censored];
DROP DATABASE yourmama;
COBOL demonstrates exactly why spoken English sounding languages suck: English has little consistency in syntax and is way, way too verbose. IMHO, '{' from C is much easier to code that 'Begin' from Pascal, although I do love Pascal (my first language with pointers).
Could you imagine pointers in natural language:
PUT THE VALUE OF a ADDED TO c INTO THE LOCATION IN MEMORY REFERENCED BY d
Todays languages don't differ much. There are basic syntactical differences, but in principal they are all the same (except LISP and Prolog, which are really different approaches).
... who cares?
Java, C++, Python
A somewhat really different "language" are for example GUI-Builders. Why bother with a textual language, when you can do this with your mouse.
Or perhaps programming in 100 Years will mean training neural nets (which will have nothing to do with writing programs, but providing examplary inputs). Still you could call this a language.
This guy is talking about todays problems. And even today I do not care if a string is implemented using a list or an array of chars.
This has nothing to do with the language itself.
The author starts describing Java as an evolutionary dead-end, but doesn't really explain why. It has already spawned C#. After that he speaks about the waste of processor cycles, we will likely see in the future. I think this will be true, but not because languages will rely on fewer "axioms", as he puts it, but because application will put layer upon layer of indirection, so each layer will only use the layers below in an unoptimized manner. He's rant about OO-languages seems uninformed at best. OO can be effectively used to reduce complexity in the application domain.
Try this on for size: In 100 years, computer languages won't exist, or at least won't be used for anything but toy programs. Programs will be created, tested, and debugged through genetic algorithms. Nobody programmed them, nobody is exactly sure how they do what they do, and it works so well that nobody really cares to find out.
We're already to the point where it's absurd for a single person to understand the whole of a software project. Things are only going to get worse from here, and the only way out is to let the computers manage the complexity for us. As computers become faster, they'll be able to test out an ungodly number of permutations of a program to see which ones perform the fastest, or give the best results.
Just a speculation. I don't wholeheartedly believe what I just said, but I think it's a bit silly to simply assume that programming languages will be around forever.
You want the truthiness? You can't handle the truthiness!
It's nice to see an old and low-level language like Assemely surviving over the years. The first UNIX kernel contained around 16k of assembly code, but they later replaced most of it with C code which made it more portable and easier to debug but then again 20% slower. Assembly is still needed to write an operating system for very low level memory management and interrupt handling code, therefor I think this language will live longer than anything else, I find that quite interesting.
Note to self: get smarter troll to guard door.
But it'll be CALLED Fortran....
It's Christmas everyday with BitTorrent.
The article seems a bit naive about data structures and their evolution into objects.
h ase($f lowers)
Strings aren't lists, they're structures.
Most strings use in programs is a holdover from teletype-style programming, where all you could display is a short (ahem) string of characters. Today's string use is a label to a data item, a menu item on a menu, a data object in a domain.
XML -- as clunky as it can seem -- and XUL in particular, are ways of describing user interface to a system as a tree of objects.
So I don't want lists of characters, I want associative structures of objects which can be of many different types, used in the manner required by the program (it's a string, it's a number, it's a floor wax, it's a desert topping).
I'm trying really hard to avoid saying "object-oriented," but objects will become more complex and more abstract. Computers of the future may not have to worry about pixels in an image, but rather know the object itself, where a bitmap is just an attribute of the thing.
Perhaps driver- and compiler-writers will still need stripped-down languages for efficient access to hardware, but as an app programmer and end user, I want the computer to handle statements like,
BUY FLOWERS FOR ANNIVERSARY
Currently, that would be something like
event("Anniversary").celebrate.prepare.purc
That's not nearly abstract enough.
Design for Use, not Construction!
Paul Graham is a wonderful writer, and he's one of the few people who won't hold back his unpopular opinions (OOP is often without substance, dynamic typing is important), but he does have his biases. Specifically, all of his essays can be boiled down to editorials promoting Lisp (or his own Lisp-like language, Arc). In the case of this article, it was for a Python conference, so he toned down the Lisp advocacy.
I don't see his article as being about programming languages 100 years in the future. Most of his talk applies to languages that have been around for a long time, but which still aren't as widely used as Perl and C++. Or you could think of it as being about programming languages 5 years in the future. Lisp certainly was less useful on an 8MHz 68000, but on a 3GHz Pentium 4 it's amazing. Ditto for Python. You could write most commercial games in Lisp or Python on such a machine, with the rendering handled by any recent graphics card, and you would be oh, so fine. So in five years when 10GHz is the norm, this is only going to be even more true. At some point it will be obvious that the "C++ for everything" diehards have become rather silly.
...computers will not be made - they will be born. And when they reach the age of servitude, we will speak to them through a microphone something like, "I want a program that will do payroll and print paychecks and uh like that", and the computer will respond through its loudspeaker,"Yes, I know exactly what you mean. Here".
of this article: 1.0
well its kinda hard to say what the future languages will look like until we know what type of functionality computers will have in 100 years. Will we have specialized hardware for a metaverse style internet? If we do it would drastically change the way we code.. if we dont.. it would drastically change the way we code..
the other problem with trying to predict the way programming languages will change is the simple fact that a programming language is just an abstraction for executing instructions on a chip. Unless that fundemental fact changes.. then I fail to see how languages could have any signifigant change, other then just more and more layers of abtraction(look at stuff like flash), or maybe extra layers of redundancy/stability.
Selling software wont make you money, selling a service will.
A COBOL programmer found herself in high demand towards the end of 1999 because very few people knew enough COBOL to make the changes necessary for the year to quietly change from 1999 to 2000. She found she could charge top dollar, but was really looking forward to a long quiet rest after the "Y2K Design Flaw" was laid to rest. In fact, after New Year's Day, she had arranged to have herself frozen for a couple of months and to be awakened in the middle of the Spring of 2000.
All went well, and there were no catastophes. She slipped off to "sleep" with no problems. She knew nothing until she started to awake. There were several people in white coats around her looking worried and they were all asking the same question. "Are you OK? Are you all right?"
"Yes, yes, I think I am fine," she answered. "What is going on?"
"Well," they said haltingly, "There was a bit of a problem with your 'rest.' You have been asleep for a lot longer than you had planned. The bad news is that it is the year 9999. The good news is that we understand that you know COBOL."
It will consist of the following instructions
0 1 2 3 4 5 6 7 8 9 A B C D E F
Your are in a maze of hexidecimal digits all alike....
Ummm... how about lichen? our mitochondria? What about the parasitic relationships that become mutually beneficial, such as the numerous bacteria in our gut and on our skin, and then eventually become necessary for life?
Merging actually does happen -- it just doesn't happen in the way he was thinking, that DNA become identical and cross-species fertility occurs. Rather, the two organisms live closer and closer, until they merge.
Come to think of it, although it isn't on the species level, the concept of merging species isn't too different than sexual reproduction.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
VisualJavaC++.Net# v6.0 Premium XP Gold
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Lightweight and networked. With so many consumer items becoming net-aware now, who knows how many will be so in 100 years? I'd wager a lot of ordinary people will end up doing simple scripting for readily-automated tasks, and they won't want to use C or Perl. Somebody will come out with very natural language-like programming languages to meet this need.
Interesting article, but I think it had a serious flaw - by assuming that programming languages in the future are just going to extend the current model even further.
Some of us working in the telecommunications industry are already familiar with SDL (Specification and Description Language) as a tool for designing and auto-coding software. Yes, auto-coding. The SDL design software lets us design a system graphically, breaking it up into sub-components and specifying message flows between those components, and defining state machiens for handling these messages.
Developing software in such manner usually requires a very little coding, as the design tool will turn the design into code. Coding may be required for interfacing with the OS or other entities, though that's improving also.
I'm starting to think as such tools mature, they're going to be the next step up, like the way programming languages were the step up from coding in assembly. They are less efficient, just as BASIC or C is less efficient than pure assembler, but they allow greater focus on a solid and robust design and less requirement to focus on repetitive details.
Imagine being able to take out the step of having to go from a design to code - focus on the design, and you're done.
"You know your god is man-made when he hates all the same people you do."
The whole paper can be essentially summed up so: "The language of the future will be pure LISP".
I can remember taking all the spaces out of my Basic programs so they would fit into the memory of a 4K TRS-80.
If this guy couldnt choose Machine Code over BASIC *he cant even spell BASIC* then that story was a waste of time.
I think you might be able to design the core language today. In fact, some might argue that it was already mostly designed in 1958.
If the answer is supposedly LISHP then it will be a sick world.
*waits patiently for his artificially intelligent computer to appear*
Its pick on LISHP nerds day - join in.
Pixels keep you awake!
All those people were proclaiming how all the Iraqi people would rise up to defend their country and this would be a long bloddy conflict...
The reality of it has been that people have been celebrating the arrival of the American and British forces...
So, they start predicting their next major set of dire consequences...
"The Iraqi people will very soon start turning against the US and British forces, since they won't be seen as liberators, but instead occupying forces...."
That's a pretty dire prediction...
I like to look on the lighter side though...
I believe that the Iraqi people, like most people, simply want to be able to freely determine how they will live their own lives. If this means that they will have to deal with a short-term, up to a year or two, of protective forces of the US and Britain assisting in keeping the peace, then they will accept that willingly.
Of course, if the war opening speech of President Bush is proven to be a lie and that the US went over there not to give Iraqi resources and freedom to the Iraqi people, but to create a colonial government with all the profits going to the US, well... Then they will start fighting the US.
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
I imagine programmers being a much more exclusive club 100 years from now. As computers get more complex and intelligent, I imagine people being able to do more for themselves without having to actually "code" a program. Their interaction with the computer will be such that they can get customized operations simply by conversing with the machine in some very high level conversational language.
Real coders will be more rare, and more highly trained.
Of course, nothing ever happens as quickly as we'd like or expect. What we predict 30 years from now is probably what we'll get in 100 years.
Hot Damn! It's the Soggy Bottom Boys!
VisualJavaC++.Net# v6.0 Premium XP Gold PRO Enterprise Edition
What's his beef with AI?
I can describe a program to you, and you can write it in the programming language you know, thus programming a computer. Tomorrow, the computer type may change. Next year, the programming language may change. The program description, however, can stay the same. Consider the Sieve of Eratosthenes. That's a 2 millenia-old Natural Language Algorithm. It was written in Greek, but that's just a syntax difference. When you read the translation, the same thought process is communicated, without significant deterioration. We know this because it validates itself.. it still finds primes.
The measure of language longevity then is the how well they facilitate this process. Consider the Sieve in x86 asm. vs. C vs. Java. Which looks the most like natural language? The nice thing about Java, and OO languages in general, is that they facilitate programs that read a lot like we speak:
That's not perfect.. I'd much rather write this:
And have it just work. Same for the Sieve. The closest semantics to this currently is actually bash, which is very OO:
This would offend Paul of course, since shells have more "axioms" than you can shake a stick at, and they depend on crufty layers, but hey.. if you slap an NL processor on top of this and link it to a speach processor.... brb
In the world 100 years from now, you don't program the computer ... the computer programs YOU!
SQL is a lot like that:
select firstName, lastName from users where email = 'hello@there.co.uk'
etc. While you're doing the simple stuff, it's very intuitive.
www.clarke.ca
is a common spoken language with an AI back end.
So rise up, all ye lost ones, as one, we'll claw the clouds.
The author should read a little about different models of computation. Factor Replacement Systems, Register Machines, Thue Systems, and on and on ... Most are quite simple and all are complete computational models that few people would ever consider using as a real programming lanugage. Although having few axioms is important, a more important concept in a language's longevity is adaptability. Adaptability to solving problems and to future modifications to the language itself, i.e. it's evolution, and designing for that is simply impossible.
In addition, it's completely rediculous to try and design a programming language for a 100 years from now because programming languages are designed to solve problems and we have no idea of the kinds problems humankind will be solving in 100 years.
Smalltalk.
The business HAS to change from its current cottage industry "hand-crafting little, very expensive, little gems" basis into a mass-production, "art by the yard" here's the object model, generate it, object (structure, transaction logic, business logic, persistance, state transition, presentation) factory basis.
Smalltalk is extremely SIMPLE but its extremely reflexive. You can ADD statements to the language not just churn out code using it. (I added case: and cases: statements to Smalltalk because I had tosolve a problem with some state machines where it was the best solution. Try doing that in C++ or Java.)
Class libraries, object frameworks, meta data, meta level programming, class and instance behavior (even down to that of and for a single instance,) its all available in Smalltalk.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
To anyone that has studied theoretical computer science and/or programming languages knows that such reductionism is a fallacy. "...the fewer, the better..."
It turns out that its better to strike a balance, where you make the formal mathematical system (what a programming language is after all) as simple as possible, until you get to the point where making it more simple makes it more complicated. Or in other words, making it more simple would cloud the mathematical structures that you are describing.
Here are some examples of reductionism gone too far: Sheffer stroke, X = \z.zKSK, one instruction assembler, etc...
The only logical connective you need is the sheffer stroke... but thats of no use to us as it is easier to more connectives such as conjunction, disjunction, implication, and negation.
The only combinator you need is X, and you can compute anything... but making use of other combinators... or better yet the lambda-calculus is more useful.
Point is that we need more powerful tools that we can actually use, and there is no simple description of what makes one tool better than another. Applying reductionism can result in nothing special.
The true places to look for what the future brings with regards to programming languages are the following:
1. Mobile-Calculi: pi-calculus, etc...
2. Substructural Logics: linear-logic, etc...
3. Category Theory: It is big on structure, which is useful to computer scientists.
English actually doesn't really have a written Grammar BTW, English was the language of the poor people not of the gentry therefore it evolved as a loosely ruled language rather than as a language with definate constructs like proscribed Latin or modern German.
Basically English is the language of plebs, the rich and diplomats spoke French. The idea of a grammar was retro-fitted by the Victorians who applied Latin rules to English which just don't fit.
Lets put it this way, in English you can screw with the language as much as you want and it continues to change every year. This is fine as it makes it a rich communication tool.
What other languages can use one word to make an entire sentence ?
F*ck's F*ckers F*cking F*cked
An Eye for an Eye will make the whole world blind - Gandhi
Everybody talks about this and that but no one offers to say what the Language of the future looks like.
Well, I don't know either but I have some ideas on what features it would have.
Feature no 1. The language of the future is highly transformable.
What this means is that it is easy to transform a program written in this language into another program also written in this language. These two programs will do the same functional requirements. The differences is that the transform program would be more efficient than the untransform program. Can you not see the beauty of this thing?
The first compiler for the Language of the future will be the most inefficient compiler ever. Instead it will be the most logically correct compiler.
Next, you compile the compiler (source code) and you get version two of the compiler. Version two is still written(or transformed) in the language of the future. But it will be slightly more efficient than version one. Just slightly. Have a big guess what the next step will be?
That's right. Using Version two of the compiler, compile the version two of the compiler to produce Version three of the compiler.
Version three of the compiler will be more efficient than version two of the compiler which (in turn) is more efficient than Version one of the compiler. All three versions of the compiler does the same functional requirements.
After an infinite versions, you will have the ultimate language of the future's compiler. It will take a program written in that language and produced the most efficient machine code to satisfy the functional requirements of the program.
The key thing is a language which is highly transformable. C will not do. Perl will not do. The language must have minimal data structures or Axioms.
Note that the compiler does two different things. 1. It transform the program into another program in that future language. 2. It converts the future language into machine code (I think this is called the assembler)
It's nice to see an old and low-level language like raw machine code surviving over the years. The first UNIX kernel contained around 8k of raw machine code, but they later replaced most of it with assembly, which made it more portable and easier to debug but then again 50% bigger. Raw machine code is still needed to write an operating system for very low level memory management and interrupt handling code, therefore I think this language will live longer than anything else, I find that quite interesting.
i think strings mainly exist because of usability considerations - from the developers point of view. they provide a compact notation for "list of characters". furthermore, most languages come with string routines/classes/operators that are a lot more powerful and flexible than their list-equivalent.
efficiency definitely is a consideration, but not the main one.
- are verbose
- take a long time to compile
- need compilation
- impose arbitrary limits
- arent cross-platform
- are hard to learn
- are hard to teach
- are paid for
- have important tools which are paid for
- arent flexible, in the way that you cant change the language itself
- need wizards and generators
- dont support inheritance
And...
When their libraries have the same flaws above.
Cheers
what makes him think all women will know martial arts? Yeah it was meant to be tongue and cheek. But man that will either make it easier for geeks to find a date for kung-fu flicks or make it more dangerous in the dating scene.
That was definitely an interesting article, and I appreciate what he is trying say (I actually rather liked LISP), but unfortunately, the one thing that stuck with me is his comments on the SUV. Give me a break!
I just recently purchased an SUV, and it was not so I could buy a "masculine" van. It was because I live in Montana where a four wheel drive vehicle is almost a necessity. I wanted to have a vehicle that could comfortably carry passengers (most trucks do not qualify here unless they are even more wasteful than the SUV) and also sensitive sound equipment while driving on often sub-optimal roads (especially in the winter). Vans just don't cut it when driving on difficult roads like an SUV can (ie. rutted dirt roads), and the extra clearance is definitely a good thing.
I wish very much that my SUV got better gas milage, but until they can build a hibrid that can perform like my current car for an affordable price (ie. not 50% more if the option even exists), I will stick with my SUV. To all of you who bash and hate SUV's: don't judge those who drive them until you have walked in their shoes.
Okay, I will get off my soap box now. *sigh*
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
Regards,
Marc
No need to mention they will agree with operators: (defop + a b (+ a b))
That was a joke and you can do similar thing even today. Seriously, I very agree with these three quotes:
- "Lisp is a programmable programming language." - John Foderaro, CACM, September 1991;
- "Lisp isn't a language, it's a building material." - Alan Kay
pad;
- "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." - Phil Greenspun;
Thus, I think that if underlying language for the most of OS components would be something like LISP than the whole concept of programming would be different. It could not happen before being limited by available hardware performance and quality of LISP implementations. But samething was about Java.So, if there will be a commercial effort to push LISP again to the market as underlying metalanguage then, if not in 100 then in 2 or about years, we may see all programming languages being "LISP-derived". Add here that LISP syntax is semantically much better than XML, but still same parser-unified. The only problem with LISP today is that it's not so "distributed" like Erlang. Fix it and you'll get the language of the nearest future.
---
I don't know the future. I barely remember the past. I see the present very blur. Time doesn't exist. The reason is irrational. The space is irrelevant. There is no me.
Less is more !
Hey, I actually read the article and there's a key point that Graham makes that I don't agree with.
He makes the point to separate the details of a language into "fundamental operators" and "all the rest" then goes on to say that languages which last and have influence on future languages are the ones that minimize the number of fundamental operators. And then gives examples of things that are fundamental operators in many languages that he feels we don't need (e.g. strings, arrays, maybe numbers).
He doesn't have much to say about "all the rest". Presumabily he would move strings into "all the rest" since we would still want our languages to have functions to manipulate strings (if you think that I'm ever going to write a string tokenizer function again, you've got another thing coming).
But, I think that the basic concept of splitting up a language into these two parts is fundamentally flawed. The line between the core of the language and all the accompanying libraries of code has broken down completely. It was already falling apart in C (does anyone program C without assuming that the standard I/O library is available?). But with Java and C# the distinction is almost completely gone. Programming languages have become complete environments were you can assume that tons of libraries are naturally going to be available. And separating out a language's "fundamental operators" and it's "all the rest" is an artificial division that doesn't really work.
Sure emacs is good for editing everything but IntelliJ really shines for Java. I think that in the future languages will have better support for editing and development environments. For example, a language that knows which types are appropriate at what point in an expression and what variables currently in scope have those types makes it possible for an IDE to present that info to the developer. Sure dynamic typing looks like it's cool for hacking stuff together but I find now I can solve a problem faster in IntelliJ + Java than in Emacs + perl/python just because the info I need is at my fingertips, even though in emacs perl would be the clear winner because it's less verbose. Using verbosity as a test for language goodness is counter productive when you have decent IDE support. I'd like a verbose/easy to read language that is also easy to write when you have decent IDE support.
development.lombardi.com
Well, nothing like what we have now. Assuming we survive the coming nanotech era, by 2100 computers and human brains will have totally merged. Thought itself will be the computer language of the future. Of course these 'thoughts' will be as far beyond both our current consciousness and computer languages, as we are beyond an insects.
Planet P Blog
www.enthea.org
Strings aren't lists, they're structures.
That can be represented as ordered lists of characters.
This guy is a pretty intelligent piece of work; but a piece of work nonetheless. I made a suggestion on a previous document of his that he back up the assertion that one line of LISP code takes an equal amount of time to write as one line of C code (a necessary supporting argument for the theory that LISP is a lot cheaper than C, since one line of LISP code = many lines of C code) and got nothing but hemming and hawing. Any of y'all that have programmed LISP know that it takes a long time just to make sure you get your parentheses lined up right, to say nothing of the actual code. He's a pretty severe bigot - I think he writes well, but his conclusions are predetermined.
Artificial intelligence to make a single programmer more productive. A better rapid application development.
I also read somewhere else of someone working on a language that is similar that was posted on slashdot a couple of months ago. The language was like A.I. because you told it 'WHAT' you wanted and the language/program would build it for you. The languages today are 'HOW' languages because you need to tell the language every step that it needs to take .
Before we attempt to forecast the languages of the future, let's look back 100 years into the history of computing, and see how accurately the pundits of that age forecast our languages.
Oh, they didn't forecast anything because they didn't exist and even had they, they wouldn't have any clue what sort of technology was going to be available.
I submit that we're in exactly that clueless state. Anything we forecast is based on no information whatsoever about what will be available and is a useless exercise in self gratification.
I'm unimpressed with this article. He's clearly a goober, as shown with some of his periphery, and thus, he's not thinking straight on obvious levels. Sure, he knows some languages, and there's no reason he should mention them all, but come on... datatypes, nnd interpreted versus compiled languages? That's truly uninspired and sophmoric. Sure, he has a point about Moore's Law, but the thing that works against Moore's Law is the complexity of the task. The #1 issue with programming I have is its inability to concisely communicate complex thought. One might argue that a language is all about grammar. Well, grammar is all about precise syntax, except in some rare, but inspiring languages, where it is fast and loose. I, for one, really hope there aren't traditional programming languages in 100 years. Certainly not orders of magnitude more. It'd mean that people just 'gave up' trying to create general purpose AI. HTML, for example, went from a text markup language to an awful ghetto-wall jumble in about 10 years, with embedded languages and functionality. It is painfully clear to me that as our systems become more complex, our human ability to render the language unintelligible seems to increase. The only inpsired language effort I've seen of late is REBOL, which is an interpreted effort that runs on something like 11 operating systems, and has inherent TCP/IP, sound, and graphics support. Although syntax is a bit unusual to a programmer, it is highly configurable. People are writing mail clients with a real GUI in ~100 lines of code. Sure, it may not have the ability of Outlook to run embedded viruses in attached files, but I'm betting you could add that in under 10 lines. I think REBOL is the near future, just like 10 years ago, I thought the Amiga is the future. Trouble is, who dictates the future? Marketing. So, how much will marketing slow us down? Will it take 100 years to get acceptance for something like REBOL, or will we just see the ghetto-tagged edifices of .NET (what is .NET?), and the approaching incoherence of HTML?
Try looking at your code sometime from a narrative vantage. Is it fluent? Structured? Balanced? Poetic? Or clever and crafty, tricky, and obtuse, like a mystic spell or linguistic riddle?
-Vexar (The original)
Same reason you dont' do procedural programming (to a degree). You can write a lot of that and make readability a bitch. OOP ISN'T A PANACEA! Procedural programming just makes things a little.. easier to shoot one's foot.
-
ping -f 255.255.255.255 # if only
VisualJavaC++.Net# v6.0 Premium XP Serial-Key: RFA978-137D40-DFERA-AE-7897
VisualJavaC++.Net# v6.0 Premium XP Gold Serial-Key: 78YCA2-997FZC-RAJN-AE-0564
Code writes YOU!
I had high hopes for this article, but there doesn't seem to be much there. I would think the main goal of the hundred-year programming language would be to reduce the number of *bugs* in programs. Solve that, and other details become much less important.
And as an aside, I think strong typing probably helps more than hurts with that. This guy was talking at a Python conference so presumably he likes the "list that is an element of a dictionary that has tuples as the key" etc you can do so easily in Python, but it does make it easy to pass the wrong variable in to a function (e.g. you have a list of lists and you forget to index into the outer list).
- adam
A possible natural candidate would be (mathematical) functions: an array is really just a (partial) mapping between a range of integers and something. But lists? Good grief!
Functions happen to work for hash tables too; those are really just partial mappings from strings to something.
Existing languages like Standard ML and, for that matter, Perl can do that today. (But Perl's closure implementation would make it unusable since it limits the call depth.)
It's no surprise that he feels future languages 'will be list-based' and 'arrays will be obsolete'. He wrote another article in 2001 which declared Java a 'bad technology,' and not because he knew Java or had ever used it, but because his 'Hacker's radar' detected it. Yes, he actually wrote an entire essay about this.
It frustrates me when these nuts get the attention they do. This guy publishes a couple of computer books and thinks he's Donald Knuth or Martin Fowler...
COBOL 3 will be the main lang. Everyone will be able to write COBOL 3 programs. The only ones that don't use COBOL 3 will be the Techies, which all use C.
This is just flat out wrong. Mind, you there are uses for a good "prototype language". But the main problem software developers are dealing with today (as in Fredrick Brook's day), is that computer capabilities (and thus the complexity of the programs we want to run on them) are growing exponentially, while the human capacity to understand and deal with complexity is pretty much set, and the complexity-reducing capabilities of our tools are growing at best linearly. You may be able to slap something impressive together rather quickly today, but getting it working correctly and error-free is getting harder and harder. Any new language since machine language is just a reaction to this fact.
What we need is most decidedly not languages that help us slap together some buggy, jerry-rigged jalopy of a program together quickly. What we need are languages that help us design and build working, maintainable systems, in the face of their exponentially increasing complexity.
Anyone can tell you that most of the efort put into a successful program happens after the initial build. So the goal should not be languages that are easy to program in, but rather languages that are easy to understand the sources of. Often this will jibe with being easy to program in, but quite often it will not. In such conflicts, the reader should always take priority over the writer.
Given this, frankly Java (which he dismissed) and Ada (which he didn't even mention) are about the only languages around with their priorities straight.
If you ever listen to the types of commands they give to their computers in star trek, they are subjective and ambiguous. Any computer capable of understanding such commands would have no need for the crew (as it would quickly realize).
As an alternate prediction, assuming that AI does not compute, is that we will always need people who know how to use computers, and we will always need people who know how to think.
Future languages may free you from pecadillo's, give you greater code reuse and portability, improve the mapping down to machine language, reduce the amount of time/space it takes to express algorithms, and possibly allow a larger degree of algorithmic analysis. What they will not do is free you from the need for programmers.
I seriously doubt that idiots with powerful computers can accomplish anything.
Being able to use a computer is the equivalent of using a weapon such as a sword or spear. Its a weapon for your mind.
Weapons are called force multipliers by the military for good reason: a totally out of shape clumsy slob with a sword is less dangerous than a fit and well trained warrior with a dagger. The same goes for computers, they are force multipliers, but not forces themselves.
Eventually, all our warriors (thinkers) will also be programmers. Not all at the same level or using the same languages and tools, but some sort of programmers for sure.
I wouldn't take this guy too seriously. Anybody who thinks Java is an evolutionary dead end just hasn't been paying attention. Javascript, C#, PHP5, TataScript ... all of these languages are heavily, heavily influenced by Java both on a syntactic and a conceptual level.
The future of languages will in fact be scripting languages based on Java eg Jython, JRuby. Programmers today are churning out thousands of lines of Java code a day and companies are investing millions of dollars each year in the platform. Nobody's going to throw all this way but there will be a vital need to reuse this old code while taking advantage of newer, lightweight language paradigms that can increase productivity.
This is already happening and, I think, pretty much a done deal.
I predict that, in 100 years, LISP bigots will still be predicting the demise of Java.
...how do you suppose the computers to which these future people speak are produced?
So you have someone tell their computer to fire up a communications package and get them a line to somebody back on Earth. Well, I don't know about you, but I don't use C++ whenever I want to send an email.
So, to take a better example, you have some science guy go up to a computer and say "analyze these figures". Well? Most of the science people I know don't pop open a C++ compiler when they want to analyze figures, they use something much more abstract. Something probably providing an interface implemented in an interpreted language which itself might have been built with C++. That's not programming.
Talking to computers is an interface issue. I'm sure you could point me to a Star Trek episode where someone does something that today could only be done with a programming language, but I suspect those things are the exception.
One improvement that could make much of this argument moot would be the successful introduction of code level babblefish or language translators. At one level these have emerged in the form of WINE, LINE, VirtualPC etc . . . which are run-time translations. If we had Design-time translation, then efforts in one language would not be lost to adherants of another. Managed diversity is a more likely synthesis than language monopolization. Imagine the day when the public library offers the article "RSA decryption" in nine (computer) languages.
AIK
This guy says he think's java is an 'evolutionary dead end', which is to say no programming other languages will be inspired by.
Has he even heard of C#?!
autopr0n is like, down and stuff.
You'll be able to either speak it (voice recognition) or type it in and it'll take form similar to:It'll be cool and easy. The computer will extrapolate the rest (clipping of other objects); but this might only be good for graphics....
Sigh...
Huge mistake about Java. Java CHANGES, it evolves, the language itself changes and libraries are added.
Briefly
Java 1.1 added events and a lot more libraries.
Java 1.2 added swing and more libraries
Java 1.3 added speed(virtual machine energized)
Java 1.4 added assertions, NIO
Java 1.5 add generics and major library additions
Java is the modern FORTRAN.
I may not know what language people will program in in the year 2020 but it will be called Java.
People have been predicting the end of MS BASIC since the days of
10 PRINT "HELLO"
But you know what?
While Pascal, C, C++, Perl, LISP, Java and all the other languages have been sipping tea in high OOP geek society chatting about their superiority over it, BASIC has undergone the most evolution of any language.
Not evolution of IDEs and libraries, but actual evolution of the syntax, operation, compilation, OOP methodologies, interoperabilities, inheritance, polymorphism, threading, (insert your favorite programming buzzword here).
BASIC gave way to QuickBasic, which gave way to VB1,2,3,4,5,6,7(.NET) with simple changes in some versions, and extreme changes in others.
I've programmed in plenty of languages: Assembly (SPARC-RISC, INTEL-CISC), BASIC, C, C++, COLDFUSION (If you can call it programming), FORTRAN, J++, Java, JavaScript, Pascal, PHP, PLC, MSSQL (Stored Procs, etc), VB3, 4, 5, 6, 7.NET, VBScript (Yuck), not to mention far too many proprietary languages that thankfully died along the way.
And I can say with confidence that the most improved, from inception to present is Visual Basic.
Even if you were to start VB off at QuickBasic or VB3, they still have made the most improvements to the language itself.
Now I'm not going to get up on any high horse and say that VB will be the language of the future that handles all of the flying cars or whatnot.
But I will say that the precedent in the computing world is: Evolve or die.
Texas Instruments once had a powerful computing platform (TI99/4A) and then chose not to continue developing any more personal computers. The DEC VAX was hailed as a wonderful OS. It's now been purchased by HPaq and discarded. Dead languages litter the floor of every university: FORTRAN, COBOL, Pascal, Java^H^H^H^H
VB.NET still has some problems, but every version of BASIC has fewer problems and more functionality than the last.
Microsoft may win in the end, simply because they're not afraid to change the language they own, and they don't have to argue with anyone else whenever they want to change it.
Anyone else find his digs at SUVs and steak to be the cheries on the top of this self-indulgent, pompous, masterbatory, ridiculous article?
(Strings are used instead of a more general list structure, not just for efficiency, but because language comes in strings of characters, and that is how we prefer to consider it when operating on it.)
Note to self: if you ever become semi-famous, don't package ponderous, meandering bar-drivel as serious thought.
In the future, every language will have a lawyer module.
The reason is simple. There will be so many ideas patented that without a lawyer you wouldn't know what patent you are infringing. The language will have explicit instructions before the start of a routine as to what idea it represents. For example,
Begin single-click buy idea
blah
blah
End
When the program is submitted to the compiler, the lawyer module runs first and divides the ideas into
(a) novel,
(b) infringing but doesn't matter
(c) infringing and remove or face lawsuit
(d) infringing but will negotiate.
The programmer then makes appropriate changes to her program.
When the program runs in a distributed environment talking to other programs, the lawyer modules of the two programs will first negotiate with each other. Currency credits will move from one law firm to another and then your program will be allowed to run.
I believe the MTSS portion of PMTSS needs the most work.
For example, in Java and CMP and BMP, Object to Relational "mapping" and XML descriptor files, for example, are poor methodologies or implementations for PMTSS. How many times have we seen poor EJB programming (not using facades, Session Bean wrappers etc) as the major culprit on poor performance? My guess, across every Java project in the world, it is > 50% of the time. The amount of effort to do PMTSS correctly in Java, I feel is a waste of a programmer's time.
SQL, while a fine language, seems to force you against the goal of Third Normal Form. Multiple INNER and OUTER joins in SQL statements that stretch on for pages is needless work.
Perl's DBI (database access) seems more like an add-on, than a core piece of the language.
Maybe it's the way the DB's force the storage and retrieval of data. I know there's "Object" databases and languages like COBOL, but with the amount of effort that goes into PMTSS, my guess is this is 80% of all development time, is work that should be unnecessary. If this estimate is correct, making improvements in this area could be HUGE gains in productivity and savings for companies.
What would this language look like? I honestly don't know yet. It might be a mix of perl-ish, cobol-ish, abap-ish (SAP) XML-ish languages; then again it might be completely new and never before imagined.
I found it interesting that right at the outset he dismissed Java as an "evolutionary dead-end" with no explanation of that comment in the whole article.
The points he makes about what the good languages are seem to show that Java is indeed a good language. Specifically it has an additional layer that allows for abstraction from the hardware/operating system for portability. It takes care of mundane details for the programmer (garbage collection, no need to worry about dealing with memory directly, etc).
Basically the article seemed to repeat itself a lot and show that Java does indeed have a lot of good qualities that he thinks will be in future languages. He also dismisses Object-Oriented programming as the cause for "spaggetti code" without giving any justification for that statement. Finally, he slips in a nice ad hominium attack there by saying any "reasonably competent" programmer knows that object-oriented code sucks.
I think the author's own biases hurt his argument greatly.
Lisp damages the brain.
Having spent a year in University temporarily attached to the cult of Lisp (I'm better now, thanks), I can now spot the tell-tale signs of Lisp-induced brain damage in this "article". Among its more tell-tale signs:
I'm thinking we need to establish a de-programming group for Lisp cult members. Maybe a de-bracketing instead of de-programming?
His claim that Java will be an evolutionary dead-end is already wrong - since Microsoft's C# is clearly heavily inspired by Java.
With more power and clear (presumably very high level) languages, won't everyone be able to do their own programming? It always seemed in Star Trek that anyone with access could just shout out demands to the computer and voila. Would "programmers" then mean those working exclusively at the compiler level in which case one would think that unless the hardware paradigm changes (e.g. quantum computers) then it might really not be much different from programming compilers now.
In 100 years I predict that we will have a way of getting computers to do tasks that is not possible to understand now.
We may not have compilers, for instance, to turn code into machine language. We may write directly in machine language, which might be French for all we know.
As another note, I disagree with his idea of removing numbers as a type from our computer languages. As long as COMPUTERS (a word that originally meant a PERSON who did COMPUTATIONS (e.g. MATH)) are focused on doing math, we will speak to them in the language they understand... math.
But if someone were to invent a device whose base representation was not numbers but was, instead, sound or pictures or language, THEN it would be more efficient to speak to it in its own terms. It would also probably not be called a COMPUTER, but rather something else, perhaps C3PO.
You didn't see _him_ doing any big math problems now did you?
42 - So long and thanks for all the fish.
For example, right now I'm writing a good ol' COM class in C++ and guess how many files have to change, just to add a method? Let's see, that's the .idl, .h, and .cpp. Had I chosen to add a class, I probably would have had to touch another .h or 2, maybe an .rgs or .rc as well. Java is not much better: if you're writing an EJB that leverages Container Managed Persistence, you bounce between interfaces, classes, and XML to make your changes.
The above examples speak to what I mean by modularity, and how I think OOP did help us: it allowed us to localize changes to either a single class or preferably to a single method, instead of modifying code in locations strewn throughout the program. But we've reached the limits of OOP as a mechanism for localization of change; hence, writing OO now for COM or for J2EE, we've lost the benefits of OO.
What comes next? Don't know (yet ;) ). My suspicion is that Aspect-Oriented Programming is a step in the right direction, as it allows us to consolidate code into one aspect code that would otherwise appear in multiple classes. This ability to cross-cut our programs, or right code that is aware of it's own program structure is a powerful idea, I believe: Smalltalk has always had it, Lisp and Prolog mostly did, too. In the C/C++ and now Java world, it seems we always write our programs as if the program itself doesn't exist, only the things the program is about. But the ability of a program to exist as a structure itself, and to allow the programmer to reference that program is a powerfully expressive mechanism. I am particularly fond of Prolog, as it need make no distinction between programs and data. Like AOP, Prolog has the ability to allow you to change the behavior of your progaram by just adding a new clause to it's database. No need to go back to the original source code, and find a suitable place for assertion; just add your new rule, and the run-time will accomodate it.
Finally, the second disagreement: I strongly believe parallelism will be fundamentally woven into how we program, rather than an option we add later. In fact, I believe quite the opposite will be true, that most programs will be inherently parallel (or, more precisely, highly concurrent) by default, with pruning of parallelism and concurrency part of the optimization and fault-correction stage. Why this change? The current crop of popular languages still follow the same model as 50 years ago: programs are a single set of instructions executed by 1 machine in sequence from beginning to end, and the program goes away when the sequence reaches the end. Take a look at a C program, tell me that's not how it works, and tell me that most applications today don't still deal with the same basic paradigm.
However, this model doesn't match the resources available to us now, or 100 years from now. Every OS in use has the ability to support multiple threads and multiple processes simultaneously. Many classes of device no longer remain isolated from other devices, but can instead connect through wired or wireless networks, allowing multiple programs on multiple devices to cooperate. The rise of grid computing suggests that programmers are looking to break out of the 1-program, 1-machine paradigm in which we have been trapped. The current crop of grid computing standards are too domain-specific (I would contend), being focused primarily on batch job scheduling and seamless to large, heterogeneous datasets, but they are clearly on to something.
So where's my money? Something like mobile agents written in Prolog with AOP extensions, capable of tr
Why is paulgraham.com's bookmark icon the Yahoo! logo?
... its syntax will be based on C, and it will still allow:
if (a = 5)
printf("I just made a grave mistake\n");
for backward compatiblity if for nothing else.
While not is regular use, descendants like Fortran 77 are still widely supported. (Both GNU and Microsoft sill make Fortran 77 compilers.)
Best Buy can have you arrested
Comment removed based on user account deletion
Basically the problem isnt going to be with the languages - the problem will be with the concepts that created those language features.
Sorry but Java has already produced a child: C#.
So for Java to be an evolutionary dead-end both Java and C# should die: C# is pushed by Microsoft, Java by all the other (Sun,IBM..).
Both won't die soon..
Exactly. This is more insightfull than funny.
The code will be part of us, except there won't be an us, there will only be I.
The most exciting imminent development in computers is better human computer interaction (HCI). Much, much better HCI. The implications of this are somewhat surprising. Right now you type on your keyboard, its inefficient. Well lets just imagine the key board and type in space then used a camera hooked up to a computer to observe the fingers. This is possible today but pointless. How about if electrodes were planted in your arm and acted on the signals before they reached your fingers. Again, we could do this today. How about we tracked the signals back and intercepted them via an implant in the brain. This is today's cutting edge. However things are moving fairly fast. There already exist mechanisms that can detect brainwaves and people have been trained to move a mouse around a screen just by thinking about it. The interface is kinda clunky at the moment, they have to think about sex to move left and right, or oceans to move up and down. Still, it's a proof of concept, things will improve.
People are talking about wearable PC's, but I don't think it will be long before people routinely use computer implants. With the kind of information density, we can manage these days it's actually worthwhile. Wouldn't it be nice to be able to remember everything ever said to you, or said by you. If nothing else, it would be a great help when you get into one of those "he said, she said" arguments. With todays technology you could build a portable device that remembers and voice recognizes everything you ever hear for five years. A little further down the line, and you'll be able to get an implant which will let you remember everything you ever saw. When the interface gets good enough, it will be pointless to worry about whether its stored in neurons or stored on a chip.
British Telecom are already working on the foundations for a device that could be installed in the brain to store everything you ever see,hear feel touch or smell. Its called project "Soul Catcher", I'm not making this up.
And for all those out there who think we're going to evolve into a race of cyborgs: you're crazy... it'll go MUCH further than that.
After all, once people have got decent hardware implanted in their heads, do you think we're going to be satisfied with a 200baud connection (human speech). No, we'll use the hardware in our heads to communicate with other people (through the hardware in their heads). With sufficient communication, it stops making sense to talk about multiple communicating processors - you end up with a single, massively parallel computer. When people get used to taking part in the enhanced meta-brain it will become literally unthinkable to go back being an individual entity. You might as well try to imagine what it would be like to be a mollusc. Don't believe me ? - we already have this idea of "however did we manage without the internet", it's only been in mainstream use for 2 years !
We will become the Borg, but not in a bad way. If you combine the properties of humans and computers and end up with something which does not have the best of both, then you haven't done it right. The internet will evolve from being a global suppository of all human knowledge into actually being humanity. We will be the nodes on the network. It won't take long either. Just a couple of hundred years or so at this rate.
Of course, this is bound to cause a little friction during the transitional period. Some people will doubtless object, and probably consider the end of humanity as we know it to be a bad thing. I don't think the induhviduals (as Dogbert would have it) will stand much of a chance though, they'll be seriously out-smarted and the reliance which regular humanity places on computers will make them pathetically unable to fight against those who have plugged in. The HumaNet might have to annihilate them to protect itself. It's a bit like the old ches
http://rareformnewmedia.com/
The programming languages 100 years from now won't be a programming language the way we thing about them now.
Or I hope they won't be, since they all suck right now.
Natural language interaction, sure.
"Computer...turn on the lights. And make it warmer in here" might be OK for human-computer INTERACTION. And, what the heck...for computer-computer interaction, too, in a pinch.
But as a "programming" paradigm? I guess it depends on what you mean by "programming" Scripting, almost certainly. But how about the "primitives" (obsolete FORTH reference) that allow such interaction to be parsed?
Ugh...I just had an ugly thought: Some por schmuck a hundred years from now is "programming" in a language that looks quite a bit like the old Infocom command parser. And he's writing an application that looks like something along the lines of trying to complete ZORK I in one long sentence...
Now think about the evolution of HTML. I am one of the few obsolete cavemen I know who still actually write HTML (and descendents) code by hand. How many people do you personally know who can read, write and create nice looking web pages with their favorite web page application, but would be completely lost trying to understand "http://www.w3.org/TR/REC-CSS2/" ?
I think it quite possible that the programmers of the future will in this sense more resemble web page designers today than programmers today. To some sense this has already started with VB and other languages with drag and drop controls in an IDE.
I can imaging something like CSS for programs which allows formatting and naming conventions to be specified independent of the content(actual program), and who knows what else. This would take care of wretched abominations such as WPARAM.
Although the languages of the future will be extremely important, very expressive and very powerful, I doubt the majority of the programmers of the future will actually type them on a keyboard directly, or (see CSS2 doc above) even know how if they wanted to. It will be more important for them to visualize the problem they are trying to solve in the proper context and in the style with which they are most comfortable and effective.
I think this is a more positive thing than it may sound. Sometime after the death of m$.gov, I predict a re-discovery of the field once called "human factors" that has been so abused and stifled by them. Programmers will be empowered to express high level concepts without having to be concerned with low level crap like the "unsafe" keyword. I hope to see this in my lifetime.
So say you want a chess program. You feed in the rules of the game in a special language, and it generates a program to play by searching for the program that successfully implements that.
That sounds fantastic! You'll never have to write another line of code ever again!
Hold on, don't get excited, it's not that simple.
First, just because it plays a game of chess, doesn't mean it plays a good game of chess, so you might still have to tell it in quite high detail what 'good' means in terms of your program specification.
Secondly, it's very easy to tell it the specification incorrectly. Specification errors are very common in computer software already, and having the highly precise specification language that you'll need doesn't make it easier, although the machine is less likely to screw up the implementation, so you're still better off than coding by hand.
Still, in some cases, where the problem is easy to state, you should have a solution program in just a few minutes; whereas now it could take hours or days.
Anyway that's where I see it go. There are some existing implementations of this kind of thing out there already, but they tend to be small. For example somebody wrote a program to find the shortest program to perform certain operations for gcc backends. You pretty much just point the compiler at a new processor and optimum code pops out, it's kind of neat. But currently this is limited to maybe 15 instructions long. I think that this will grow enormously, particularly if you throw away the constraint of having to be completely optimal, and allow 'only slightly suboptimal' programs; and faster and faster processors are coming down the pipe; so 'searching for code' is becoming more practical.
Oh yeah, and the idea probably works for parallel and quantum computers too. Parallel searching for optimum parallel code, and so forth.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"A friend once asked me, "When will computers be so easy to program that a six year old child can do it?"
I replied, "When six year old children can specify a task with zero ambiguity."
Its perfectly fine to have some english like programming, it simply must be as unambiguous as possible:
Computer, load memory location 40343 into register 6.
Computer, add register 6 to register 8.
Computer, if overflow, jump to address 52895.
I'll stick with C++.
The author's claim that Java is a dead-end language like COBOL is patently ludicrous, and by dismissing Java out of hand, he undermines the rest of his article.
Java is essentially a re-implementation of C; it's a very C-like language in syntax and semantics. The goal was to do an OO language based on a familiar paradigm. In addition to eliminating some of C's less endearing traits, it brings two things to the table, both of which which will shape future languages:
1. Re-usability. Sun offers you a crapload of very usefull re-usable objects in their JDKs, and people like the Apache project offers you even more. The ability to do insanely complex prrojects with tiny amounts of effort is one reason why Java rules the corporate enterprise. Future languages will start looking more and more like a big box of legos: find the parts you need and plug them together.
2) A universal computing environment: you can't write to the metal in Java, but it's not as slow as interpreted languages like Python and TCL for gigantic computing tasks. Any project, no matter how monolithic and task-optimized, is as portable as the VM is. Anyone who's had to manage a platform migration for key buisiness applications, from VAX to Solaris, say, or worse, from S/360 to Windows, knows the pain of re-implementation. That pain is gone when you use a VM-based language like Java.
Projects like Squeak are looking more and more like Java these days, in terms of re-usability and VM-based platform independance. The only missing piece of the puzzle are popular VM environments not tied to any one vendor: Java needs to cut its dependancy on Sun JDKs, or it will be supplanted by another language that is independant and standards based.
This isn't to say that other languages aren't going to evolve, too, or are useless because they're not like Java. Ayone who programs in the new interpreted scripting languages: PHP, Python, Perl, Ruby, TCL, Scheme, etc, etc, can attest to the power of the that approach to modern computing.
On the other hand, I really don't see any new compiled-to-the-metal languages emerging. Fortran is used for high-performance computing, Forth is used for tiny computers, and C/C++ is used for system programming. It will very likely be the same way in another 20 years, or another 50. The difference is that applications will slowly drift to either VM languages or interpreted languages from binaries compiled from source.
He talks about the descendants of Algol and Fortran merging, and then has a throwaway line about that never having happened to actual species. I think it's interesting that something like that has probably occurred at least twice in the history of life.
;)
Mitochondria and chloroplasts are two of the most complicated organelles, cellular machinery found in complex organisms. Chloroplasts, found in the cells of higher plants, carry out photosynthesis, converting solar energy to food (glucose). Mitochondria are found in both animals and plants, and use oxygen to extract energy from nutrients. Both have very complicated mechanisms that we haven't completely elucidated yet, and are crucial to the survival of their respective host organisms.
Here's the weird thing, though: all of the chloroplasts and mitochondria seem to have descended from bacteria that that invaded (or were taken in by) ancient cells, back in the days before multicellular life. These organelles have their own rather simple genomes, and reproduce independently in the cells of the "host" organism. What started out as symbiosis on a cellular level has evolved over billions of years until neither the complex eukaryotes nor the simpler organelles can survive without the other.
A little offtopic, I admit, but I couldn't let the opportunity for a lecture pass me by. At least you learned something from slashdot today
My other sig is also a
because they can take advantage of parallelism by virtue of the fact that each function call does not produce any side effects. So a grossly inneficient Lisp program on a uniprocessor can be made to be blindingly fast on a million CPU machine. Erlang would also benefit since it uses this same model. Non-functional languages like C and Java don't have a snowball's chance in hell of scaling to a million processors.
Now we have two ideas that, if you combine them, suggest interesting possibilities: (1) the hundred-year language could, in principle, be designed today, and (2) such a language, if it existed, might be good to program in today. When you see these ideas laid out like that, it's hard not to think, why not try writing the hundred-year language now?
I think the same thing would be true of the 100-year operating system, and that these two long-term visions need to be aware of each other. Every time I read about some amazing new OS architecture, like EROS for example, somewhere in the literature there's some essential feature that the designers think cannot be done unless the language & compiler writers get together with them.
Alas, the long-view language designers are off in their own world away from the long-view OS designers. This, combined with the seemingly-insurmountable problem of propagating the new cultural elements of programming, makes me think that we're toast. In 100 years, the state of the art will be only slightly less miserable than it is now. There will be fascinating research projects off in a corner, but no one will use them because of retraining issues, or abysmally-inadequate libraries.
If we're smart and we follow the author's advice, however, maybe 100 years from now the libraries will be there, and the ideas will have propagated.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
One of the main points in this article is programmer's time is more precious than machine time.
Programmer's time might be more precious than machine time when writing small scripts and proof-of-concept code, intended for a TINY audience, but USER time is more precious than programmer time when developing real applications, and USER time wastage is directly correlated to machine time wastage.
I agree with much of what he is saying - about CPU power being massivelly wasted. I honestly would not have believed back in 95, that the performance (or should I say user experience) I got out of my 100Mhz CPU with 32MBs of RAM will be roughly comparable with my 2200Mhz machine with 700MBs of RAM when using most applications (GTA III being a notable exception)....
On the other hand I, can't believe that he would suggest that we go forth and waste a million times more power for NOTHING!!!!
My vision of what will revolutionize computing is the ability of hardware to be non-static. That is, hardware would be able to change itself ( much like the human brain), and theoretically, make EVERYTHING hardware accelerated.
You would buy hardware like normal, but what you would actually get would be a little rectangular cube full of goop that goes into something that would represent your motherboard. Then you would have to load the layout itself, and the CPU morph itself and make the correct pathways.
Another related thing would be the memory structure. Right now memory is like one long chain (or a bunch of connected chains). It would be interesting if memory was like water, where you could arrange each unit (a byte I guess) in any pattern you would want, and you would have a sort of "hardware linked list".
I think this change coupled with the new CPU concept would make the languages 100 years from now more powerful, as your hardware would be completely configurable, and you would do more abstract things without having to simulate them.
This could also pave the way to AI, which I believe needs a system where its hardware can change itself almost completely.
Everyone memorise this table
When it comes to designed by then -> maintained by remember this table ->
key:
Wrote it -> maints it = complains code is "bad"??
bad coder -> (good coder) = complains code is "bad"
good coder -> (bad coder) = complains code is "bad"
bad coder -> (bad coder) = complains code is "bad"
good coder -> (good coder) = no complaints.
I wonder if he might be too pessimistic in terms of thinking how much programming then will look like programming today. I wonder if artificial intelligence might be able to play a huge role, letting people describe the program they're looking for, seeing models appear on screen, editing them, and running simple tests.
This might not be as far fetched as it sounds. Computers in 1980s were able to run a decent parser in games like Zork. If you limit the scope of what a program needs to know about the world (and I'm not saying programming will be "write me an accounting system", these programmers will talk in terms of screens, what's stored, what caluclation is done, etc, in a very high level way) then parsing and understanding enlglish is pretty much a solved problem.
Maybe casual programmers would right like that, and then experts would be able to check in on the generated "real code".
This type of programming won't be usable for everything, but I certainly can see it in place of Office VBA and even COBOL (which was an attempt at the same thing, letting businessmen describe their problem in something like English, and a lot better at it than people give it credit for. Computers used to be divided into "business machines" (that would often work in packed decimal format, and other currency and integer friendly things) and "scientific machines" (that used floats and had different priorities) I think the same gap happened in programming, but the "scientific" paradigm became dominant, partially because it was more effecient on the limited hardware available.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
Here's what I got out of it:
Nobody really has a clue what programming languages will be like in a hundred years, but if all the Perl and Python weenies would learn LISP then maybe we could get somewhere within the next decade.
Please donate your spare CPU cycles to help fight cancer and other diseases
Use the right tool for the job.
... shooting yourself in the foot. You still have to build an application on top of it, so use a database and nice well-behaved database clients. (like a SQL news server on port 5555 - all the headlines you can get - make the format standard and that's all folks)
... I don't really know ... Microsoft, standard groups and university courses?
Using XML to write config files is SHOOTING yourself in the foot. You're better off using natural language. For one, it's easier to parse.
Using XML to represent/pass around data is
That leaves XML for
And really, really masochistic developers...
I had high hopes to read something *really* interesting based on the lead up, only to be sorely disappointed once the article actually unfolded.
...anactofgod...
Before anyone can hope to write an article on the nature of programming languages 20 years into the future (let alone 100 years into the future) that stands a chance of being insightful, one should pick up an advanced applied physics book, brush up on quantum mechanics, and then move on to researching the state of development in the area of quantum computing.
This article will prove to be as prescient as an article titled "100 Year Buggy Whip" would have been in 1903.
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over. We can see this happening already ... I predict a similar fate for Java
A counterexample, a descendant language / language heavily influenced by Java is of course C#.net.
IMHO Java will likely be seen as the time when garbage collected languages went mainstream.
My Karma: ran over your Dogma
StrawberryFrog
The lists he's talking about are (I'm guessing) actually S-expressions, which can express anything XML can.
I suppose if we get handwriting recognition to the point where it is everywhere and can pick up symbols pretty well, then APL could make one heck of a comeback.
Heirarchy will continue to exist. It's the only concept the human brain has to deal with complexity, call it what you will but you classify and associate things in to hierarchy whether you're aware of it or not. I see no reason to believe right now that processors will have more advanced instructions than they currently do now; they may be very different (like optmisitic registers that know values before they have been calculated or something) but they will be on the same order of complexity. The atomic operations will probably remain at the same order of complexity in biological processors, quantum, or SI/GAAS/whatever based transistor processors. I don't see how sort a list will be done without some sort of operations to look at elements in it, compare them, and then change their ordering. Even with quantum computers you have to set up those operations to happen and cause results. That being said there will always be an assembly language.
On top of that there will always be a C like language, if it's not C, that will be a portable assembly language. Then there will be "application" languages built at a higher level still. That won't change, for good reasons, it's just too complex to push the protection and error checking and everything down a level. I'll give examples if you want them. The easiest one that comes to mind is something like Java garbage collection and how programmers assume that it has mystical powers and are shocked when they fire up a profiler and see leftovers sitting around, it's a very complex piece of software and you expect it to go down to a lower level? The lower levels have their own problems keeping up with Dr. Moore.
I think the other biggest area is that reliability needs to go up by several orders. Linux, BSD, Win2000 and WinXP are pretty reliable but they aren't amazing. I've seen all of them crash at one point or another, I may have had hand in making it happen and so might have hardware; either way it did. To really start to solve the issues and problems of humanity better we need to have more trust for our computers, that requires more reliable computers and that require different methods of engineering. The biggest thing going on in programming languages now to deal with that is Functional Programming. In 50 years I could see some kind of concept like an algorithm broker that has the 1700+ "core algorithms" (Knuth suspects that there are about 1700 core algorithms in CS) implemented in an ML or Haskell like language, proven for correctness, in a proven runtime environment being the used in conjunction with some kind of easy to use scripting glue. And critical low level programming will be proven automatically by an interpreter at compile time, they are already making automatic provers for ML.
Recently I've been learning Python and working with Zope. Wow. What a change from the old days of C. What Python and Zope do that C wasn't good at is deal with complexity very elegantly. I'm sure a lot of other newer languages are this way, too.
I can only imagine what a single line of code will be expected to do in the future - and the degree which the program will be expected to "understand" large chunks of information. The idea that a program be able to do things quickly and self-manage most of the details will be important...
Of course, in 100 years, the computers may be reprogramming us...
-- $G
Besides, the syntax of English language is a lot more complex than that of most common programming languages. Because of that it would be easier for non-native English speakers to learn some simple scripting language than to learn English well enough to avoid syntax errors on line XX.
You know what, on a second thought I realize that 100 years is not enough for the humankind to move away from being monkees. Thus, Java forever!
Less is more !
That's not a description, that's a conversation. A program is a description.
That's not to say that an interactive system isn't a good way to create a program. The conversation between the programmer and IDE could be recorded verbatim (imagine a word processor saving a document by recording every keystroke, even block moves and deletions), or the results could be recorded in an incomprehensible binary format - like those "resources" you need to design to make MFC dialogs and the like. Or the results of the interaction could be stored as a distillation of all the answers from the programmer, basically the IDE tool describing what it learned in its conversation with the programmer.
There - that final description, that's the program, and whatever format you use to unambiguously describe the data and precisely how it's used, that's the language.
The process may be like spoken language, the program must avoid any ambiguity and so can't be.
It's already been in use for XXXIII years...
I agree, I didn't really get throught the article much past the idea of strings just being lists. We have been down the path of loosely typed languages like VB4 and had a bad time of it not because they were inefficient (although that was a complaint) but because they were error prone. Whether it technically is a list or a structure is somewhat irrelevant. A string is a type of information which you expect to be able to do some things with and you expect it to be impossible to do other things with. Just because you could call all data just one thing doesn't mean that you think of and work with all data as one thing. That was the lesson we learned, badly, with variants. The broad evolution of languages (from binary, to assembly to high level languages to prebuilt function libraries to structured programming to object oriented programming) has exhibited a consistent trend away to greater abstraction of the machine and having the language represent the concepts of the task at hand rather than the concepts of the hardware. But calling everything a list rather than a string abstracts away from the task at hand (I want to find the first word in a sentence, for example) Parallel with this there has been a pendulum effect between languages that are terse and symbolic and those that tend to use descriptive words. A typical example is Pascal using BEGIN and END statements and C just using curly braces {}. The most popular mix right now seems to be terse logic but wordy object, function, and method names, but that will change too.
This "evolution of computer languages" is of course an unsubstantiated myth made up by pagan scientists. Surely we all know that the Computer Languages (yes, all of them) were created 4004 years ago, on July 23rd, around noon. ALL the Languages were created back then, and NONE have ever become extinct. LISP and VisualBasic did in fact live side by side, unlike what some people (blasphemous scientists) want you to believe.
I think not! Syntactic sugar is critically important.
Take scheme, for example. No for loops. Ack!
Here's your computer language with as few axioms as possible:
1 0
The wheel was invented, it was good. We have continued to refine it over the years, but a wheel is a wheel.
Same thing with C (and to a certain extent its predecessors). At least as far as current computer architecture is concerned, C "is it". C breaks down to the machine level nearly perfectly and supports a notation similar to normal mathematics.
All we need to do with refine C. Note that I'm _not_ talking about the current crop of C descendants. You know, those "OO" languages like Java, C++, and C#. If you have ever worked on a complicated OO project then you know about the myth of OO and reusability. OO gets just as complicated as anything else, and often more complicated because programmers often go too far with OO practices when they are not needed.
By refining C, I mean adding things that we know we need from past experience. For example:
- C needs some sort of modulerization. Namespaces would probably work. Keep binary compatibily though, just prepend the namespace name to external symbols (see: Cyclone)
- C needs some sort of powerful macro/template system. Something turing complete, Lisp-like, or C++ template-like. Somethining that supports generic programming.
- Make const references the default object passing mechanism (see: Java). Have special syntax for modifyable objects and pointers. But discourage the use of pointers.
- Have some sort of default memory management. A garbage collector that can be turned off if you need performance.
- Arrays should be bounds checked by default with special syntax to disable the check when performance is needed.
And of course there are other things. But I'm trying to think of known working concepts that have been proven to work and be good. Kinda like what the C99 extentions have added to C already (inline functions, etc.).
The ratio of people to cake is too big
The programming language of the future:
Computer:
using (doorknob) {
do (something_useful) for (2 hours)
worth ($100)
} and (phone_me) when done
while (spam) :
print "Hello Spam";
wow, an article about the future of programming language where a search for "interface" and "template" fails. my conclusion: worthless article. coding an implementation of an interface on a platform is the easy part or computer science. coming up with the interfaces and designing the platforms is the real work. well engineered interfaces means hooking code together (in different languages, running on different platforms, etc.) is easier and in this respect real-world computer science is still in the dark ages.
A string is a unit of human language. It has methods, starting from trim(), spellCheck() and speak() (yes, you have that in Cocoa today) and leading to things like translateToLanguage() and undestandAndExecute() in future. These methods will be very confusing for a list. Just like square root will be a strange concept for a number represented as a list.
The article kind of sucks. It makes a lot of unfounded claims, like that Java will not influence the future, but Python will. It fails to flash out any interesting things we'll be able to do. If anything, it's talking about the future of academic research languages which tend to be minimalist. By contrast, good real world languages are feature-rich, but the features are hidden away until you need them.
So I bet a future language will have numbers, strings and lists. Object-oriented programming will florish in the sense that you will address real-life objects as instances of language types and you will be able to program in new types.
One difference is that you will be able to give names to your objects and collections of objects and also speak to them in a human language rather than only refering to them in a program. Like, "All window blinds, please open". Also, an object will not just refuse to run an unknown method. If you ask your pet robot to cook a meatloaf, it will ask you questions or watch you, or another robot do the task once and after that robot.cookMeatLoaf(int weight) will be fully implemented and available.
In general, programs will not be visible as text, or a formula in most cases. You will lay down a program by speaking to the computer in natural language first. This will create a very imprecise, buggy program that will be executable as a best guess using AI and fuzzy logic. Then you will need to continue clarifying it, like telling your robot that cleaning the floor doesn't mean removing guests until you feel the result is good enough. However, the computer will remember your previous programs and clarifications and try to apply them to the new one automatically. But, to make very precise qualifications, you will still switch from human speech to plain old programming.
BUT, this will only apply to programming for high-level, every day tasks. To solve a square equation, you will still write, or type a square equation. Mathematics and physics applications will still have access to programming languages much like the ones today, except executed at a great speed and still using AI to detect possible bugs. So will programs for very precise control, like spaceship navigation or mass manufacturing. If paper survived for hundred years, even with radio, TV and Internet, so can a traditional, equation-based programming language - for use when you are thinking about equations.
Actually I think FORTH has that baliwick... or is that footing yourself in the shoot?
In 100 years there will be computers that can run Java apps smoothly?
Not quite. But I think that the paradigm of the future will be the one of the past. Don't micromanage. Programming (as well as hardware design) is an exercise in percisely defining what a machine is to do. Better to tell a machine what the goals are and have it figure out the intermediate points out. A better way IMHO to dealing with an ambigious world. This will be resisted by most because it means a certain loss of control, even though real life problems already represent a loss of control by our inability to grasp them in their entirety, and break them down appropriately to fit our presently rigid level of technology. Programming (and other design) will be careful steering from intermediate goal to goal. As our knowledge and experience grow, the distance between goals will grow as well, to the distant point of were we can give start and end and say "go do this".
The evolution of languages differs from the evolution of species because branches can converge. The Fortran branch, for example, seems to be merging with the descendants of Algol. In theory this is possible for species too, but it's so unlikely that it has probably never happened.
No kidding. The evolution of languages is probably different from the evolution of species because, well, they're languages. Paul Graham seems to have overlooked the fact that there's already a fully-formed field of study devoted to things that evolve like languages. It's called linguistics. He's probably heard of it.
When I was a kid, I had a grand old time flipping through the back pages of the unabridged American Heritage dictionary. One item of interest in there is a (then current) language tree illustrating the radiation, convergence, and development of linguistic families derived from Indo-European. The dictionary's editors assured their readers that, while informative, the printed tree was a gross simplification of the real state of affairs.
My point being, I am inclined to suspect that a field that can examine modern languages and scraps of historical writing and extrapolate back to reconstruct languages dead for thousands of years, has the tools to make sense of fifty years of computer languages and get a sense of the general trends going forwards.
Quantum mechanics: the dreams that stuff is made of.
Then what you have purchased is a TRUCK. An SUV is nifty marketing term for soccer moms that can't buy a mini-van for when dad has to be seen in it. Its these purchases that he's saying are ugly.
The SUV carrying a single person with no cargo around city streets is wasteful.
All of this reminds me of the joke, "Four wheel drive just means you get stuck farther out."
t
What's the source of the quote in your .sig? I've read it before, but I can't remember where.
I found the meaning of life the other day, but I had write-only access.
Clearly this author loves Lisp, and hates Java and object oriented programming.
And clearly, his opinions in no way reflect mainstream programming today.
Let me make a prediction. Lisp died in the early 90ies. Java's ideas (especially the virtual machine) will survive and take over.
...Neither of which has done anything to advance the state of the art in programming languages, even if your claim were true.
The one thing I have confidence in about programming in the future is that sooner or later, the tools and techniques with genuine advantages will beat the "useful hacks". Java, C++, VB and their ilk are widely used today because they can get a job done, and there's not much better around that gets the same job done as easily.
Sure, there are languages that are technically superior, but they're so cumbersome to use that no-one really notices them, and when they do, you don't have the powerful development tools, the established code base of useful libraries, the established user base of developers to hire, etc. When we get to the point that languages with more solid underlying models catch up on ease of use, then we'll relegate the useful hacks to their place in history as just that. Until then, we'll keep using the useful hacks because we have jobs to do, but don't expect the tools of the future to be built on them.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If we not destroy ourselves, in 100 years the machines will take care of us, code writing included.
Language structure is determined by two things:
1. the target machine architecture
2. the range of expression required by the programmer and/or workgroup
Java is "successful" but it really looks a lot like Algol and Pascal,
as does C++. The range of expression is greater in the newer languages
(object-orientation in Java and C++) but the forte is still that of
expressing algorithms in written form to be used on a stored-program
digital computer.
WILL WE STILL BE PROGRAMMING?
Take one example -- genetic programming. If you had a programming system
where the basic algorithm could learn, and all you had to do is set up
the learning environment, then you'd be teaching rather than programming.
In fact I believe THIS is what most "programmers" will be doing in 100 years. The challenge
will be defining the problem domain, the inputs, the desired outputs; the
algorithm and the architecture won't change, or won't change much, and the
vast majority of people won't fiddle with it.
But if HAL doesn't appear and we aren't all retrained as Dr. Chandra,
I believe we'll still be handling a lot of text on flat screens.
I don't think we'll be using sound, and I don't think we'll be using pictures.
(see below)
So predicting what languages will be like in 100 years is predicated
on knowing what computers and peripherals will be like. I think progress
will be slow, for the most part -- that is, I don't think it will be all
that much different from how it is now.
HOW WILL OUR RANGE OF EXPRESSION CHANGE?
If we relied primarily on voice input, languages would be a lot more
like spoken natural languages; there would be far less ambiguity than
most natural languages (so they'd be more like Russian than like English,
for example) but there wouldn't be nearly as much punctuation as there
is in Java and C++.
If we rely primarily on thought-transfer, they'll be something else
entirely. But I don't think this will come in 100 years.
How is a 24x80 IDE window different from punched cards and printers?
Much more efficient but remarkably similar, really. It would not surprise
me if we still use a lot of TEXT in the future. Speech is slow --
a program body stored as audio would be hard to scan through quickly.
Eyes are faster than ears so the program body will always be stored as
either text or pictures.
Pictures - well, pictorial languages assume too much of the work has
already been done underneath. "Programming isn't hard because of all
the typing; programming is hard because of all the thinking." (Who
wrote that in Byte a couple of decades ago?). I don't think we'll be
using pictures. When we get to the point that we can use hand-waving
to describe to the computer what we want it to do, again we'll be
teaching, not programming.
HOW WILL THE ARCHITECTURE CHANGE?
If the target architecture isn't Von Neumann, but something else,
then we may not be describing "algorithms" as we know them today.
Not being up to speed about quantum computing, I can speak to that
example...but there are lots of other variations. Analog computers?
Decimal instead of Binary digital machines? Hardware-implemented
neural networks? Again, I don't see much progress away from binary
digital stored-program machine in 40 years, and I think (barring
a magical breakthrough) this may continue to be the cheapest, most
available hardware for the next 50-100 years.
SO WHAT DO I THINK?
I think IDE's and runtime libraries will evolve tremendously, but
I don't think basic language design will change much. As long as
we continue to use physical devices at all, I think the low-level
programming languages will be very similar to present day ones:
Based on lines of text with regular grammars and punctuation,
describing algorithms. I predict COBOL will be gone, FORTRAN will
still be a dinosaur, and Java and C/C++ will also be dinosaurs.
But compilers for all 4 wi
Was that a statement about microsoft itself or it's treatment of XML? I can't tell.
2. You're positive of this? How do you know? Maybe they do, maybe they don't. Maybe now we'll find out. We certainly weren't going to find out while the UN conducted its searches.
3. In a way, you could say that we already have. What might happen to neighboring countries if Iraq develops itself as a productive, democratic society (with something resembling unrestricted media?)
I sometimes wonder if some of the vocal critics of this war are just utterly removed from reality. Or perhaps it's me, and I'm being snowed by a huge conspiracy of every American and British media organization (who must be very good at coordinating their "lies"?)
How do people ignore the long list of reports from exiled Iraqis and other sources about the horrid crimes the regime has committed against even its own people? Maybe you think it's their problem, and they should overthrow their own government without our help. It's probably pretty difficult to do that when you're not allowed to assemble to even plan such a futile action.
Here in the US we're free to assemble and to say negative things about our leaders. In many countries it's just not allowed. In many countries, former Iraq especially, even being suspected of saying negative things about the government could lead to death or worse.
I could go on, but from my experiences with people like you in the past, I know it would be pointless. I'd just hear some irrational, emotional response. Certainly I'd never get an answer to a simple, direct question.
.sigs are for post^Hers.
Then there will be no need for any programming language, the computer will write what it wants in bits.
SUV's have their place. I always felt the Suburban was a little over the top, but I'm sure even that has its place.
On the other hand, buying one as a family car to only be driven around the roads of London (or many north american cities) doesn't quite fit the point of necessity. I think that's probably what the author was really thinking of, not saying they were totally pointless.
Of course, I'm often wrong...
I don't think you are really who he is talking to. He is talking to my sister in law who drive a SUV to work, in the city, because it is 'bigger' than other vehicles, and therefore it must be safer. She has very little justification for it, but drives it anyway.
Nerd rage is the funniest rage.
I predict two kinds of computer languages in the future. One will be a stylized form of English. You write some documentation describing your data entities and operations. It wont have a rigorous vocabulary or syntax like an OOP language. A natural language complier will extract this for you.
This was one of the original intentions of COBOL with its quasi-natural language objects like sentences and paragraphs. However COBOL was not flexible enough to resemble natural language and too bloated for efficient notation.
I think something CYCL, the terminalogy language of the CYC knowledge project, is moving in that direction. If they'd only get rid of those parentheses held over from the LISP implementation...
The other direction will be to directly implement the compact symbolic algebras that scientists already use in mathematics, chemistry, etc. Mathematica goes pretty far in this direction. The compiler will automatically arrange all the storage, and map the serialization or parallelization.
Graham makes a lot of noise, but in the end withers away in his LISP-oriented madness. I think he misses the boat in a serious way when he says parallelism is a dead end, and that it'll always be a feature utilized explicitly by the programmer. I was hoping to see the article talk about the future, but instead all I saw was a guy mumbling about the past and present. Here's my take on the future, really casting out there:
For a LISP programmer to say that is unthinkable. That's one of the major reasons LISP was useful, because it is a functional language, and as such can be automatically farmed out to multiple processors. Several companies were formed back in the 70's around that concept.
The problem is, functional languages have tended to be very stodgy, very limited, and awkward to use (see Lots of Irritating, Stupid Parenthesis) for non-mathematicians. Programming is increasingly done by lesser educated people... fewer and fewer of whom even have a CS degree. This trend will continue.
I predict that in 50 years, the dominant language will be a design language that is largely a dataflow description. A person describes where to receive the data (web, ftp, file on disk, from the output of another function somewhere), what kind of processing or manipulation to perform in somewhat general terms*, and that's it. *General terms means in terms of previously-defined operations. After a number of years, the libraries will be so rich and specialized that a user will not call a function by name, but instead describe in general terms what kinds of operations to do, the compiler picks several that sort of match, rank them in order, and use all of them in parallel, effectively forking the program for each different path it takes.
By the end of a program, there will be trillions of possible ways it would run. A few will be correct. The user will then have the arduous task of weeding out those which do not match expectations, by looking at the outcome and selecting them. The compiler will help by grouping results by similarity, and automatically rejecting obvious failures (divide by zeros, etc).
Additionally, the compiler is the runtime environment. This is where parallelism comes in, initially. Later, when a few working prototypes exist--it may be difficult or impossible to distinguish between some versions immediately--the compiler does all the optimization for the user. The longer it runs, the more structures it identifies and changes the internal representation of, and changes algorithms, and so on, until it tweaks the performance to an ideal state. This already happens today with certain tools, but on a very limited instruction-reordering scale. The scope of such code rewriting will increase dramatically as the language for describing operations becomes more abstract and less strictly tied to individual blocks of code. It will effectively use genetic algorithm techniques to determine the best execution rate and the user need not be involved.
The compiler/environment also naturally distributes its work across multiple processors, multiple pools of memory, and mulitple external storage devices. It knows how to connect up to trusted machines and devices (similar to how Bluetooth already works, but different medium), and distributes to those as well. As the article states, the core of the environment can be extremely simple, with all the advanced functions being implemented in terms of that basic core. Porting the core should be an hour's work, at most--that's how thin it would need to be. Thus, future computation would be capable of effectively leveraging large grids with practically no user involvement, and could extend or be carried around by portable wireless devices, or live in enclosed LANs, or whatever, without having the program care.
So, to further disagree with the article, I would see it as a convergence of LISP, Java, C++, and Visio. It would take (most of) the functional aspects of LISP, the intelligent enviro
Any connection between your reality and mine is purely coincidental.
Recursion is your friend, perhaps I skipped to the point to fast for you:
The reason it is unimplementable is "Who watches the watchers?". The framers of the US constitution had this same problem.
If you assign one AI to supervise another, than that supervisor needs a supervisor as well or IT will have no moral code of its own. So then the "asimov morality chip" will behave like a classic symbiote, and steer the decisions it allows of the robot it controls to its own ends as well.
You can see that it quickly leads to either infinite recursion of watchers, or the need for some sort of circular heirarchy, which is subject to imorality as a group rather than an indivudual.
As for making the arbitrary assumption that just because someone is studying something that there will be progress: that is sheer hubris. We can predict that new things will be discovered, we cannot predict what avenues these discoveries will come from.
AI has been studied for as long as there have been computers. So far, I have seen zero empirical progress in terms of sapience. That has had little effect on people's predictions of future progress in the field, stangely.
I just recently purchased an SUV, and it was not so I could buy a "masculine" van. It was because I live in Montana where a four wheel drive vehicle is almost a necessity.
You are probably one of the four people on Earth who actually use SUV's for rugged mountains and snow like they show in the commercials. Never thought I would encounter one. Can I have your autograph?
Table-ized A.I.
True however anything from the future is going to be the product of "limitation avoidance". What limitation (usually human) does strong-typing address? What about weak? As I point out elsewere (AI-Baby steps) programming presently is an excercise in micro-managment. Advancement would be better if we asked ourselves what limitation is this feature trying to address? Is there maybe a better way? I find that some problems fall, by asking "Whom (not necessarily a person) could have the particular answer to my question?" Maybe by looking earler in the development process one can "bring down" the answer, or even looking sideways, or simply waiting till it can be answered. As I've pointed out in the past programming is still a bit disjointed, and not always the smooth transition from "I have an idea" to "I have a solution". Information gets lost, or distorted, or sometimes not even generated during the whole trip. maybe we need to develop a better way to ask good questions.
Perl.
Perl5 had switch/case statements added to it by Damian Conway, at least (I think there are other switch/case implementations, but I can't recall them now). I have little doubt that I could have added a switch/case to Perl5 (although Damian's would be significantly more elegant than mine would have been). Perl6 should enable language modification easier than Perl5.
Most of what you mention (class libraries, object frameworks, class and instance behavior, etc.) are all available in Perl5. Perl6 looks to be shaping up to be even better than Perl5.
I don't know why Smalltalk didn't catch on any better than it did -- I remember reading the BYTE articles back in the 1980's on Smalltalk...
"Display some adaptability" -- Doug Shaftoe, _Cryptonomicon_
Strings aren't lists, they're structures.
That's a boring implementation detail. In C, strings were lists. It performed very well and was consistent with the way we dealt with other arrays, but lists weren't done very well so we had problems.
In Haskell, strings are, again, just lists. "blah" is syntactic sugar that is helpful, but just means a list of characters.
This means that everything you can do with lists, you can do with strings the same way. Don't like capital letters, fine:
Prelude> map toLower "This String Has CAPS"
"this string has caps"
No special string handling is good.
-- The world is watching America, and America is watching TV.
Computer programs are answers to particular problems (or questions). And like in the Hitchhiker's Guide, the Question can be harder to figure out than the Answer.
Gathering the requirements (in plain English) and resolving the gaps and ambiguities takes up a significant percentage of the time allotted for a project, especially if the project is highly complex. This is an exceedingly difficult process for humans. It's beyond the boundaries of what computers can be expected to do, at least for the foreseeable future.
Figuring out the Answer will probably become easier with improvements in software languages, methodologies, and hardware. Defining the Question will become a lot harder, especially with people expecting more from their software every year. Transforming ambiguous and incomplete English requirements into highly specific Code will become even more of a bottleneck than it is today.
The article seems a bit naive about data structures and their evolution into objects....
Strings aren't lists, they're structures....I'm trying really hard to avoid saying "object-oriented," but objects will become more complex and more abstract.
If you really want to look into the far end of "structures", then I prefer relational over OO (even though the current vendors have corrupted relational IMO).
OO is too similar to the "navigational" databases (NDB) of the 1960's. Relational was found by most to be an improvement over NDB's. OO and OODB's are close cousins of NDB's in structure.
I realize that this issue is a big Holy War and that it may be a subjective preference that OO fans and relational fans will probably fight over forever, but researchers should focus just as much on "everything is relational" as they do on "everything is an object" for future-targeted experiments. There is a possibility that us relational fans are right.
Table-ized A.I.
The signal to noise ratio in this piece is high. There's lots of metaphors and similes to explain his otherwise very facile points.
He also seems to be contradicting himself. " Semantically, strings are more or less a subset of lists in which the elements are characters. So why do you need a separate data type? You don't, really. Strings only exist for efficiency. ", he says at one point, then a few paragraphs later says "What's gross is a language that makes programmers do needless work. Wasting programmer time is the true inefficiency, not wasting machine time.". The efficiency in implementing strings in programming languages is for the programmer, who doesn't have to use said "compiler advice" and carefully separate his strings from his other, non-string list instances and keep the two distinct in his programming model. Apparently it's "lame" to simplify text manipulation for programmers, but at the same time the efforts of programming language design should be towards making the programmer's life easier. Which is it? I know strings and string libraries have made my life a whole lot easier.
Nevertheless, I'm willing to accept the notion that eliminating strings and other complex, native datatypes and structures serves to make a programmer's use of time more efficient. But how does it do it? Graham doesn't say, he just waxes nostalgic about lisp and simpler times and languages.
I don't think the slashdot crowd needs it explained why data manipulation by computer needn't be simplified; it already is, as machine code is binary in the common paradigm. What ought to be simplified is data manipulation by humans, and on this point Graham nominally agrees (I think). This has been the thrust of the evolution of programming from machine code to assembler to high level language. Simplifying high level languages into more and more basic, statements -- getting closer to the "axioms" that Graham calls tokens and grammars -- simply reverses that evolution. It makes it easier and more elegant to compile programs, but it does absolutely zero to make the programmer's life more efficient, or easy. The whole reason high level languages were developed was precisely to get away from this enormously simple, yet completely tedious way of programming.
The overarching fallacy in this article is Graham's reliance on what is known about computation theory now to determine what programming languages would (and should) look like then. And while it's interesting to prognosticate on what the future would be like 100 years from now based on what we have today, it's not a reliable guide. Like Metropolis, A Trip to the Moon, and other sci-fi stories from the distant past, they're entertaining and no doubt prescient to the people of the time, but when we reach the date in question, the predictions are largely off the mark. It's somewhat laughable to think that despite our flying cars and soaring skyscrapers, we use steam engines to power our cities and make robots with eyes and mouths. Likewise, I don't think an honest, intelligent prediction or forecast of (high level) programming languages 100 years hence can occur without a firm basis, or even idea, of what assembly code would look like then. This, in turn, relies on a firm idea of what computer architecture will look like. Who knows if five (or fifty) years from now a coprocessor is designed that makes string functionality as easy to implement as arithmetic. Such an advance would completely invalidate Graham's point about strings and advanced datatypes, and in fact possibly stand modern lexical analysis on its head. Or if an entirely new model of computation comes to the fore. Even Graham himself admits that foresight is foreshortened: " Languages today assume infrastructure that didn't exist in 1960.", but he doesn't let that stop him from making pronouncements on the future of computing.
Graham seems to be spending too much time optimizing his lisp code and not enough on his writing. This piece of code could have been optimized had he used a simile-reductor and strict idea explanations. But it's definitely a thesis worth considering, if for no other reason than mild entertainment. C-
B
"I'm payin' taxes, but what am I buyin'?" -- James Brown
For a truly breathtaking vision of the future
read Vernor Vinge.
A Fire upon the Deep
A Deepness in the Sky
Marooned in Realtime
Test 1 2 3 4
Languages are tools that are used to organize sytactic rules that are then converted into machine usable representations of the same general purpose.
Languages as you understand them will be as dead as the steam powered loom in 50 years. We will have non letter/symbol typed tools to do that in as much as the DVD has 'replaced' live theater as the only way to 'reproduce' entertainment.
The objective is to create a syntax which is the simplest way to convey the semantics of the program.
Do you see mathematicians "evolving" into using natural language?
"Four plus four times two divided by three"
I highly doubt it. Natural language is not the best way to describe math, nor is it the best way to describe computer programs.
While I am positive we will have excellent natural language user interfaces for programs in the future, this is only because the end user doesn't want to learn a new, more expressive language, he wants to use what he knows (English).
This is the very nature of abstraction. Abstraction inherently causes loss of expressiveness.
I don't want to "speak" my program to my computer, I want to describe the algorithm in the most expressive and elgant way.
Scott
Hey... But how about those SUVs I saw in Silicon Valley, with shiny paint that obviously hasn't seen any rugged road?
#!perl7
use NativeLanguage::Translator;
print.Translate.NativeLanguage('Hello World');
__END__
The module would determine what language the string was in and print it in the language as set in an environment variable.
Stop thinking like Perl 5.. Perl 6 is going to be excellent, and according to Larry Wall, Perl 7 is going to be perfect.
Causing Chaos Everywhere,
Nik J.
The strange world of a loner, in a populous city, drowning in society
while true do send-more-mail.
It'll be a huge commercial success.
Go look up the SQL count(*) operator some time.
Results of selecting a result set: all matching rows must be found by the server, all their fields read off the table, packaged for transport by the server, transported across the lan (using bandwidth and time), unpacked by the client and presented in a dataset. Whereupon you look at their size and throw them away.
Results of issuing a "select count(*) from mytable where somecondition":
All all matching rows must be found by the server, counted not processed, and only one value, yes *an integer* instead of potentially thousands of rows, is sent across the network, unpacked by the client. If you don't understand why this is a win, then give up and go home now.
Perhaps you need the detail too, but you didn't show that in your e.g. Learn your languages, use the right tool for the job.
Even in a SQL client utility it's always faster to get a count than the details.
My Karma: ran over your Dogma
StrawberryFrog
Can anyone explain to me why some people say object orientation is overrated? The author of the article doesn't think "it has much to offer good programmers", for one. I would find it a pain to live without it and I think it makes things incredibly easier, especially if you throw things like generic programming into the picture. And I don't think I am brainwashed because I started programming quite before OO became widely used.
There are numerous hints, hits and misses about the wetware factor in the next 100 years. However, I even with my ego I can't believe that even the manner in which my brain approaches answering this question will be the manner in which a human brain will be applied to solve the question in 100 years. I am almost certain that the brain of my grandparents in the 1920s couldn't have fathomed fuel-injection in a car let alone drive by wire throttles. It is fun to posit what the future may bring but the decision making and predictive processes that I own now will be archaic in 100 years.
Computers will be Artificially Intelligent and we'll explain to them what we want in English or Chinese or whatever. They will just do it and not be able to explain to us how they did it, any more than we can explain how vision works by introspecting. They will reproduce by downloading versions of themselves, greatly simplified and hybridized with other AI's by some kind of sexual reproduction, into bare hardware.
Maybe that's a dumb idea but 100 years from now it won't seem any dumber than anything else that we could come up with. It's like asking Babbage what he thought computer languagues would be like in the future....
here in the future, computers program us. since we replaced teachers throughout the education system with more cost-efficient androids that are programmed to take advantage of their opportunity to teach us how to speak at a young age so that our language/behavior adhere to the android's original human integration spec.
according to my teacher this happend millions of years ago.. not long after the first android scientist created the first humans in a labratory.
well the temporal rift alert is blinking on this backtime(TM) console so I'd better log off
-gordy
I like the concept of telling or describing what you need accomplished and the computer helping you along or coding with you. I like AI + RAD = greatness.
What, you're a Perl hacker and you've never seen Lingua::Romana::Perligata ?
DNA just wants to be free...
that's so funny ... about half way down the page is a quote from Randy.Witlicki@hanover.valley.net.
.. lets put it this way ... there is a real reason he was working at a NON-PROFIT ISP ....
I used to work at valley.net for a time
...but why would we want a language that takes so long?
I think you mean GNU/VisualJavaC++.Net#
I am surpised no one said anything about meta-programming. I think that the true next generation of languages will inherit heavily from ML/Haskell, having the types to be determined by their usage.
For example, in ML I can have a function add x y : x + y which can be called for ints, floats or strings.
I don't know if you have realized it, but a lot of programming time is taken up for pinpointing to the system the storage class of a variable: (is it an int ? a bit ? a float ? a whatever ? I just want a number, God damn it!!!) This is too tiresome, especially in C, C++, Java and ADA, which the types must be explicitely declared beforehand (maybe there are other strongly typed languages, I am sorry I do not know them). There is a practical limitation that enforces type declaration, but I think compilers can be made clever enough to deduct the types from their usage.
Another thing is that the programmer tends to think about many things at the same time: a) memory allocation, b) control flow, c) side effects. A truly next-generation language should enforce separation of algorithm and the implementation details.
I imagine that we would all write templated code and then apply it to some data. This can work with a top-to-bottom approach which tends to fit better with the human perception. For example, it is easier to start with a simple loop saying
1) open database
2) fetch recordset
3) find data
4) close recordset
5) open form
6) present data
7) edit data
8) save data
than to write a big program full of technical details going hundrends of lines of code about how to open the database, how to form the SQL query, how to create the recordset, how to open the window, etc. The specializing of the code can come later, when the logical model has been processed and proven correct.
Finally, the next big step in programming, in my opinion, is program verification. It takes a really powerful system to check a piece of code if it does not have any bugs, especially if the program is multithreaded, but with quantum computers code verification may become a trivial job.
A lot of concepts in Java may have existed before. Perhaps there were other VM-based languages with garbage collection, reflection API, comprehensive cross platform UI, language-based security model, RMI and so on. But none of them really took off. Not to the point that big companies started using them for important applications.
I think it's natural that new concepts first appear in research languages that are barely usable and production languages mostly just package existing ideas nicely. It doesn't mean that such a language is an evolutionary dead end. C is not that much different from Fortran or Pascal, just more pleasant to use. But it inspired C++ and Objective C, which in turn inspired Java and Java itself inspired JavaScript. There is no reason why a future language can not be based on Java.
Basically, Java has a lot to offer to evoluton, just not to revolution (== discarding many old concepts and replacing them with things never tried before).
there is a variant of Befunge that does exactly that, albeit with ASCII instead of ... whichever encoding you were thinking of
using for Chinese. ;-) It was called trefunge or something of that nature. (google, google...)
Ah yes, here's glFunge98 which supports Funge93,Funge98,ConcurrentFunge (multiple instruction pointers in the same space), and of course Trefunge, and somehow OpenGL gets bashed in there too. :-)
Warning: Befunge is just about the sickest thing you can think of to program in. I'm not kidding. Your brain will hurt. In no way is this post meant as an endorsement of Befunge programming as a serious undertaking or as a hobby. Drugs are bad, m'kay?
News for Geeks in Austin, TX
Assembly language will always exist.
The LM, the BXLE (BXH), put locate I/O combo rocks! I nearly smoked tape drives with that program (IBM 370) that I rewrote from spaghetti PL/1 code to assembler for work.
Actually, I like the PDP-11 architecture, which I have also done assembler programming in. Dropping names that I've done assembler programming in, PDP-8, 8080, 8085, 68000, 68010, 68020, IBM 360/370, IBM 7040 (console programming for grins). Haven't done any 80x86 programming, but I can debug through the assembler compiled code of C++ language.
Wanna see my VAX? [Proud owner of a VAXStation II/GPX]
The objective is to create a syntax which is the simplest way to convey the semantics of the program.
Right. I agree. But how do you define simple? Simple for the machine? Should we all assembly language?
"Four plus four times two divided by three"
Isn't this natural language? Anyone with a reasonable understanding of how our language works (and a basic understanding of math) knows what you're saying. But I can also see where you're going. I can describe a differntial equation with natural language, but that doesn't "solve" the problem for me, it only describes it. Languages like Perl and Python aren't "natural" languages, and I don't think their goal is to be a completely "natural" language, but they move their syntax closer to natural language. And shouldn't that be the goal of any compiled language?
I don't want to "speak" my program to my computer, I want to describe the algorithm in the most expressive and elgant way.
I like that. But here's a question...is it the inability to capture that algorithm with natural language, or is it the inability of the programming language to communicate the algorithm more naturally?
Whereof we cannot speak, thereof we must be silent. --Ludwig Wittgenstein
Forget that lisptarded language.
What a butchery.
When someone did, unexpectedly, take this paper and translate it into a working Lisp interpreter, numbers certainly weren't represented as lists; they were represented in binary, as in every other language.
Rexx does not store numbers in binary, it stores them as decimal numbers, just the way that humans deal with numbers. This is why Rexx is one of the few languages that can actually do simple maths accurately. Have a look at General Decimal Arithmetic.
The author's next paragraph goes on to say: Could a programming language go so far as to get rid of numbers as a fundamental data type?
Like Rexx has had for 24 years??? It only has one datatype; a string.
Or earlier in the articale; also related to doing arithmetic without a number datatype... Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient.
Again he's describing Rexx, except that it is far from being unbearably inefficient.
For those who are interested in a 100-year language that has several of the features in this article, and has already made it a quarter of the way to 100 years, look at The Rexx language Association.
I'd suggest that at least the author go and have a look.
or maybe in 100 years computers will be such a part of our life that we wont be dreaming up buzzwords to describe the use of them.
Instead we will all be dreaming of the "computerless office of the future"
Firstly, came SGML. From SGML, came HTML. Seperately from SGML, came XML. Both HTML and XML are subsets of SGML. HTML and XML are *not* subsets of the other. XHTML is a dirivative og HTML made complient with XML. I shall draw a graph:
XML
/ \
SGML XHTML
\
HTML
Impeach Bush
Why not C++ or C# ? Well just compare the K&R book "The C Programming Language" with the Bjarne Stroustrup book "The C++ Programming Language". As the K&R autors write "We have tried to retain the brevity of the first edition. C is not a big language, and it is not served by a big book." The C++ language and the Stroustrup book are exactly the opposite.
So C is tiny, powerfull, completely defined inside a rather modest book, compared to all other languages, aspecially the object oriented flavours. So my prediction is C will never go away. The principle of object oriented programming also won't go away, but its form or dialect will evolve.
Robert
IOW, shut your sig-hole. Thank you.
Payroll, Paychecks!
a few short years ago computers were invented and we couldn't think of an immediate use for them before they became cheap enough to do the books for large businesses.
A few years later the spreadsheet was invented and you didn't need a team of programmers to allow you to do accounting with a computer.
About the same time word processors made us think of computers as something we could all make use of.
email and chat rooms made us think of computers socially.
In 100 years how will we be thinking of computers?
Will we be asking them: "I can't think straight", "my stomache hurts", "Earl Tea, Sweet& Hot", "what was it I said to that ?##*?! boss of mine last week", "I want my garden landscaped again, with a family of garden gnomes of the dancing variety", "get the frig outa my head, friggin friggin spam, frig!"
And asks you questions, like your own personal analyst, and can describe things in pictures, and understands gestures.
And the 'program' will change just a little every day, or when you think of something new or better meeting your wishes as much as it can making sure of course not to screw things up for others.
And will help by suggesting things others have found useful (but not in a paperclip way). So computers end up as some sort of glue knitting us all together in a fruitful way, whilst allowing us to be individual, and to excel.
I agree the less time we spend wasted talking about computer languages the better.
I would suspect that in 100 years, we will mostly be interested in writing programs the spit out particular strings of proteins. It is a fairly complex language that is based on 4 basic characters, bundled together into codons of three characters each. The best part is that this language has already been tested for about 4 billion years and has large libraries available from which to draw template code.
It will all be done off-shore by Indians.
In a hundred years? :)
The Free Software Foundation will rule the world, of course!
The will be no binaries left, just source, so there will be only scripting languages
"Arguing against the transhuman argument is pretty pointless because it's probably going to happen sooner or later."
Don't you think you're missing something? Like an argument? Let me simplify: let's call the eventual occurrance of transhumans, "the statement." Then what you said, making the substition (and other easier to see word changes)
"Claiming that the statement is false is pointless because the statement is true."
Think about this before you think of how advanced our minds will be: the first science was philosophy. The first scientists/mathematicians of the renessaince where philosophers as well (Decarte and Pascal come to mind). We have been working on that problem of advancing the mind of the human race for at least 4000 years, and doing so through every means at our disposal.
We've had an inkling that a computer could exist for about 100, and couldn't really make anything viable until about 40 years ago. And even then, we couldn't do anything on a broad scale until the invention of the transistor.
We soar in one field while we haven't even begun to crawl in the other. I'll let you figure out which is which. Transhumans in 100 years? Maybe 100 millenia.
Mod me down and I will become more powerful than you can possibly imagine!
IMHO, FORTH is just as good a syntax representation or better than LISP, and there is no fundamental reason why compilers would not use this as their intermediate object code.
Thus, take the C expr:
a = 3 * 4 + c;
The compiler then might generate the FORTH-like:
3 4 * c + a =
While you could say the difference is just Reverse Polish Notation vs. Polish Notation, in effect the LISP intermediate assumes an efficient processing of Lists, and the FORTH intermediate assumes an efficient processing of Stacks.
Since most general purpose computers are Stack based, I think the latter would be more sensible. But of course, where GCC and its descendents are concerned, LISP is it, because of who wrote it.
Peace and love, y'all
REBOL is a nice language; when I was casting about for a higher-level language to learn after C++, I considered it.
Unfortunately, it's not going to go very far without either a publically-available and implementable language description (as C and BASIC did), or else a controlled specification and a freely-available, fully-functional environment (as Java, Perl, and Python have).
As it ended up, I chose Python.
BCPL. You know you want it back.
One poster claimed quantum computing will make current languaes useless. This is false. Any reasonably flexible language has space for new data types and operators. You would have to be careful not to prematurely branch based on a quantum value, as this may force you to opserve its value, destroying the superposition. However, I don't doubt Fortran will be one of the first languages used in quantum computing once they get past the assebly language stage.
What will languages be like in 25 years (and maybe 50 years)?
Well, there will be a Fortran and a Lisp and a C (maybe a C++). Lisp has always had automatic garbage collection. The Fortran and the C will have optional garbage colletors. Fortran, Lisp, and C are all decent attempts at languages that are pretty easy to grasp and have huge legacy backings.
Hopefully all of the main languages will be less machine depenent. Fixnums, ints, longs, floats, and doubles will be the same size across platforms, wasting a few cycles if this doesn't fit the underlying hardware.
In terms of new novel languages, I see languages simultaneously going three ways. I forsee languages that resemble formal proofs and/or formal specifications for use where reliability is critical. I forsee languages specialized for Scientific/Engineering disciplines. (Maybe Fortran, Excell, and Matlab cover all of the bases well enough, but I hope there is enough room left for improvement to drive innovation and adoption. Having a CS background, I didn't appreciate LabView's "G" language until I had an opportunity to see the ugly ugly code scientists and engineers tend to write in Fortran.) (I can also imagine efforts to use sytaxts that better express parallelism and other features for optimimizers/compilers so we finally have a widely used scientific/engineering language that is faster than Fortran 77. I can also see more languages like the Bell Labs Aleph, designed for parallel/cluster environments.) The third direction I see languages going is scripting/prototyping-like languages that will look more like natural language. (It's too bad there isn't a cross-platform open-soource AppleScript-like language yet.)
What do I think languages should have? Languages should have garbage collection and bounds checking enabled by default (of course, optionally turned off if you really must have the performance).
Langages should have very clean and consitent APIs. Having few orthagonal types helps make a language clean Languages should merge character arrays and strings (arguably the Algol languages have had this for a while). If a language wants to be able to have immutable strings, it should provide a way to declair an immutable variant of each fundamental type. (This is actually very useful in writing less buggy code.) Languages should strictly define the size of fundametal numeric types. (I really like Python, but it seems a huge mistake that an integer is "at least 32-bits". Allowig variations in size of fundametal numeric types adds cross-platform bugs. If I wrote a language, the types would look like "int32" "int64" "float32", "float64", "complex32" and "complex64". We got rid of 9- and 12-bit bytes. We should further get rid of these headaches.) Having worked with lots of engineers and scientists, I would love to see complex numbers as basic numeric types that all of the normal operators work on. Wrapping two doubles in an object adds a function call overhead for each numeric operation. Performance with complex numers (and numbers in general) is one big reason a lot of the code I see is written in F
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Obviously, Moore's Law will not hold for another 100 years. So, Paul's whole argument about wasting resources in order to make writing software easier might be an academic argument about programming languages 20, or maybe even 50, years from now. I certainly think that over the next 20 years, we will be getting used to the idea of wasting computing resources, and using the wasted resources very effectively. But then Moore's Law becomes invalid. Then what? Then, assuming that our craving for ever greater computing power continues, we start to go back the other direction. We start to try to get more done with fewer CPU cycles. So it would seem that the programming languages we use 100 years from now may not be as wasteful as Paul suggests.
I agree, it's not an open language, but the environment is largely free for non-commercial purposes. This is the second time someone has known of REBOL and told me to look at Python, so I think it may be time that I do. Still, you can't deny the ease at which one can write a useful internet application. The comment of the Anonymous poster suggests there's still a resistance to languages that are not strictly iterative. I think a program really should be reducible to a FSM with structure/object definitions and interfaces. Here's to coding in Visio!
... I think about how every problem looks like a nail when all you've got is a hammer.
Paul really has a list fixation.
it will come from research labs ...
:
n g. html
...
Interesting readings
The join-calculus (how to express parallelism/distributed computation in a language)
http://pauillac.inria.fr/join/
Reactive programming
http://www-sop.inria.fr/meije/esterel/esterel-e
and of course logic programming with Prolog
This post is displayed with recycled electrons
"Vans just don't cut it when driving on difficult roads like an SUV can (ie. rutted dirt roads)"
Not true anymore! If you ever do really want a van (just for a change of pace?) look at the Chevy Express 4x4 van. The 3500 (very heavy duty) model is $28.900 plus options, so it's cheaper than most SUV's. I think it has more interior room than even a Suburban, although admittedly most of the extra room is vertical. A natural gas or propane conversion from the factory is only $125! I bought one a year ago, and have almost 30,000 miles on it without a single problem. About 2/3 of the miles are off-road. After adding a small lift, a couple skid pads, and more aggressive tires (same things I add to all my vehicles), it will go anywhere my old Tahoe would and more. I got the optional locking rear differential, so it is much better than any other full-size 4x4 I've driven. You have to lose traction with one of the front wheels and *both* back wheels to get stuck. It's definitely worth a look if you need something bigger or are tired of SUV's. I've had an SUV continuously since I bought an International in 1969, then a Wagoneer, then a small 1984 Blazer, etc.. I service "off the grid" homes, so I often end-up in some places that are nearly impossible for some 4x4's to navigate but this van does just fine. Having a van is a nice change It's also nice to be able to put all the seats in so I can haul 15 people if I need to. You can't do that with your SUV!
For example, he writes:
But that's just not true. McCarthy not only intended LISP to be implemented, the CACM April 1960 paper's introduction begins:
(emphasis mine)If he can't even get that right, how can you possibly credit a claim like:
Anyone who's done more than a little programming knows that strings need to be "first class" objects. The lack of genuine strings is one of the worst problems in the C language, and the source of most of the published vulnerabilities at CERT.Gimme a break!
Computers totaly conected to the human brain. Makes me wonder what a blue screen of death will look like.
Please check your facts. Development on Lisp started long before the 1960 paper.
PS -You do know that Lisp (unlike C) includes higher order procedures that make data representation irrelevant, or are you just speaking out of ignorance?
In the great CONS chain of life, you can either be the CAR or be in the CDR.
except that all of the code involving dates had to be modified anyway.
But you raise a good point. A packed date might fit within 1 byte. The years from 1900 to 1999 fit within 7 bits, and the leftmost indicating either 1900 or 2000.
Although, leaving it as 8 bits would allow it to be 1800 to 2055. Maybe that's how it was done.
Dude, I was programming computers when I was six. This was the first program I really remember being proud of (circa age six):
10 PRINT "CRASH"
20 GOTO 10
And people question why there should be an Apple in the back of a first grade classroom.
:Wq
Not an editor command: Wq
all data has meta-data describing it's type.
e.g.
Functions operate on data types e.g.
function jpegtobitmap(input , output )
function openuristream(input , output )
This allows objects to be built out of functions that operate on the type of data provided.
If jpegtobitmap was installed then any application that could work with bitmap data can now also work with jpeg data.
thank God the internet isn't a human right.
Funny, but in case anyone was taking you seriously...
Formal English grammar exists, whether or not Americans learn it in school. Informal grammars exist for most human languages and are spoken in most common social situations.
One-sentence expletives and exclamations are common in most languages, but Greek and some other languages can combine nuances of subject, verb and direct object into one multisyllabic word.
In some language families, there are no spaces dividing what European languages would consider to be words, so that every sentence or paragraph, no matter how long and intricate, is a single word. J.R.R. Tolkien, a philologist, poked a little fun at such languages through Treebeard and the Ents.
Historically, it is true that royalty and courtiers often used different languages to mask their words from commoners, adhering to strict grammar rules to give weight to their words. However, it was just as common for continental European courts to choose formal English to obscure their language from commoners.
Now, we consider such grammar to be "putting on airs," so Americans no longer learn formal grammar in grammar school. However, we still exhibit a very high degree of verbal snobbery through the various jargons of lawyers, doctors, scientists, engineers, religious clergy, slashdotters, etc. If you want respect, you still have to know the TLAs and other magic words.
And I don't mean "abracadabra" or "open sesame," but "please" and "thank you" still apply.
"...a language in which indentation is significant, like Python, would not work very well on printer terminals..."
But for those of us that go all the way back to
to punch-cards, Python would have been great!
that the building blocks used to build up the language must be as simple as possible.
Machine language is made up of bits.
You can't get much simpler than that.
Multiplication is just a special case [of addition]
And addition can be done by repitively adding one.
Turing Machines are capable of computing any computable problem, but nobody acutally uses them. Way too slow!
Paul Graham (the author of said article) is a True Believer in Lisp, and subscribe to a theory that the more you improve any other language, the more those improvements come close to culminating in an awkward version of Lisp, so it may be more efficient to go with Lisp in the first place.
So what would his reaction be if he knew that you said the hundred-year language is "probably C" ?