#### Archived

This topic is now archived and is closed to further replies.

# The Perfect Language

This topic is 5095 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Whatever programming language(s) you program in frequently, I'm betting there are blocks or sections of code that you find yourself writing in some variation over and over and over again. So I have two questions: 1. What are they? Be as specific as you need to be. 2. What syntax would you replace them make your life easier? Don't think in terms of existing languages here! How would you write it if you could. (Understand of course that I'm talking about a level of abstraction that fully specifies the actions needed to take place; for example you might say, "render awesome looking fps please" but that doesn't tell the computer how to do what you want.) Beyond that, feel free to tell me what you'd like to see (or not see) in a programming language. My goal is to design a new programming language (with help; open source, gpl, you get the picture) that compiles down thru C to executables (I'm thinking I could use gcc as an intermediate step). Just to get you thinking outside C and Java, one possible syntax structure is "subject verb object" instead of the usual "verb subject object" or "verb object subject". Arguably OOP uses the SVO structure by doing Subject.doSomething(Object); however the point is we can even write it with the dot if we want. Forget all the syntax and structure you know and think about what you WANT. The PC already has it's binary; it's happy. The only other thing we need in a language is to make US, the programmer happy. [edited by - bob_the_third on February 6, 2004 5:36:23 PM]

##### Share on other sites
Something that works more like a neural net -- where the process of writing is less of a serialized sort of experience, but one where different portions are tweaked some at the same time, others in a response to some kind of optimization, extension, etc. This abstratction I believe is already possible. I suppose an example is neccessary:

Suppose you start by first determinining which type of memory management model you want to use within a certain module of your program -- ie, system managed, strict program manager, stack machine, whatever (these aren''t defined as of yet for this specification, but you can sort of understand it even now.)

In the process of writing a program there would also be an added layer of abstratction, one that specifically expresses the modifying source code from a compilation perspective -- ie something of how templates work, along with the preprocessor, inline assembly if desired, and other things all following under a sort of umbrella api that specifically manipulates code (see XDoclet, XML-Databinding, etc.)

Secondly -- to hell with escape characters.
Built-in regular expressions.
Standard abstract data types of course.
Void returns assigned to the void for easier parsing.
An existing recurse directory search method -- done this in about 8 languages.
Some form of easy gui -- I''m thinking SVG compatible.

This stuff is of course mostly off the cuff..

L-

" ''No one has control -- control is just a fantasy. And being human is difficult.'' "

##### Share on other sites
Lucientquiet: I'm definitely with you on the GUI tools; it's the one thing that keeps me (and I MEAN the one thing) with VB. Because I can sit down and whip out a Windows app in 10 minutes.

I want to see if I really understood what you said; are you kind of talking about a language that uses context along with syntax to determine meaning? If so I definitely think that would be cool and it's something I'd like to see. If not, I must have missed you and perhaps a little more elaboration would help my sleep-addled brain.

I don't know about you, but I spend way too much of my time trying to deal with indention to keep my code readable. I don't know if there's a better alternative that wouldn't be a workaround, but...

Also for-loops, do-loops, while-loops. If-else. All these things are cludgy. My seed-of-a-thought (SOAT ) right now is templates on steroids. Basically the language could be a collection of rules which would be templates that could be structured HOWEVER you want and they would then map directly to C/C++ language source files. The compiler would do pattern matching to determine the pattern you were applying. Context-sensitivty would be great too. In addition, the templates could be defined with the code from the language itself. Basically a language that can be redefined/extended at any point in any way (or at least ALMOST any way; not really just any way).

Also I was thinking about having it use an imports approach except not just with methods, but with language constructs, operators, EVERYTHING. Everything is modular and can be overloaded/overridden.

The real trick here would be to set up a highly functional core language that people could use without having to define all sorts of macros (which would offset the efficiency gains) themselves. The macros would be built by those who wanted to contribute to the ongoing development of the language.

