Slashdot Mirror
Ask Slashdot: What Should Be the Attributes of an Ideal Programming Language If Computers Were Infinitely Fast?
An anonymous reader writes: Earlier today, Tim Sweeney, the founder of Epic Games, asked his Twitter followers an interesting question: "What are the attributes of an ideal programming language if computers were infinitely fast, and we designed for coding productivity only?" I could think of several things, the chief of which would be getting rid of the garbage collection. I was wondering what other things you folks would suggest?
This is stupid. Computer will never be "infinitely fast" or even close to it. There is always the possibility of ding computation in such a way as to drag down any system.
There is always a compromise between programmer productivity, code maintainability, and system performance. It's not like you can realistically escape this triad so why pretend one leg does not exist? The computer programming industry has enough problems with magical thinking as it is.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
...and infinitely fast computer would be self aware and wouldn't need instructions.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
And GOTO, no GOSUB though, that's dumb
The language for an infinitely fast computer is called DUH.
There are no keywords, operators, or logic structures; the entirety of the language is you typing "DUH" into the command line, then hitting ENTER.
Upon pressing ENTER, you are presented with every possible program that could ever exist. All you need to do is select the one you want.
Obliteracy: Words with explosions
Getting rid of garbage collection? The feature whose whole point is boosting productivity at the cost of performance? In a setting where performance is explicitly not and productivity explicitly is? Can you spell "hangup"?
sudo ergo sum
It should be a highly parallel language, where you can program with constraints.
There is no garbage collector in C, so it must be the ideal programming language ;-)
Special mention for assembly too.
"Science will win because it works." - Stephen Hawking
It should be capable of understanding normal language, any known language, and execute the idea of what you asked for... But do so with disastrous unconsidered consequences. Man should not toy with technology!
This sig intentionally left blank.
You still have to write the correct logic. So the question is essentially, "what features of a programming language lead to least logical errors?"
I just imagine a world of cross-joins, extremely complicated in-string, lazy iteration and the like.
If there were no penalty for pivoting data or iterating though sets, we would all gravitate toward the shittiest constructs imaginable...
I mean hell, browsers are basically expected to be limitless now... HTML hello world used to look like "Hello World" Now it looks like
"Hey javascript framework, load 500 modules, then ask the server what "Hello" is, then ask the server what "world" is, then style it all in whatever your 13 generated CSS files say it should be styled as, and tell google analytics that someone looked at my hello world page."
Wouldn't an infinitely fast computer be completely useless in that doing anything with it would result in a race condition?
Obliteracy: Words with explosions
The amount of memory GC uses isn't a problem if you have infinite performance.
GC uses more memory than manual memory management exactly because you can't run it all the time - you have to let the heap grow, and then do a collection when you stand a chance of actually freeing a bunch of memory.
With infinite performance, you can run it after every single line of code that might possible have changed which bits of the heap are referenced still, that means you actually get *improved* memory usage over manual memory management (since no one gets that perfect, in general).
It should be able to understand and do whatever comes after "I want you to..." both as a vocal or written statement.
I guess he never heard of Wirth's Law. Compared to 20 years ago, our computers are operating at and infinite speed with ridiculous amounts of RAM. Yet the desktop, IDEs, and applications seem slower than they were 20 years ago, require Gigabytes(!!!) of RAM, and do not seem to do anything more than they did before. Go figure.
What a pedantic bunch. Mental race conditions because of the word 'infinitely'. Anyway, let's ask this question a different way. "If modern hardware had been available at the time, how would you have designed languages like C, C++ and JAVA? What compromises were made that continue to impact those languages?"
One of the goals of the problem statement was to improve human productivity. Therefore GC would be a requirement. Not having to manually manage memory removes a large burden from programmers.
GC has an often overlooked, but fairly silent other advantage. It greases the compatibility of libraries written by many different authors. All of the libraries are guaranteed to have the same memory management discipline. Just to pick on C / C++ for example, multiple libraries might have different memory management disciplines. It is necessary to understand whether the API has special functions to deallocate some structure, and who is responsible for such deallocation. With GC all of that disappears. If an API call hands me back a datastructure, I just let go of it when I'm done with it. No concern about who deallocates it. The GC is what deallocates it when there is no longer a reference to it.
Another important attribute would be toolability. Java, for example, is very toolable. IDEs for Java are able to statically deduce a great deal and then offer intelligent suggestions to auto complete things as you type. There is doubt about what type of parameter some function has -- because it's statically typed. There is no doubt about what local and global variables you have available, of that type, which could be passed as the actual value for that parameter.
Basically the Editor knows about your source code as well as the compiler does. If you click on some function name, or variable name, or class name, it is unambiguous where it is declared.
Modern Java IDEs also can intelligently rename things. If you rename some identifier, the IDE knows precisely what other parts of your entire source code base need to have this same rename done. If I change function 'abc" to "def", not only is the declaration changed, but every reference to that function throughout the program. But if there were another local function somewhere else with the name "abc", it would not be changed, nor would references to that. The compiler knows exactly, unambiguously what references what.
There are many other powerful refactoring tools as well. People who say they will use a simple text editor because they don't like the bells and whistles of a modern IDE is like someone saying that they would rather dig a huge ditch with a shovel because they don't like the noise of a backhoe.
Static typing would be a must for large programs. Modern languages with type inference allow you to avoid typing in much of the type information, yet still have static typing.
Static typing is not primarily about performance (although it is about that). (And the problem definition said performance is infinite.) Static typing is also about correctness of code and compile time checking, and the toolability and refactoring I mentioned.
I'll see your senator, and I'll raise you two judges.
So if I screw up and create an infinite loop this computer would complete the loop anyway in only one unit of time?
1) The language would be graphical
No, physical. It would have one analogue keyword consisting of how hard you are hitting the robot with the stick, and/or how loud you are yelling "no, you stupid git!"
Someone had to do it.
There very much would be a reason to change programming languages. With infinite speed, you could do an exhaustive search for proofs of correctness, so you could write the requirements for the program & have the language formally verify it without any extra effort (provided a proof of correctness exists at all).
For that matter, why not just write test cases & constraints & have it find the simplest program that passes all of them? At some point, you would either have enough constraints that the simplest program is correct, or you would realize you did not actually know what you wanted.
Which is why the question is stupid. This is not how advancements are made, this is how people are lead down false paths with a dead end. Advancements are made by considering the impact of all important factors...
This line of thinking is foolish. Advancements are made from all kids of approaches. If you want to think innovatively, you should probably be following paths you assume will lead to a dead end. If are aren't failing most of the time, you aren't thinking very innovatively.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
And I'd design the language so you don't worry about that. If you don't use a library, it will automatically be removed.
Hell, I don't think I would even bother with such low level trivialities.
Star Trek is the better example. They ask the computer what they want done, the computer figures it out and presents them the output. They're programming, but not. Or how they program the holodeck - they ask the computer to generate a character on the holodeck, then load up various behaviours using commands. They can even program simulations of characters.
Or how they reprogram the Universal Translator with a few parmeter changes and get it working again, or adjust the phasers to transmit in some way You think it up and with a few keystrokes, everything is reconfigured.
How does a garbage collector that handles circular references determine which objects to finalize first?
The real question being asked here is, "How do you make a programming language easier and more idiot-proof?" Right off the bat, there is just no substitute for ability + experience. You need both (or if not experience, a whole lot of ability).
Remember, the thing a programming language does is translate human-readable text into processor instructions - one's and zeros.
How to do that more easily and have the program robustly do exactly what you want? Object oriented is brilliant IMO, for example. Forcing you to make classes (a way to group code), and create complex methods (functions), and just instantiate the object (the mere act of doing so running multiple functions, and being able to call with one line a function that does a whole bunch of stuff.
First there was assembly, line by line interaction with the processor. Then Basic, then function-oriented programs which groups functionality into functions, then object-oriented programming (grouping functionality into classes and their methods), and object-based programming (e.g. JavaScript - everything is an object, except primitives).
What is all this leading to? Trying to take the average human's mental concepts and turn them into machine code in an easier and more error-proof fashion.
Deep stuff for a Slashdot thread. We'd need the likes of Claude Shannon and Bjarne Stroustrup to really bite into this.
People are still going to need to learn the language of the computer, even if/when it could understand natural language ("I wanna add this list of numbers together, divide it by the number of numbers" versus "I want the average of this list of numbers". "And then I want to display it in a flashing red box.").
Christ, what a maintenance nightmare. Ease of generation of machine code versus maintainability? "Why was this asshole doing all this bit shifting in this function?"
Well, hopefully I framed the real question a bit better, got no idea of what the next evolutionary step would be.
I'd replace a programming language with more of an interview system.
Basically, you'd tell the computer what problem or task you wish it to do. If it knew how to perform the task, then your job is complete. If it doesn't know, it would ask you to break the problem down into smaller sub tasks. You do so and for each sub task that the computer knows how to solve, it would do so. And for each sub task that it didn't know, it would recursively ask how to solve those sub tasks. As for a library, the computer would remember every task that it had been taught previously.
There would still be programmers, but their job wouldn't be using any specific language, but instead describing how to solve problems or perform tasks.
WIth an infinitely fast computer you don't program steps or equations rules to compute the result. Instead, you infinitely fast generate random result sets and program simple broad rules for what is an acceptable result match. Your CPU has infinite branch prediction, so it explores all paths instantly. I really think the poster meant quantum computer programming language. Because Quantum computers are somehow infinitely fast because they can explore all results simultaneously.
Léa Gris
Star Trek is the better example. They ask the computer what they want done, the computer figures it out and presents them the output. They're programming, but not. Or how they program the holodeck - they ask the computer to generate a character on the holodeck, then load up various behaviours using commands. They can even program simulations of characters.
Or how they reprogram the Universal Translator with a few parmeter changes and get it working again, or adjust the phasers to transmit in some way You think it up and with a few keystrokes, everything is reconfigured.
The question was about an infinitely fast computer. Star Trek is a few steps beyond current computer speeds but still not infinite. Still, thinking Star Trek is better than what some others are thinking so far.
When you go into a physical library, you see knowledge and other works somehow compiled, for all you know over an infinite past amount of work. You wouldn't dream of spewing such an output within your own predicted lifetime. Then being a slashdotter, you ask yourself, what is the ultimate state of the Library of Congress if it simply progresses linearly yet to perpetuity? It will be nothing less than boggling.
So perhaps there is a command in the idealized programming language that looks like this: querylibraryofcongress, or perhaps: askjeeves. Even such commands underestimate the power of infinity. When considering an infinite computer, it's time to reverse engineer. You ask yourself, how would I make a light saber?, not ever living in a world where one exists - that's the kind of reverse engineering going on here. Now, reverse engineer the infinite computer ...
Here's another command: costzero. I.e., run without costing anything! Somehow it will figure out how to do so. Naturally, a computer of infinite speed would be ensured to be connected sufficiently to the universe in order to obey.
Here's another command: goaheadmakemyday. The output will make you happier than whatever you can imagine you want.
Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.