What Is The Future Of Programming Languages?

MrProgrammer asks: "With hybrid languages like C# coming down the pike, what do you see as the next advances to be made in programming? We have languages from Assembly to Visual Basic, covering what would appear to be the entire spectrum. Is there anything else to be added? Is there anything beyond OOP?"

Comments

Re:It depends a LOT on hardware

[nellardo]

What I mean is this: Microcode allows you to soft-code each "instruction" in the instruction set. There is therefore nothing to stop you making those as high-level as you like.

That's true. But keep in mind that microcode existed before RISC instruction sets. You could program in a high-level byte-code, but almost no one ever did (the most recent exception that I'm aware of is SGI's propensity for microcoding the hell out of their graphics accelerators to run GL real fast). I think it was the VAX that had an assembly-level instruction for "find the roots of this polynomial". Essentially no one programmed in assembly (except kernel hackers, who didn't usually need polynomial roots....) but no compiler was smart enough to figure out when it could use that instruction. Even if the instruction had a library call interface, people that really cared about the accuracy of their roots would want to choose their own algorithm (and if they weren't coding in assembly, there was no way they were going to touch microcode).

What I'm suggesting is that the compiler does NOT compile the "program" to suit the processor(s), but change the processors to suit the program.

At one level, there's no theoretical difference - do you transform A to use B or B to use A? If the program and processor are both correct, and the transformers are both correct then this kind of transform should be associative through composition - i.e., (trans A) -> B == A -> (trans' B). On another level, transforming machine types (in the Turing sense of machine) can change the run-time, sometimes exponentially.

In this case, what you'd do is, for each object, is replace the microcode for each opcode on the corresponding processor with the compiled code for a given method.

Realistically, what's the difference here between what you've proposed and what presently happens? RISC instruction sets are pretty close to microcode already - that's intentional, and how they were designed, for just the kinds of purposes you propose. Register windows on modern processors were in fact designed for object-oriented programming (see David Ungar's Ph. D. thesis on a processor designed for Smalltalk - Ungar is now a researcher at Sun and one of the pioneers in just-in-time compilation).

eg: Let's say you have a class "btree", with methods for creating a new root node, checking if a tree is empty, adding a node, deleting a node, and returning the value of a node. You program these as your new opcodes for your processor. You now have a RISC instruction set, with 5 opcodes and a pseudo-register for the value of the node. (You actually have a further opcode for selecting an instance.)

Self's bytecodes are in fact much like this. Self has eight bytecodes - three bits. If I remember correctly:

• Send a message. This used five bits to index into a table of message names.
• Put a message string in the table.
• Extend identifier. This is used to have more than a five bit index, either for putting in the message or retreiving it.
• Non-local return.
• Primitive assign. Used five bits for the slot name.

and a couple others I dont recall - non-local return probably, and possibly one to push "self" onto a stack.

The concept of a program no longer exists, in this model. As your "program" is now just a series of opcodes, spread over a number of processors, ALL you have, in the way of a program, is an initial call to one opcode on one processor. Nothing else has any meaning.....

I suggest you look into the Agents programming language, by Gul Agha. This is exactly what it is. Even simpler, really - each agent (processor) can send and receive messages, and has one register worth of local storage and a script describing what messages to send when other messages are received.

a lot.

[Zurk]

the languages now are really CRUDE. programmers have to build infrastructure whenever we code. thats prolly the most annoying part (and sometimes the most fun) of coding. what i'd like to see is a language which would provide basic functions off the shelf. if i want an HTML editor stuck between two translucent animated buttons which pull up a hex editor and a MP3 player..i shouldnt have to *code* all that. three function calls and a few lines of code should do that for me in (insert language of choice). i should have to build stuff to parse files...if i want a XML tag called weather in a file somewhere on the disk, it should be able to retrieve it for me in one functional call. Java & the GTK stuff has been trying to do that but it doesnt go far enough. I want a seamless environment to manipulate all the functions available, plus i should be able to cut and paste bits from a library of examples available. And i should have a choice of writing bits in assembly and controlling the machines registers at the same time. tall order huh ?

Further simplification

[satch89450]

When you look at the progression of programming languages over the years, you see a growth in complexity followed by a simplification and maturation. This cycle, I believe, will continue.

The B language is a perfect example. It's atomic elements mapped one-for-one with the DEC PDP-7 instruction set, and included interesting shorthand that sped development. The C language fixed some of the growth pains of B; the standard mandated strong typing so that the compiler could do better what "lint(1)" tried to do. C++ tried to extend the C syntax into the object world, with some consequences good and bad.

What I see, though, is the creation of new languages to solve specific problems in ways that are natural to the particular problem-solver. You see this with business languages that abstract several thousand lines of COBOL code in a single statement. The further abstraction makes writing certain code easier, faster, and more bug-free.

Emphasis needs to be increased on program accuracy. Debugging has been bolted on for years; it's time for significant debugging aids to be included in languages.

Assembly to VB isn't the "entire spectrum"

[alangmead]

By puting things in terms of "Assembly language to Visual Basic" you are really defining the terms of language design really narrowly.

Basically you're just analyzing one axis of the evolution of programming languages,(the pure imperitive branch) from the Assembly to Fortran to Basic to VB (with a few backwards steps with GWBASIC and QBASIC in there.) Its not that far of a stretch. I plan on taking a close look at functional programming, logical programming, 4GLs, etc. before I ask "is that all there is".

I worry about the way you dismiss object oriented programming so quickly too. The way objects work in C++ vs. Smalltalk vs. Python vs. Dylan shows a huge range of study just to decide what objects are and how they work.

It depends a LOT on hardware

[jd]

The efficiency of programming languages is heavily dictated by the hardware that they run onto.

OO, for example, will NEVER surpass, or even equal traditional functional programming, until the hardware is itself OO. (The Crusoe is one step in this direction, where the end result is placing one method in one instruction, one class on one processor, and one instance in a selectable set of registers.)

The reason is simple. OO languages need to be translated to a functional form (which is going to be inefficient) and then compiled to a low-level form (which also looses efficiency).

By designing hardware that is NOT based on the functional concept, you can improve the quality of non-functional languages to the point where they become practical under stress.

Then, there are other developments that badly need to be made. Abstract Data Type compilers are not exactly thick on the ground, but would make writing complex data structures much easier.

Then, too, there is an assumption in computing that you have to move from beginning to end. Yet when you draw up a specification, you don't give a flow, you give mathematical rules which are valid. Nor do you say -how- something is to be done, you simply define the consequences of performing a given operation. Extend the concepts a bit, and you totally seperate the "whats" from the "hows", and the content from the presentation. Allowing the user to control THEIR end, and the machine ITS end will be the next major step forward in computing.