#1 It would take too long for the compiler to figure out what the programmer is saying. There is many ways to express a single idea, and the compiler would have to be absolutely massive in order to have every way, and it STILL wouldn't have them all. Basic is the closest to a literal language, and thats easy enough for most people to learn.

#2 Dijkstra deals with this better than I ever could: www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html

#3 I want to agree with you Will, that computer languages should look just like our natural languages, but i think i have to agree with the programming community that it won't really make it much easier to write programs.

The main task in writing a program is breaking down some large task into smaller, methodical ones. Expressing those tasks in some particular syntax is really secondary, and after a few months in any given language it usually stops being a stumbling-block.

I do agree that languages should Try to be as human-readable as possible,
altho not because it makes them incredibly easier to write in,
but because it makes the code easier for someone else to understand later.

As mentioned, Visual Basic is probably the most literal language going.

#4 Nah... I would have to say that programming languages work as they are because syntax is simple. While its true that some people might have trouble learning these languages, the simplicity of the syntax is nessecary for each command to have a very precise meaning, and with a literal programming language, that just wouldn't be possible. With a literal programming language, syntax would become overly complex and the interpretation would become problematic.

#5

Quote:If John has 5 apples and Sally has less than 3 oranges then give Jason 7 pears.

If John is holding five apples and Sally doesn't quite have three oranges, give Jason seven pears.
Say John's got five apples and Sally's almost got three oranges, then give Jason seven pears.
Does Jason want seven pears? Well, he only gets them if John has five apples and Sally has no more than 2 oranges (though if she doesn't have any, that's cool).
Does John have five apples? If so, does Sally have fewer than 3 oranges? If that's all good, then let Jason have seven pears.
Should Sally ever have fewer than three oranges, and John has five apples, then give Jason seven pears.
If John has five apples, but Sally has three or more oranges, Jason is SOL when it comes to getting any pears.
Dude, liek WTF! John's gots 5 aplz n Sallys git 2 or so 0rngz (i dun no but no more then 3...i thnk) so i givez jas liek 7 peerz. lol! ;-)

I'd hate to write the parser.

#6 English is too ambiguous, whereas code needs to be precise methinks.

#7 AppleScript (the scripting language for OS X) is a fairly "literal" language and can be used to write a variety of utility applications. It's not as robust as a full programming language like C++, but it's quite powerful in its own right.

Here's an example of what the code might look like:

on replace_and_select(target_string, replacement_string)
	tell application "Script Editor"
		tell the front document
			set this_text to the contents
			set this_offset to the offset of the target_string in this_text
			if this_offset is not 0 then
				set selection to characters this_offset thru (this_offset + (length of the target_string) - 1)
				set the contents of the selection to the replacement_string
			else
				set selection to {}
			end if
		end tell
	end tell
end replace_and_select

It can get tedious, but it reads a bit more like English than most languages out there. There's still quite a bit of structure required though, so things don't get out of hand like in David's example above (which is insane! :p ).

#8 Interesting input on this, thanks everyone.

Well, if I were to make a programming language that's how I'd make it... :P

I would make it flexible enough that you could write in conventional syntax or in "readable" English form.

For example, you could write:

&& or and
|| or ...or!
= or equals, is, has
== or give, assign
; or .
> or greater than
< or less than
++ or increment
-- or decrement
and so on....

And there would be no need for squirly brackets or braces. Every statement ends with a period. Every major block of code is a paragraph. It would be like reading a book.

My point:
When programming languages were first being made, it would be unimaginable to write in this literal form... but today, I believe it's quite possible to do. I bet any one of you programmers could easily make a scripting language that would work this way! The reason it hasnt isnt because it isnt practical or cant be done, its because of legacy. Would any of you like to write an entire program in Assembler only? Probably not (although for some Im sure that wouls sound like fun)... and look at how much easier coding is today. So I think this could be a natural progression for computer languages...