One thing I really like about Java is that it goes all the way from high-level to low-level; you can take whatever view you want. I'd like to see this in the "perfect" language. Commands, operators, etc. can be very high-level and have lower-level definitions that you can override if you want. For example in a rendering package, you might have:

"cull P's backfaces" which could be overriden if you found a better algorithm. Notice that I used an apostrophe for a possessive; I don't think I've ever seen THAT in a programming language, but it's an idea (I'm not saying I'm sold on it; I'm just not discounting it right off the bat. The mantra right now is keep an open mind. ). Also notice that P is an object with some sort of polygon-mesh definition and cull is one of the methods defined for that object; backfaces is one of its members.

By the way, if this concept takes form I have plans of beginning a language specification project (completely open; no  involved here, no patents etc.; I just want a GOOD language). The goal is basically to produce a compiler that produces executables, but it can compile to an intermediary language.

Good ideas/points. Let's keep this discussion going. With all the debate on languages around here, I'd say it's worth our while to work as a community to "build a better mouse-trap."

[edited by - bob_the_third on February 6, 2004 6:33:44 PM]

Python !

##### Share on other sites
quote:
Original post by bob_the_third

I want to see if I really understood what you said; are you kind of talking about a language that uses context along with syntax to determine meaning? If so I definitely think that would be cool and it''s something I''d like to see. If not, I must have missed you and perhaps a little more elaboration would help my sleep-addled brain.

[edited by - bob_the_third on February 6, 2004 6:33:44 PM]

Excuse me if I''m mistaken but wpuldn''t that require an EXTREMELY sophisticated AI. I mean If a computer could choose the correct corse of action based on context, that would be WAY more advanced than todays compilers and additionally make programmin(defined as EXPLICIT sets of instructions being read into a computer) as obsolete. thus it would be like the computer in startrek.

Sure it would be possible to exist but not with todays technology(unless you like to wait a good 100 years for each build)

##### Share on other sites
Yes Python rocks too!!!

##### Share on other sites
Fruny: Do you mean that Python is the perfect language or that what I described IS Python?

One potential problem I see with my ideas so far (and that would have to be considered when designing a spec) is without a certain core amount of structure the user will be paralyzed with indecision and won''t be able to get anything done.

So there should be a well-specified rule-set. I lean toward natural-language style in some cases, but not all. Perhaps a mix or perhaps even allowing the programmer to switch between styles at in the same program. They could code in NL, functional, oop, structural, back to NL, etc. Mix and match. But there has to be a syntax (or syntaxes.)

In fact, I envision at least four basic syntaxes:

