|
The Future of Programming Languages
How do you think programming languages will evolve? Will the continue to be character based? Rich text based? Will they demand a more robust alphabet with specialized symbols? Will the be iconographic? Will object oriented languages me the norm? If not, how will OO evolve? Will OO evolve, or simply be replaced? With what? Will there ever be compilers that allow the developer to input natural language and output assembly? Will IDEs of the future contain expert systems? (By that I mean, will the IDE simply have the developer say, "Sort that list", and then the IDE determines the most efficient sorting algorithm to implement.) What's the time frame? Will we ever be rid of FORTRAN, C & COBOL?!?
dave
Monday, March 8, 2004
What a strange fellow you are. You ask for both the embrace and the rejection of Cobol.
K
Monday, March 8, 2004
"Future events such as these will affect you in the future"
TJ Haeser
Monday, March 8, 2004
>> "What a strange fellow you are. You ask for both the embrace and the rejection of Cobol."
This is a interesting post... I've never written a line of COBOL in my life, so I am thoroughly and completely ambivalent to its existence. I am asking where you think computer languages are heading in the FUTURE. Use your imagination. Voice IDE interfaces? 3D GUI IDEs like in 'Minority Report'? Amazing new Iconographic grammars? Built in expert systems to optimize & automate algorithm selection?
dave
Monday, March 8, 2004
ETL tools.
http://www.ascential.com
This is just a part of the 'future' you speak of. DataStage, and other ETL tools use graphical representatives to illustrate how things progress.
It would be AWESOME if C++/C#/Java can be visually representated graphically. Build a class, create (or use) an icon for it. Link away!
(Yes, I work for them.)
T.J.
Monday, March 8, 2004
Is that similar to DTS 'programming'? 'cause I hate that. You can fit a lot more text on the screen than you can icons.
And the prctures don't tell half the story anyway, you always have to click on them to get the the real work, which is typically some kind of text.
I think some people must like it, but I don't.
Scott
Monday, March 8, 2004
You may want to take a look at _Interactive Programming Environments_ by Barstow et al. Crusty old '80s book containing essays about the cool old systems like The Programmer's Apprentice, object based noun/verb window systems, ambitious stuff. Some casually explained how files sucked. Somehow few of these things survived; companies went bust after a boom, Xerox didn't care, etc. VCs in those days enjoyed stuff like firing the Steve Jobses of their companies; I'm sure they've learned by now...
Tayssir John Gabbour
Monday, March 8, 2004
Graphical tools are good for simple configuration but as soon as you step over the line into programming they become too cumbersome. Some purport to offer end users the ability to prgram without needing programming experience, the trouble is if you don't understand the concept of a loop or conditional processing then it doesn't matter if its text or icons on a page you aren't going to be able to cope with it.
My suspicion is that we are going to see more specialist languages and frameworks for certain types of applications. If you are doing any Windows GUI development then you will have to start looking at XAML as soon as Longhorn gets close to release.
Tony Edgecombe
http://www.frogmorecs.com
Software for printing
Tony Edgecombe
Monday, March 8, 2004
Declarative Programming is the future.
Don't say how, say what.
There are already far more declarative programmers than any other kind, just look at how many end-users are able to create spreadsheets - declarative programming by any other name.
Functional Languages like Haskell, OCaML, etc., and "Logic" languages like Oz and Prolog are all declarative.
Painfully explaining to the compiler how to program a loop is just that - painful. Much of what we do in day-to-day "imperative" programming can be abstracted away.
And that's only a start. Rethink mutability of data and use "dataflow" variables and suddenly parallel programming is easy rather than a nightmare of race conditions.
The future programming languages are already here, it's just that most programmers haven't realised yet.
David B. Wildgoose
Monday, March 8, 2004
So David,
so can you create an app like joels in Haskell yet?
the artist formerly known as prince
Monday, March 8, 2004
The thing I'm noticing is that the advantages in readability of being able to use things other than ASCII to program is strongly outweighed by the disadvantages (the symbols aren't on the keyboard anyway, and if you aren't using plain ASCII, it's much harder to send around/grep/use any random text editor/etc. You can semi goof around with this (with results that haven't been particularly satisfying yet) by making the language ASCII-reducable but having a graphical editor.
It also seems like the future for true power-programming is meta-languages, where they can take upon some of the aspects of a specially designed language. ML does this, as do most variants of Lisp, but you also have to consider fully standards compliant C++, with operator overloading, templates, etc. to be a language like that. It's interesting to see C# changing to offer many of the same sort of features that C++ has had all along. And it's doubly interesting to see the C++ gurus, most notably the Boost folks, writing good implementations of all of the big parts of Lisp that aren't in C++ already (because, as we all know, every large-scale programming project not in lisp contains an ad-hoc implementation of at least half of the Common Lisp standard)
Specialist languages are good, but it seems like most working programmers don't want to create a full language set that comes with the tools you need to get your job done. To me, it seems like the meta-languages offer the same amount of power, without all of the extra baggage you would need to create the whole system. Especially when you are trying to work against CLR, COM, or huge C/C++ libraries, it's really not feasable to build a new system yourself.
Flamebait Sr.
Monday, March 8, 2004
The idea that declarative languages will completely take over is mistaken. Domain-specific declarative languages (or libraries for general declarative languages like Prolog) are useful, but they require a huge amount of imperative code to make them work. The difference between "y is that number which equals x when squared" and the code for sqrt(x) is significant. The difference between a context-free grammar and the code that parses the language of that grammar is even more significant.
As declarative language methods become more popular, imperative programming will become ever more important.
K
Monday, March 8, 2004
"The idea that declarative languages will completely take over is mistaken."
Sorry, where did I say this? This is just a straw man argument. The compilers for declarative languages obviously have to be written in imperative languages, because that is the machine architecture the end product will be running on. Excel is written in C++, but declarative Excel macros are not.
As for the comment about Joel's software being written in Haskell, well, why not? Are you trying to claim that Haskell isn't Turing complete? Take a look at the ICFP Contest tasks which include things like creating Ray-Tracers, a job normally given to C++ and its ilk.
David B. Wildgoose
Monday, March 8, 2004
>> "the symbols aren't on the keyboard anyway, and if you aren't using plain ASCII, it's much harder to send around/grep/use any random text editor/etc."
Hmmm... Interesting points. My thinking, though, is that in the medium term future, we'll not be bound to use a keyboard - and freeing the developer from the keyboard pretty much frees us from ASCII. It takes an awful lot of characters to create simple loops that mathematicians scribble with a few sigmas, subscripts and other useful scripting conventions.
You also mention regular languages. If we were to extend ASCII to include useful mathematical notations, we'd be able to specify our patterns in a much more coherent fashion. In textbooks, for instance, you'll never see pattern expressions with twenty escape characters. No escape characters necessary - just use boldface to specify literals.
dave
Monday, March 8, 2004
Very interesting article in this week's New Scientist concerning advances in genetic programming. It envisions a software development model that merges concepts of developmental embryology (i.e. growth at the individual level) with Darwinian evolution (i.e. fitness for purpose at the generational level). The suggestion is that we may eventually - meaning not sometime soon - treat the development of software more like selective breeding of plants (or genetic engineering?) and 'grow' software rather than write it.
Gaius
Monday, March 8, 2004
If I had to hazard a guess, I'd say that:
* there will be more xml-based, declarative, special-purpose languages -- like XAML, say.
* _solutions_ will include code written in many languages, and in particular, traditional OO imperative languages will be used to customize the output of the declarative languages
* graphical _languages_ will continue to be of only marginal interest, but graphical _tools_ will flourish. Design tools will produce as their output programs in declarative languages.
I wrote a blog entry on this subject last week: http://blogs.msdn.com/ericlippert
Eric
Eric Lippert
Monday, March 8, 2004
Five years from now you will simply choose a metaphor and build the program within that VR space. For example, if you like the idea of building a starship, you'll use that metaphor, don your goggles and mits, and the VR app will add the code behind your starship construction steps.
Hey, don't laugh, just read Gibson and Stephenson :-)
Joe Hendricks
Monday, March 8, 2004
this article
http://www.paulgraham.com/hundred.html
by paul graham describes the future of programming.
Essentially, he suggests that as processing power/memory/other resources increases exponentially, solutions will be judged by how fast they can be created in addition to how efficient they are.
In other words, what's a little program overhead (since end users with their zillionhertz processors won't notice anyway) when it saves hundred of manhours through abstraction.
eaw
Monday, March 8, 2004
David,
My argument is that the saturation of 'declarative' languages will not overtake 'imperative' languages. I don't think that you've made your case for 'declarative' languages being 'the future of programming languages'.
By their nature they have a much more narrow focus than regular general purpose languages.
K
Monday, March 8, 2004
Pardon the stupid question... What are ETL tools?
888
anon
Monday, March 8, 2004
I've said it before (specifically, in [ http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=35501 ]) and I'll say it again - the future is, and always has been, Lisp. Other languages are slowly going in that direction, but I don't think they'll converge - every language will stop beforehand.
"graphical" programming or "genetic breeding" will remain niche solutions, in my opinion -- the ideas may sound fantastic, but they lack precision and terseness that is needed, and available with textual descriptions.
Movie scripts are always written as text; Then comes the storyboard - and the movie is made last. "graphical" programming tries to do the storyboard _first_, (or somehow do away with the script altogether). Somehow, I don't think it's ever going to be the way to make movies.
Get a glimpse of the future now - learn Lisp (really learn it - Graham's "On Lisp" is an excellent book after you know the basics), and then learn APL (or K or J). Even if you don't use them, you'll be tremendously more effective at whatever environment you do use if you grok the (mostly orthogonal) ideas of these environments.
Ori Berger
Monday, March 8, 2004
And if you like declarative UI wothout Windows, try xul.
www.xulplanet.com
fool for python
Monday, March 8, 2004
Object-Oriented programming was invented with Simula in the 1960s. I think I can safely say that an obscure academic idea eventually came to fruition.
Take a look at modern languages. Python has borrowed the concept of "list comprehensions" from Haskell and Miranda, (two FP languages), and in fact also provides functional constructs like "map" and "lambda" expressions.
Eiffel now has "agents", or "functional objects".
Perl has gained "closures".
And so on.
These ideas are all taken from declarative languages, and it is my contention that declarative programming is going to become more and more important.
That's it. Not that imperative programming is going to disappear, (people still program in C as well as C++). Just that more and more programming will take place in a declarative fashion.
David B. Wildgoose
Tuesday, March 9, 2004
>>Is that similar to DTS 'programming'? 'cause I hate that. You can fit a lot more text on the screen than you can icons.<<
Sorta, yes. True, you can fit more text on the screen, but the graphical front end provide a much clearer organization of your throught process that you can demonstrate to laymen.
>>Some purport to offer end users the ability to prgram without needing programming experience<<
Ascential does not promote this as a 'idiot-free'. They just promote it as a 'much faster and clearer way to handle data transformation.
>>graphical _languages_ will continue to be of only marginal interest, but graphical _tools_ will flourish. Design tools will produce as their output programs in declarative languages.<<
That is exactly what Ascential DataStage (and DataStage EE) are. Graphical tools that is a front end for a very solid system (DataStage EE are both Orchestrate and C++ - you build stages using C++, and you use Orchestrate to link them all together.)
This is a concept that can be taken much further into other fields. This tool is excellent for Data Warehousing, but definitely not useful for game programming.
But I can tell that similiar concepts can be done for game programming -- switch to text when you want to hard-core your way out of a problem, and back to GUI when you want to build the framework.
>>What are ETL tools?<<
Extract, Transform, Load. Tools that handle Data Warehousing for companies. A focused tool can help optimize your development, debugging, and deployment. Writing something in C++ could take me about a week. An equivalent using DataStage would take me maybe 2 hours. Of course, it varies depending on the tasks.
>>"graphical" programming or "genetic breeding" will remain niche solutions, in my opinion -- the ideas may sound fantastic, but they lack precision and terseness that is needed, and available with textual descriptions.<<
Why not have both? Why are you trying to focus on one or another when both would provide you with a dramatic benefit?
DataStage provides both. Most people sticks with the GUI, but I love dropping down to code to debug code that resists any solutions on the GUI level.
-T.J.
(I may work for them, but I do not speak for them. All of this is my opinion only.)
T.J.
Tuesday, March 9, 2004
>> "Why not have both? Why are you trying to focus on one or another when both would provide you with a dramatic benefit?"
Is it just where I've worked, or do programmers in general have an aversion to graphical tools. The first things I do when trying to handle a tricky problem are 1)make a list of all candidate patterns which might help and 2)jot down some UML diagrams. I would be in seventh heaven if there were a powerful graphical environment that would allow me to design using pictures and drill down to the source code - maybe dragging and dropping catalogued patterns where they fit. Maybe providing an expert system to suggest patterns I haven't thought of. Seems to me most math/sci/tech people think in pictures first, and refine top-down towards the equations/source code.
Any opinions or comments? Are developers overly fixated on text? I've known many developers who laugh at UML & many data modelers who shun ERDs. In my opinion, pictures are certainly worth a thousand words (give or take an order of magnitude). For me, the source ain't the documentation! Will graphical/iconographic environments/languages cause the revolution I envision?
dave
Tuesday, March 9, 2004
I strongly think we'll do more visual programming. For example, I tend to visualize the shape of the function stack when doing errorhandling or certain computations. I think the reason many languages are weak with functional programming is because people don't get to see it; the stack is this invisible thing programmers don't get great access to. If it were visible, everyone would probably use better errorhandling, some dynamic scope, etc.
Another way is by analogy to html. The <language>language</language> itself isn't readable. But it is transformed into one which is. We could use languages which don't have much syntax, but are transformed into forms which do. And the syntax can be readable by nonprogrammers to match their own domain-specific syntaxes.
A big question is how will graphics and text merge. Text is an incredible thing; they're little graphics to which we ascribe meaning. I wouldn't mind using nontraditional graphics mixed with normal text; within the scope of a piece of data, it would be represented in sourcecode by a picture but silently expand to text by the compiler. Or it will be linked to explanations of the domain it represents. Self-documenting data.
Data-driven programming operating on things which visually look like the data.
The mental stack can overflow with ideas...
Incidentally about paradigms, I suggest Floyd's "Paradigms of Programming" Turing Award lecture. Basically a nice chat about how certain patterns help people solve problems. Like the map/filter/fold stuff of basic functional programming really wows people with what they can accomplish. Incidentally, that stuff can definitely be depicted graphically... ;)
Tayssir John Gabbour
Tuesday, March 9, 2004
>>Are developers overly fixated on text?<<
Yes. We are all used to being able to manipulate things with our keyboards.
That is why decades-old coders HATES DataStage. They lose the control they are so used to dig around with. Drilling down to the code were not very well known, so they would give up after suffering crashes after crashes that they can not mentally translate from the pretty pictures.
Basically, this is why Visual Studio is well adopted, it is very text-heavy while displaying minor (beginning stage of) GUI interface. Classes are categorized. You get call stacks while looking at the code and the peeks at the same time. Its debugging capabilities sold the tool as a godsend.
I want to see it go further -- give me a visual representative of how the program flows. I don't care what the little gritty things is -- I want to see it flows. A lot of times, in large scale applications, it is very difficult to keep track of this. A little design change here would affect programs that touch it from THERE. Visual cues would help a lot in maintaining and developing good code.
However, it is a VERY hard concept to really put together and be adopted. rapidly. Change Management needs to be done for the old hats.
T.J.
Tuesday, March 9, 2004
Fascinating stuff. Thanks especially for the references to other literature.
dave
Tuesday, March 9, 2004
David, I think that you're confusing functional programming primitives with declarative programming. I can use lambda and map to, say, implement an algorithm for computing the square roots of a list of numbers:
(defun close-enough (x1 x2)
(< (abs (- x1 x2)) 0.1)
)
(defun rec-sqrt (x g)
(if (close-enough x (* g g))
g
(rec-sqrt x (- g (/ (- g (/ x g)) 2.00)))
)
)
(defun sqrt (x) (rec-sqrt x (/ x 2.00)))
(map (lambda (x) (sqrt x)) '(4 9 16 25 36 49 64 81 100))
But that wouldn't be a declarative program. A declarative version of the program would, for example, define sqrt in a way similar to:
Y is that number which, when multiplied by itself, produces X
(And sqrt = Y, given X)
Functional languages aren't declarative by nature, though they can have declarative dialects (like the famous Prolog-interpreter-in-Scheme example).
K
Tuesday, March 9, 2004
>> (rec-sqrt x (- g (/ (- g (/ x g)) 2.00)))
Ugh. How do you READ this stuff?
Ignorant youth
Tuesday, March 9, 2004
What notation would you prefer?
K
Wednesday, March 10, 2004
Programmers hold most of the abstract concepts of their work in their heads because there is no way of describing them on a two dimensional surface in inky lines. One breakthrough would be to model the inter-relationships in code in a representative model that you can manipulate. The trouble here is that I suspect there are more than three dimensions on top of which those inter-relationships change with time, context and state. I don't think this lends itself to a pretty picture. In interim step might be to create such a tool but with the set of operations that it can support limited by its ability to display those relationships. That would cause a major shift in software development with some compromises - just as Java or Web Services force compromises. Another advantage of such a tool is that if you can map relationships to I/O, state, etc. You can also map on your test cases and see where the coverage is missing. Etc.
What would also be nice is a tool which allows you to define an interface and the equivalence partitions for each parameter or set of parameters. The tool then writes code to perform those transformations. Then you tell it where it has gone wrong - because of those pesky unforseen conditions - and work your way towards the finished system.
Woodentongue
Wednesday, March 10, 2004
>> "Programmers hold most of the abstract concepts of their work in their heads because there is no way of describing them on a two dimensional surface in inky lines."
Hmmm... Very interesting comments, but I'm going to nitpick anyway! ;-) I've seen the most bizarre, abstract concepts in algebraic topology, or mathematical physics represented by models scribbled on paper napkins. I don't think there's anything I do as a developer that couldn't be modeled effectively in two or three dimensions by a clever enough modeler.
dave
Wednesday, March 10, 2004
No, I do understand what declarative languages are, I am afraid it is you who are in error.
Take a look at:
http://www.csc.liv.ac.uk/~frans/OldLectures/2CS24/declarative.html
Here's some quotes:
...the principal distinction between declarative languages and imperative languages is that declarative languages allow the programmer to concentrate on the logic of an algorithm (declarative languages are goal driven, control is not the concern of the programmer), while imperative languages require the programmer to focus on both the logic and control of an algorithm.
...and...
There are two principal styles of defining relationships available to such languages:
1. Functional
2. Logic
David B. Wildgoose
Thursday, March 11, 2004
David,
I think that if you reread my last post, you'll find that it's in agreement with the definition of declarative programming in those notes. However, I don't think that's the definition you were working with when you said this:
"Take a look at modern languages. Python has borrowed the concept of "list comprehensions" from Haskell and Miranda, (two FP languages), and in fact also provides functional constructs like "map" and "lambda" expressions.
Eiffel now has "agents", or "functional objects".
Perl has gained "closures".
And so on.
These ideas are all taken from declarative languages, and it is my contention that declarative programming is going to become more and more important."
None of those things has anything to do with declarative programming directly. As I discussed in my last post, those constructs can be used to write an imperative program that implements a square-root algorithm.
K
Thursday, March 11, 2004
David, here's a good example of what I'm talking about:
http://www-db.stanford.edu/~burback/watersluice/node144.html
The example of Eiffel's function constraints is key. To synthesize the two kinds of knowledge into an Eiffel function, with my previous example, you'd have a sqrt(x) function with a precondition that sqrt(x) * sqrt(x) = x (the declarative part), followed by the particular method I described for computing a square root (the imperative part).
K
Thursday, March 11, 2004
>> What notation would you prefer?
This one:
(defun close-enough (x1 x2)
(abs (x1 - x2) < 0.1))
I realize there must be a reason why infix is not used here.
All I'm saying is that, at first glance, a parser can *internally* convert the above to whatever notation it likes. While keeping it readable for me.
Ignorant youth
Thursday, March 11, 2004
I agree, and I prefer infix notation for anything mathematical.
K
Thursday, March 11, 2004
OOP died a long time ago in my mind, but it has taken surprisingly long for the idea that OOP may not be the way to go to settle in. C# seems so baroque, so very 1995. Lightweight OOP, a la Python, is a different story.
I think what I find most interesting is how many people don't know what else there could possibly be when you take heavy OO-ness off of the table. For example, some people don't seem to think you can have proper modularity without OOP. They're not familiar with Modula-2 or Ada or Oberon or Turbo Pascal, I guess.
Junkster
Thursday, March 11, 2004
Junkster,
What exactly do you think that C# people get wrong that Turbo Pascal people get right?
I wrote software in Turbo Pascal, and I don't remember anything being in the language that isn't in C#. I agree that "object-oriented" concepts aren't the only useful means of abstraction, but I don't think that they're worthless either. What specifically do you think are the failings?
K
Thursday, March 11, 2004
K, I think we are talking at cross purposes and are actually largely in agreement.
I consider "map" to be a declarative process rather than a functional "primitive", which I reserve for Lambda Calculus and its ilk. It is applying a function to a collection without describing how the collection should be iterated through. The imperative version will start by finding the first element, apply its function, then attempt to find the next element, and if this succeeds it will repeat the previous steps, or otherwise exit.
In other words, how to do the loop has been expressly stated in an "imperative" fashion. "Do this, then Do that".
Simply declaring that you want a function applied to every element of a list is declarative however.
This is what I meant when I said that many imperative constructs can actually be abstracted out of a program.
For example, Haskell in particular has made enormous strides forward with its "Type Classes". These enable the programmer to specify something as an "instance" of a type along with some idea of how it should be handled. This then enables an enormous number of functions to suddenly become available to those types. And in fact, in many cases it can all be handled automatically as well, simply by declaring that you wish something to be handled in a particular fashion. This is enormously powerful.
None of this means that imperative programming is going to go away. Just that declarative programming techniques are slowly seeping into day-to-day imperative languages.
David B. Wildgoose
Friday, March 12, 2004
David,
I see where you're coming from with the map example, but I don't see how it applies to your earlier inclusion of lambda and closures and so on.
When I think of declarative knowledge, I think of facts and deductions (or, equivalently, search parameters and searches). When I think of imperative knowledge, I think of machinery that satisfies some external declarative constraints (possibly one of many such choices of machinery).
I think that what you're talking about is abstraction and the separation of concerns, which can be used in either declarative or imperative knowledge. For example, the 'vector' in 'a vector I exists for each vector A such that A * I = I * A = A' is an abstraction contained in a declarative statement. It's also an abstraction in the imperative statement 'for_each(vec.begin(), vec.end(), project_to_view(my_view));'.
Incidentally, std::for_each in C++ does the same thing as Lisp's map function.
K
Friday, March 12, 2004
 Recent Topics
Fog Creek Home
|