#9 If sentence diagraming actually made sense to anyone who spoke English instead of linguists who study English, it would be an interesting proposal. But more structured languages such as Latin, Spanish, ASL, or Japanese would be a more intuitive.

But looking at language syntax is nearly the same regardless of programming versus linguistics, but when you hit a horribly adaptive language like English, it actually becomes more and more simple to constrict syntax than allow for natural language.

Convention and tradition do have a place between natural language study and programming syntax study. Things like AppleScript (which was an excellent language example) and Prolog are great steps in this direction, but the syntax is still as limiting, but not nearly as concise as programming shorthand.

Is there a real difference between...
THIS IS A BLOCK CALLED "MY FUNCTION". (period in or out of quotes depending on professional formatting style)
THIS IS THE END OF THE BLOCK "MY FUNCTION."

or
BLOCK MY_FUNCTION
ENDBLOCK MY_FUNCTION

or
myFunction{
}

...other than concise syntax (and compiler implementation).

#10 Will, I think this is a great idea, but what I think might be more realistic is a "translator" that will take a language like C# and convert it to readable English or vice-versa. That way, programmers can still write in a "short-hand" version, but beginners can pick up the language much quicker through the written form.

#11 Reminds me of Visual Basic... I don't like VB

#12

Quote:Is there a real difference between...
THIS IS A BLOCK CALLED "MY FUNCTION". (period in or out of quotes depending on professional formatting style)
THIS IS THE END OF THE BLOCK "MY FUNCTION."

or
BLOCK MY_FUNCTION
ENDBLOCK MY_FUNCTION

or
myFunction{
}

Well, in this case I think one simple way to handle it is, by following the book analogy, using headings.


For example:

My Function

The operation of this function here.


That's it. The function would naturally end before the start of the next heading or section so there is no need to explicitly close the function (e.g. "This is the end of the block My Function").

Now how would you actually define that title as the heading? Well, there are two ways I know of, using a traditional GUI-based program (e.g. like WordXP) you could select the text and change the format to the heading type.... the second way is by mark-up (e.g. [hd1]My Function[/hd1]) but that somewhat defeats the idea of keeping it simple, so the GUI-based approach is better IMO.


To elaborate on the "Book" analogy...

A book has a title --> this is the title of the program or the main super Class
A book has chapters --> Each chapter is the definition of a Class/Object
A chapter contains sub-sections with headings --> Each sub-section/heading defines functions
Sub-sections contain paragraphs --> paragraphs are a logically contained block of statements
Paragraphs contain sentences --> each sentence is a statement

However, a book could be a part of a greater program, just like a collection of books creates a Volume Set.... like a collection of .dll files functioning together.


So here's my attempt to create a sample program using this concept, but only by creating a Table of Contents:


(Volume 1 of Collection "Vehicles")

Book Title: Car

Chapter 1: Engine
Heading 1: Fuel Injection System
Heading 2: Intake Manifold
Heading 3: Spark Plugs
Heading 4: and so on...

Chapter 2: Transmission
Heading 1: Gear Shift Lever
Heading 2: Drive Shaft
Heading 3: Differential
Heading 4: and so on...

Chapter 3: Fuel System
Heading 1: and so on...

Chapter 4: Wheels and Brakes
Heading 1: and so on...

Chapter 5: Suspension and Steering
Heading 1: and so on...


Re: VB.... The only really good thing about VB or Delphi is the controls for making your own GUIs.... and also the language can be more forgiving to beginners. It is aiming in the same direction though...

make it simpler
make it faster
make it easier to understand/read

#13 There was a program being built a while back by ration rose but it was pretty crap-tastic.

Oh and please lets not turn this into a VB bashing post. There is enough of them out there.

Let's face it, it's easy, it's quick and most of us who ever programed network applications can tell you that it does what it needs to do.

All the time that I programed for a living, I really can't think of one real time where I had to kill myself over working.

#14 I programmed VB for a while... I just don't really like it much, I much prefer C++, php, actionscript... TorqueScript