1. Natural language style syntax (subject verb object modifier)
2. OOP style syntax (subject.verb(object,object,modifier,object...)
3. Structural/procedural
  int myFunc( int a )  {    if ( a>2 )    {      return a*2;    }    else    {       return a;    }  }

4. Functional (more of pure mathematical/algorithmic definitions; for more on this google "Functional Programming").

The user can mix and match and the language should detect the syntax being used. Each of these should be well-defined in terms of structure. They should still be extensible in terms of methods, functions, types, and operators.

##### Share on other sites
You guys are posting faster than I can complete my [long winded] posts!

varanid: What I mean by context sensitive is that what a particular code fragment (such as statement, operator, or method) actually means in terms of execution is based on the code that modifies it. An example would be one of the code fragments I gave earlier:

cull P''s backfaces

P is an object.
It has backfaces as part of it''s definition.
It has defined "cull" to be a method that operates on it to remove unwanted faces from its mesh.

It is possible that "cull" could be used by another object in another way. For example, a database might "cull" out records (although they could just call it "delete" or "remove"). In this case we could have:

cull P''s backfacescull records from Database where Income > \$25,000

"cull" is used in both, but has different meanings based on context.

Now you said this would be difficult. *scratches head* I think you''re probably right. But I don''t think it''s impossible or even beyond the scope of modern technology.

##### Share on other sites
quote:

One potential problem I see with my ideas so far (and that would have to be considered when designing a spec) is without a certain core amount of structure the user will be paralyzed with indecision and won''t be able to get anything done.

Well, I do and don''t agree. Let me see if I can explain why I don''t think it would be a problem. First of there are languages that already one doesn''t always have expert knowledge of the underlying mechanisms for computing some results. Especially since many things are platform specific -- so already some underlying abstractin has already been built upon. So interpretted languages are mainly just abstratctions. (And some portions of non-interpretted languages are the same as well.)

This doesn''t side step the issue that the bounds of those languages are determinate. By programming one has to expect certain things to hold true in every instance -- it has to be reliable in this way. The thing to not is that how something is done and it being reliable are two seperate things. This is one of the powers of OOP, of course.

So to build on this, the only things that needs to vary are the amount of constraints built in the language. Tightenning or loosening these constraints should be within the power of the programm, obviously, but so should how they also be able to be tweeked, up or down a notch (so to speak.) This would be where the language would have to spend most of its time.

Some of this thought flows directly into fuzzy logic. And since fuzzy logic is an AI discipline, then yes the compiler and the language would have to be AI based.

Lisp, I think is the most powerful language to date. Its too bad that some other languages are in the spotlight as much as they are -- incidently one of the writers of the Java language is Guy Steele -- who is also the writer of the Lisp reference book (I forget the exact title.)

A fuzzy logic machine would be cool too, I know they have the working specifications for making them, I believe its considered experimental, and I don''t think its been explored thoroughly enough.

Alright more later,
L-

" ''No one has control -- control is just a fantasy. And being human is difficult.'' "

##### Share on other sites
Uh, terribly sorry, I didn''t proof read that before I posted and it was a rant-typing incident.

##### Share on other sites
Well, Python is not the perfect language - there is no language perfect for every usage - but it does provide a number of things you want. So does Perl so does Ruby, so does Rebol ...

• Natural language style has pretty much been ruled out from programming languages for one simple reason: ambiguity (and the difficulty of parsing it). Rebol lets you "define your own language" that way though, or so I hear. Though, in most languages, cull P''s backfaces is usually spelt cull(P.backfaces). Or something similar. The ''dot'' is your ''possessive''.

• OOP - yes, Python''s got that. Plus, it''s dynamically typed (like Perl, SmallTalk, Objective-C ...). Which means that types are not part of your function prototypes. If a function does ''a+b'', it will use whatever + operator is available to the actual type of objects ''a'' and ''b'', or throw an exception if there are no such operator. Basically, dynamic-typing = run-time templates.
Furthermore, classes themselves are objects that have a type (metaclasses) and can be modified (add/remove/modify methods at run-time).

• Structural/procedural: Yes.

• Functional: not fully, but you do have lambdas, higher-order functions, and a number of functional style operations (map, reduce, filter). Closures are available in some form. No built-in currying, though it''s been implemented as a 3rd party library module (that works transparently).

• Escape characters: Prefix a string with an ''r'', as in r"This is a string", and escape characters will be ignored.

• Regular expressions: Python has a standard regular expression modules. Regexes are also built into Perl (that''s what it''s famous for) and Ruby.

• GUI tools: Tk bindings are bundled. More GUI toolkits exist.

• Standard abstract data types: floats, arbitrary-length integers, strings, dynamic arrays and hash tables. That covers a lot. And again, remember, types are modifiable objects too.

• indention to keep code readable: Python''s block structure is defined by indentation.
for x in ["foo","bar","baz"]:    print xprint "done"

''print x'' is indented - it''s part of the loop.
''print "done"'' is neither.

That feature has most Python detractors up in arms. Python users love it

• importing language features: as they are introduced, new features require a from __future__ import feature statement. After a few versions, when the feature has stabilized, that is no longer required. Think of it as ''inverse deprecation''.

• High-level/low-level: You can write python extension modules in C (or Java if you''re using Jython) if you want. They will be treated exactly as if they had been written in Python. Jython has the added benefit of letting you use Java classes directly, and conversly, Java can use Jython classes (Jython compiles to Java bytecode).
In particular, I use the numarray module which lets you manipulate multidimensional arrays in a simple manner. It is written in C, for speed.

• Compiling to executable: No, python compiles to bytecode. The psyco module will let you do JIT-compilation, though to what extent, I don''t know exactly.

• void returns: A function that does not return a value will implicitely return None.

• for-loops/while-loops ... being kludgy: There has been a paper, quite a while ago, that described all those in terms of one universal control statement (I can''t remember the author). Traditional control statements are good for readability. Python does provide generators though, that will let you do quite nifty things with iteration.

• recurse directory search method: Yes, it''s in the library

Python is not perfect, but (and I quote) "It fits your brain."
Link: The Zen Of Python (design principles) - or type import this in any python interpreter

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan (C programming language co-inventor)

##### Share on other sites
THe most repetetive code typically happens where you need to marshal/demarshal to/from subsystems that are not at the same level as your language. For example, going between SQL tables and C++ objects. A language feature that let you define your SQL schema and C++ management code all in one would be swell. Meanwhile, I use perl to generate both the schema and the C++ code based on a template file.

When it''s just C++ based code that''s repetetive, there''s usually a template that will solve that problem. The only cases you can''t do that is when reflection and introspection are necessary; getting the names of enum items and strings and suchlike. Again, when going between the level of the language to another (binary -> string).

##### Share on other sites
* Optimized Variants:
This would let me(because I''m lazy), remove the need to think about what intrinsic data types i''m using. The compile will be able to look at how the variables are being manipulated and consider the best data type for me to use, leaving it as a variant if the need arises. If, however, I choose to specify a data type, it won''t moan at me, additionally, all data types available are those standard between all SQL versions.

* To make scripting easier, variables and functions can be queried by strings entered at run-time. This way scripts can be loaded and executed, interacting with data and functions in the compiled code, without the need for messy glue code, which can sometimes become unsynchronised with the actual code should parameters change, etc.

* No need for function definitions, this goes for DLL importing aswell. So theres no need for long include files listing all the functions the dll contains.

* TCP remote debugging support built into the debug builds of the application. Would be great for debugging on peoples machines the other side of the world.(ok there might be some privacy problems here, possibly).

* No need for end of line markers, instead, use markers like visual basic 5 and 6 did, with a _ symbol at the end of the line to let the compiler know the line extends. Because, more often than not, most commands only span 1 line.

* One forward slash for a comment line(I know this is picky ), but theres no real need for two.

* Use of either ",'' or  for enclosing strings.

* Can cross compile between big endian and little endian, adjusting all bit operations made.

* Build in standard templates for linked lists, queues, stacks, b-trees, n-trees, matrices, hash-tables, etc.

* Assuming compilation to byte code, the interpreter can deduce what CPU features are available, SSE2, 3DNow, MMX, etcetc. And optimize operations on the built in standard templates.

.. and no case sensitivity

[[ Pancake Meat ]]
What bothers ME about programming languages are the "minor" stupidities, like:

In C/C++, the pointer-declaration operator (*) is identical to the pointer-dereferencing operator, and not the address-of operator (&). The fact that int *p = *x doesn''t do what it LOOKS like it should is probably the cause of a great deal of coding errors. (And don''t get me started on digraphs and trigraphs.)

##### Share on other sites
quote:

Original post by Lucidquiet
Lisp, I think is the most powerful language to date. Its too bad that some other languages are in the spotlight as much as they are -- incidently one of the writers of the Java language is Guy Steele -- who is also the writer of the Lisp reference book (I forget the exact title.)

Interestingly, Lisp is always brought up in this context (myself I agree with the point). The thing that I have with Lisp is the *lack* of structure (YMMV of course). Although I usually try to bring OCaml up in these kind of posts (and it's a good antedote to Python anyway ;P), lets go (following Fruny):

• OOP: Yup, classes and class types. Method invocation syntax: object#method parm1 parm2 etc

• Structural/procedural: yep (depends on definition of structural, but it's not too hard to argue the case).

• Functional: yep

• Escape chars: not sure I quite see the problem, but standard C style escapes. Escape chars exist for a reason: to represent values which are not present (or undesirable) in the character set valid for the language alphabet.

• GUI tools: my biggest problem with OCaml. Although development of windowing toolkits and bindings for existing ones like Win32(!), GTK, Tk etc. is fairly straightforward (and exist), I just feel sure a more elegant system could be developed.

• Indentation:

Here lies my rub with Python (as Fruny points out ), I really don't think whitespace should play a role in semantics. Usually an OCaml program will be indented in a fairly obvious way:

let ext_trapzd accuracy f a b =  let n = int_of_float ((b -. a) /. accuracy) in  let rec integrate i total x =    match i with      0 -> total    | _ -> integrate (i-1) (total +. (f x)) (x +. accuracy)  in  let mid = integrate (n-1) 0.0 (a +. accuracy) in  accuracy *. ((0.5 *. (f a)) +. mid +. (0.5 *. (f b)))   

But that is in no way demanded by the spec.

• Importing features: a slight problem with OCaml, it has been that previous versions have been somewhat incompatible due to it being a fairly experimental language. For several years now though you can write programs in the core language and be sure they will work ok.

Extensions come in a variety of forms, often available first in the standard macro preprocessor (and no, this is nothing like cpp )

• High-level/low-level: You can happily write C modules that interact very well with the type system (through abstract types). You just need to write a module interface and supply it and the C file to the same compiler you use for the usual source files.

• Compiling to executable: one of OCamls strengths.

• void returns: use type unit, which has value (). (I think slightly irrelevant to this language, not sure what Lucidquiet was driving at)

• For loops etc.: procedural concepts like this are available, but recursion is often preferred. Often times for... loops etc. do improve readability and personally I think that any construct that improves readability (and hopefully thus maintainability) is a good thing.

• Recurse directory: Library, even if the search is not built-in it is likely a fairly simple implementation (will look into it if questioned )

But again, OCaml is not the perfect language. In my opinion the language should reflect the problem (another reason that Lisp is usually a good solution if you get along with it ) and without a stated problem, the question of a 'perfect' language is essentially meaningless.

As for the OPs question, I find it hard to say what I'd like in a language. If you asked in some context then I might have an answer, e.g. for (offline) rendering I'd say a nice set of features would be a full 2D/3D vector system built in, with SSE/2/MMX/3DNow optimizations where available, although even then the benefit is debatable. For games (and after all this is GameDev ), I think dynamic typing with reflection definitely has quite a lot of benefits, and a system which could abstract away the reference problem (i.e. an object referring to another that might be removed next tick) would be nice. Soluble in all languages but sometimes a little strained.

[edited by - JuNC on February 6, 2004 10:00:54 PM]

##### Share on other sites
quote:
As for the OPs question, I find it hard to say what I'd like in a language. If you asked in some context then I might have an answer, e.g. for (offline) rendering I'd say a nice set of features would be a full 2D/3D vector system built in, with SSE/2/MMX/3DNow optimizations where available, although even then the benefit is debatable. For games (and after all this is GameDev ), I think dynamic typing with reflection definitely has quite a lot of benefits, and a system which could abstract away the reference problem (i.e. an object referring to another that might be removed next tick) would be nice. Soluble in all languages but sometimes a little strained.

Well yes, part of the focus here would be on game development. Ideally there would a be a set of standard libraries (or modules, or whatever) that would automate a ton of code structures that game programmers find themselves rewriting all the time. To the programmer, they would appear to be built in. Just off the cuff, I'd want:

- Complete vector manipulation in 2D and 3D with all the vector math you could possibly want.  All of it!  Ha ha ha ha!  ... sorry.  - A render loop construct that boils down to a message-pipe that you can wrap around your game code.- More elegant handling of ingame logic (rules); don't ask me how.  This item is vague right now to me too and I haven't thought about it more than this one-liner.  Sorry.  - Object collision detection.- Physics- Rendering, both 2D and 3D.- AI algos, etc. including:     . Path-finding     . Fuzzy logic     . Neural nets     . ...whatever else fills the AI board day in and day out - Audio handling at a high level including dynamic audio processing, meaning:     . dynamically render to a wave device and play it     . dynamically alter said wave sound- File I/O painlessly- ODBC painlessly with inline integration with SQL- Input from the player- Isometric issues- 2D tile game issues- etc...   

I would expect different libraries for different game genres.

So games would be exceptionally awesome. Of course it's not the only coding I do and I don't really see any reason to stop with games. That's why I left it open. But I think that it should be taylored to game creation.

Meanwhile keep 'em coming while I do some research on Phython, Lisp, OCaml, Rodent (Rodel? ), etc.

[edited by - bob_the_third on February 6, 2004 10:30:31 PM]

[edited by - bob_the_third on February 6, 2004 11:46:00 PM]

##### Share on other sites
Well, here''s an expression I''d like to be able to use for a start:

(1 <= x <= 10)

I know this is actually meaningful in C, but I''d like it to mean the intuitive ''(1 <= x) and (x <= 10)''. This is a trivial point, yes, but it would make me happy.

Not having to declare things and muck about with header files all the time would be a great benefit. It just isn''t necessary.

Other than that, I''d say the most important thing to work on getting right is the way you express and work with data structures. There are lots of nice things you can do with arrays / sets / lists too, like:

if (forall x in (some_array) (x > 0)) then ...
if (exists x in (some_array) (x > 0)) then ...
foreach x in (some_array) {if x != NULL then delete x;}

and so on.

good luck!

##### Share on other sites
The perfect language is Esperanto. Elektu Google-n kiel vian hejmpa&#285;on!

##### Share on other sites
The perfect language would be one with only one command:

MakeTheGameIAmThinkingOf;

##### Share on other sites
g: I like your suggestions, especially the stuff on arrays and iterating through them logically. Cool. I agree that this kind of thing would be awesome.

AP: k.

To everyone. I've been playing around with some natural language coding (meaning I've been writing some sample programs) and have persuaded myself that you can definitely go too far with natural language in programming and bog down the programmer with a bunch of superfluous junk. An example, you say? Okay, here goes (if you didn't say, here it comes anyway...):

This is the very first game written in the currently non-existant language! (Just kidding. First off it has no input; second...well there isn't a second. Dang.)
FILENAME:  game_1.bobCOMMENT:  This is a simple sample program showing the most basic of game loops; well really it doesn’t get player input, so it can’t exactly be a game loop, now can it?  Oh well.COMMENT:  Notice no import statements; that’s because the compiler does all importation for you behind the scenes.  Now that doesn’t mean that it would do code completion for you; it will.  You just don’t have to know the right library to import.  They should be indexed in a database for quick intelligent searches.begin render loop	clear screen				//We won’t have to define this.	move all sprites 			//Nope, since sprite is built in.	handle collisions			//Definitely have to.	render all sprites			//We probably won’t HAVE to define this.end render loopbegin “clear screen” definition	draw a rectangle from (0,0) to (screen width, screen height) in color blackend “clear screen” definitionbegin “move” definition	it expects a set of sprites called “sprite set”		for every sprite S in sprite set,		increment S position by S velocityend “move” definitionbegin “handle collisions” definition	it expects a set of sprites called “sprite set”	for every sprite A in sprite set and every sprite B in sprite set,		if A and B aren’t the same sprite,		and if A and B collide, then 			notify A and B of the collisionend “handle collisions” definitionbegin “render” definition	it expects a set of sprites called “sprite set”	for every sprite S in sprite set, draw Send “render” definitionbegin “sprite” object definition	has “position” vector (x,y)	has “velocity” vectory (vx,vy)		NOTE:  In real life, this will probably be implemented at the system level in C!	begin “draw” definition		...	end “draw” definitionend “sprite definition`

Among other things, the keyword "definition" while nice from a reading standpoint contributes to carpal tunnel syndrome.

Thus I favor an opt-in system, meaning let the programmer get as verbose or as cryptic as they want, on the fly. We, the compiler should be ready to handle either.

For the verbose we must give them a pretty darn good idea of the way our language parser works and how it will react to their attempts at NL. For the laconic, well C/C++ style languages are pretty easy to learn and define.

Other things I'd like to see:

- Collections of data are differentiated at time of use by default (unless otherwise specified). So you can use a stack-heap-tree-LL-array if you want, darn it!
- Automatic in-line support for set manipulation.
- Allows implicit variable declaration (but allows it to be turned off!) but flags cases with warnings so the user can't do it by accident!
- Allows inline C code and probably SQL (and any others that can be compiled down to C code through any and various tricks).
- Allows (but ignores) junk glue words like "the," "a," etc.

In fact I think a programmer should be able to program kind of like they talk if they want. So they should be able to say, "Let's draw all the polygons in the scene." Okay I'm kidding about the last one unless it turns out to be feasible which I doubt.

More? This brainstorming session is pretty cool.

[edited by - bob_the_third on February 6, 2004 11:44:38 PM]

##### Share on other sites
The only reason I don''t like python''s scoping is the fact that I had major problems with it not being able to figure out spaces vs tabs. one solution is to use spaces, but then it can be a little more tedious to move around in the code. that and pray your versioning diff program can show whitespace somehow

##### Share on other sites
Really, what benefit does programming in natural language provide? The fact that we can use Word as our IDE? I am being pragmatic here. There is a certain beauty and elegance in expressing ideas in a few words.

I think the "programs as stories" thing has been tried before in COBOL I believe.

##### Share on other sites
Yes. And COBOL is nasty, nasty stuff. So to be honest you''re probably right. However I guess the only thing that has me thinking it might be cool, at least to SOME degree is that it could reduce the need to comment your code.

When I''m coding complex algorithms, I almost always start out with some form of pseudo-code that''s a mix of English, C, VB, Math, whatever pops into my head.

I use English because it''s easier to clearly express ideas to make sure my thinking is right and I haven''t made mistakes. I use C/VBMath syntax because I get tired of typing/writing a whole bunch of stuff.

Bottom line, sometimes English is more elegant, sometimes C is more elegant, sometimes pure Math notation is more elegant. Why not be able to choose? But no I don''t want to create another COBOL. Heck I don''t like to type a bunch of stuff. There''s definitely a balance.

##### Share on other sites
Here you go. Enjoy it if you''re interested.

##### Share on other sites
Here's an interesting challenge that I'll issue. Conceptualize a very simple game, let's say "Space Invaders." Now, without writing or even THINKING about writing code in any computer language, write out full pseudo-code. You do not need to define how to draw a sprite to the screen, or how to perform basic vector math. Then post your pseudo-code here (in source tags so it doesn't take up tons of space). I'd like to see how game programmers think. Maybe we can get some ideas on the ideal game programming language from this.

If you don't want to do "Space Invaders," do whatever fits your fancy, just as long as it's a basic game of some sort (though keep it reasonably small; no QuakeIII! ).

Note: If you read the challenge and thought "no way! That's work!" then feel free to keep replying here with your thought on the ideal language anyway.

[edited by - bob_the_third on February 7, 2004 5:02:08 PM]

• 10
• 11
• 9
• 11
• 9