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."
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
that's VisualJavaC++.Net#
that's VisualJavaC++.Net#
That's what I was going to post, but I didn't want to give Microsoft any ideas!
PepperHacks - Hacking the Pepper Pad
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...
Java will turn out to be an evolutionary dead-end, like Cobol.
dead-end? Java has already spawned javascript and C#.
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;
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
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!
I def. think that a new languange based on quantum computing will be at the forefront.
If after generations and generations of computers, we are still teaching people to talk in computer terms and not yet teaching computers how to talk in people terms, we'll have gone the wrong direction.
It doesn't matter if quantum technology is used or not, for the same reason as it doesn't matter whether a brain is a parallel or single threaded machine, whether it's made of carbon-based or silicon-based technology, etc. What matters is that it can talk to you, can understand you, and can improve life.
If you want to know what computer languages should and hopefully will look like in the future, you have only to watch Star Trek. I'm not kidding. The desire to pack computer use into a short TV program has led the authors of that show and shows like it to pare out all but the absolute essentials of describing what you want the computer to do. That is what computer programming should be like, since that's what people programming is like. People don't put up with excess verbiage, and neither should computers.
Kent M Pitman
Philosopher, Technologist, Writer
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.
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.
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
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
"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.
I don't think it's the first order functional nature of Lisp that has allowed it to survive, but rather the "late binding" nature of it.
Static, strongly-typed languages, make the assumption that everything that needs to be known about the world is knowable at compile time. Such programs need to be recompiled (at least) and rewritten (often) because the world changes and either the source program itself or its compiled form needs to accomodate that change.
Lisp, because it delays many decisions until runtime, and because its runtime tagging accomodates datatypes that are not among the set that was declared at compile time, naturally accomodates changes in the environment around it, and naturally survives well during transitions between old and new ways to do things.
Static languages often breed static ways of thinking, and often need new static specifications at regular intervals to accomodate the mismatch with how the world really is. Dynamic languages breed dynamic thinking, which (I claim) is more robust over time.
Kent M Pitman
Philosopher, Technologist, Writer
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
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.
Upper level languages will change. But what about Assembly? What about programming for embedded systems?
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!
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!
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
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."
In the world 100 years from now, you don't program the computer ... the computer programs YOU!
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
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.
SuperPlusGoodVisualJavaC++.Net# v6.0 Premium XP Gold PRO Enterprise Edition
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.
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
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
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.
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.
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.
Basically the problem isnt going to be with the languages - the problem will be with the concepts that created those language features.
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.
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.
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
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.
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 !
Well, for starters I'd look here (make sure to look at the links in the navigation bar on the left) and here.
...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.
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
Believe it or not, but there is a reason why Lisp users are more often also Lisp lovers than Java users are Java lovers: Lisp has very few primitives, and very many high-level tools built upon it. While you have a productive toolset from the beginning, you are always able ot change everything if it doesn't happen to fit your problem exactly, using the more basic tools.
For example, Lisp object systems are implemented in Lisp itself. Take that together with Lisps ability to redefine programs at runtime, you get something way more powerful that Java's object system. If you don't like an object system, change it until you do, or write your own. Everything in the language not only makes this approach of programming by language-tweaking possible, but encourages it - don't like the default way multiple inheritance is done in CLOS, the standard Lisp object system? Use the meta-object protocol to implement a metaclass that implements your weirdo inheritance rules.
Conventional languages like Java don't allow you to do this, instead they force you to think the way it's invetors wanted you to (which is not neccessarily the way they like to think themselves, as in the case of COBOL or Java). Lisp is not a single language - it is a toolkit to easily build a language that is perfect for your task.
Programming can be fun again. Film at 11.
I'm a professional java programmer. I also do objective C (before Cocoa), Smalltalk, python, C, scheme, Haskell and a few other languages reguarly. I've managed large perl based projects, written high-performance data processors in Ocaml, written a billing system in C++, a monitoring system mostly in tcl, games in assembler, data processing systems in eiffel, and hell, I even did a CueCat decoder in javascript a while back.
While I've still got quite a bit to learn, I can say you're missing the point if you don't understand what he's saying about java being a dead end on the evolution of languages.
What does java have to offer to evolution? I can't think of much that java as a language has brought us that's new.
Being VM based? It's more acceptable now, but it's not new. OO? It barely does that well at all. Hmm... Libraries. JDBC is ODBC with a touch of sanity. The collections look very much like the collections of Smalltalk finally (which also appear in objective C).
Overall, without doing something revolutionary, I don't see how it can contribute that much to evolution.
Revolutionary languages are languages like lisp (which is a sad story in that it's still capable of doing everything any other language can do, often with less effort), smalltalk (actual OO is a lot more simple than partial OO), Haskell (smaller change, but you can be terse without being cryptic...almost a common language for design and specification), etc...
Many languages have made some contributions to programming in general and will change the way people think about development. Python may not hold the influence of lisp or smalltalk, but it does do some things that future language designers will consider (for example, yield for generators vs. call/cc is an excellent improvement in helping expressing what you mean).
-- The world is watching America, and America is watching TV.
The problem is that English is *not* very precise... When lawyers attempt to make English be more precise, look at the messes they make ... I don't know about you, but I don't want that.
But it's what we've got. Human language is, alas, imprecise. But we have more than 50 years of experience with that and we know nothing better is on the horizon. I think you'll be lucky if between now and a hundred years from now, you can teach 10% of the world's population the meaning of the world algorithm, much less the use of an algorithm.
But take heart -- while the computer has been called a relentless judge of incompleteness, the fact is that some of that incompleteness is just due to their bad schooling. Lack of common sense. Lack of context. If we can add that stuff in, maybe the kinds of problems computers give us won't sound like the whinings of a small child, ill-informed about the things in the world that we collectively agree should be 'obvious'. That won't fix everything, but it will fix some things.
For example, most non-computer people are able to take showers in finite time even with "Lather, Rinse, Repeat" written on shampoo bottles. They don't loop infinitely. Maybe in a hundred years, computers won't either because someone will have filled them in on the joke.
And legalese is not inherently required to be expressed as badly as it commonly is, that's just a fashion. Like doctors having bad handwriting. Social pressure would fix that if people were willing to tell their lawyers to go back and rewrite a text in prettier form. (Some probably are too cheap to pay by the hour to have that happen. Then again, if they did, they could perhaps read the result. The lawyer is probably just as happy you can't, just like a high paid computer consultant is often just as happy his clients can't understand the script he's written them, so they'll have to call him for upgrades. Again, not a technical problem, but a social one.)
Kent M Pitman
Philosopher, Technologist, Writer
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
We do already have some primitive forms of this conversation idea via versioning systems like CVS. The problem is writing a program that recognizes patterns in the changes and learns to do that stuff on its own.
Also, think about languages like Ruby or Lisp where the interpreter can alter a program while it's running. As an example I wrote a small text editor in Ruby/Tk in which you could modify the source code to the editor in a buffer, then choose "eval buffer in application", and that code would run in the context of the application. Once you have the core of such a program, with proper error handling, you need never turn the program off again (as long as you don't redefine the core engine with a bug). I was able to add menus, menu items, rewrite existing routines, etc, all while executing the original code. Of course, emacs has been doing this same thing for years...
Using both CVS and live eval you get much closer to code being a conversation between the programmer and the system.
I do not have a signature
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
The popularity of a language has little to do with its contributions to the evolution of future languages. Sure, popularity means that more people get to see it and what-not, but many people who write languages tend to know more than the one they just wrote.
To call languages like lisp, smalltalk, objc, etc... ``barely usable'' is to make it clear you've barely used them.
While you may not believe that C is much different from fortran or pascal, it's not derived from either. C's father is a language called B. Algol 60 and 68 also influenced the development of C. I can't speak too much on the history of C++, but it's misleading at best to say that C inspired Objective C. Smalltalk inspired Objective C. C was the default system programming language for quite a while (i.e. people were having to use it anyway), and Brad Cox wanted to add the features of smalltalk to it to make application development easier. Not to say that C didn't play a major part in this development, that'd be stupid, C is clearly the father. Objective C, however, is the mother who stayed at home and took care of it while the father was out working on bigger and more bloated things.
Javascript is in *no way* related to java. Javascript existed before java and shares only a few items of syntax.
So, you never said what Java brought other than popularity. If you design a language that has the collections API of java, you've just modeled a language after smalltalk. If it's got RMI, then I hope you at least get it close to as good as objective C did (which was doing it before java). If you plan on using java as a reference for a reflection API, then please, use it as a bad one, because it was done much better in...I don't know, just to pick something, let's say python. Cross platform UI? I was writing cross-platform perl apps using Tk before I did any UI work in Java (and it was easier, though I find it still yet easier in tcl, which is the only language in which I've actually deployed cross-platform UI)...etc...
-- The world is watching America, and America is watching TV.
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.
I hold the best computer languages for actually programming the computer will still be analytic, logical languages.
I guess this is the fundamental point on which we just have to agree to disagree. I think that analysis and logic are critical operations, but I hope to find that the computer languages of the future will cease to be pedantic about the specific mode of expression, perhaps building in a sense of redundancy of expression so that no matter what language you express the idea in, it ends up with effectively the same internal representation.
One of the biggest differences right now about how computers do things and how people do things is that computers do not "degrade gracefully" when you go outside the ordinary way they expect to receive things. They tend to "fail catastrophically" on the least little deviation from the expected. In a hundred years, I hope they learn to be more laid back about what doesn't really matter (the manner of expression) and to focus more on what really does matter (the goal of the expression).
It might be that they will fail at the goal for the first few revs. But if we don't at least deploy them with the intent of trying, we won't get there.
Sometimes the path toward the future is a crooked one. For a further illustration of this phenomenon, search for (and read) 'A Personal Footnote' at the end of my 2001 paper on error handling in Lisp.
Kent M Pitman
Philosopher, Technologist, Writer
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.
In the great CONS chain of life, you can either be the CAR or be in the CDR.