#15 The people who dont like VB are the purists... and they would probably not like simplified solutions at the cost of more over-head. I can understand that... nothing wrong with that view.

#16 True... and I say whatever works for you... though I'm a big supporter of keeping things consistent

#17

Quote:If John is holding five apples and Sally doesn't quite have three oranges, give Jason seven pears.
Say John's got five apples and Sally's almost got three oranges, then give Jason seven pears.
Does Jason want seven pears? Well, he only gets them if John has five apples and Sally has no more than 2 oranges (though if she doesn't have any, that's cool).
Does John have five apples? If so, does Sally have fewer than 3 oranges? If that's all good, then let Jason have seven pears.
Should Sally ever have fewer than three oranges, and John has five apples, then give Jason seven pears.
If John has five apples, but Sally has three or more oranges, Jason is SOL when it comes to getting any pears.
Dude, liek WTF! John's gots 5 aplz n Sallys git 2 or so 0rngz (i dun no but no more then 3...i thnk) so i givez jas liek 7 peerz. lol! ;-)

*wipes tears from his eyes* omg roflmao ... i belive David Blake summed it up perfectly.
Programming is simply talking to the compiler in a language it can understand. However, we as programmers need very speicific things done in a very specific manner. Thus the language must also be specific and structured. ( Unlike the english language )

#18 @Will: I think the idea is novel, but flawed. If you would take some time to walk through a few lines of code that actually does more that loop though an empty loop 10 times, or set a value, then you would quickly begin to realize that real code is accessing references to pointers, passing these references to other classes, instancing classes, inheriting their functions and so on... It would be hard to acurately describe these things in "english". In reality though, these advanced operations are stream lined into a few lines of code that are clear, effective, and elegant (If done correctly).

Turning source code into an english language would be similar to saying, "Lets simplify math problems by typing them in english." For example change:

((10*5) + (6/2)) * 3

into

"First multiply ten times five, save that value into slot1. Then divide six by two and save that value into slot2. Now take the value you saved in slot1 and add it to the value in slot2. Save that result into slot3. Finally take the value in slot3 and multiply it by three."

Effective? Since the parenthisis location affects the answer we are forced to describe the process in agonizing detail. (This happens in coding more than not)

Also, it is hard to visualize the "English" version of the math problem. Can you imagine the nightmare involved in debugging such an "English" monster.

The problem isn't the current system, but a lack of understanding about what the current system represents. I agree though... If you don't understand operator precedence or parenthesis, then the first line would look like greek. If you do understand these things then the first line looks clear, efficient and elegant. It allows your mind to visualize the procedure in a way that the "english" version does not afford.

Instead of claiming the current system is not effective or that programmers have not fixed it by now because of legacy demonstrates a lack of understanding, or worse a lack of desire to learn, which in either case would automatically exclude that type of person from creating any form of useful coding logic no matter how it was typed.


B

#19 There is a guy in 4th year at my university that is making a program where you can sit down and drawn mind maps of the program that you want and it will convert it into XML and then into any language you like ,its very cool program but at the momment can only handle the main sturcture of the program like classes and methods. still have to hand write loops and switch statements

#20 @Brandon

As a software engineer I can tell you point blank that you are wrong and Will is in fact correct. You talk about pointers and references so I assume you haven't encountered a language called smalltalk before.

The sole purpose of a computer language, is to allow a programmer to describe computer logic in a human readable manner. The compiler then converts this description (we call it source code) into a machine understandable form. Often one statement or keyword in a language converts into many machine code instructions and it is the order in which these instructions are executed that determines the outcome of a program run.

Because of the nature of computer languages, it is not inconceivable to create one that is near english (cobol or ada for example). The only real overheads would be increased compile times and larger sourcecode files, neither of which matter too much in todays world of high speed cpus.

In the last 20 odd years as ISO standards have really taken off, you will notice that the standard, with regard to source code is that it is clearly laid out and well commented, with plenty of white space to ease reading. None of these requirements are even vaguely aimed at the computer.