Perfect language

A perfect language would be both imperative and nonimperative. It would be both functional and procedural. It would be interpreted, bytecode-compiled, and native compiled. It would place ease of use over execution efficiency, execution efficiency over ease of use, and sacrifice everything for hard-realtime capabilities.

In short, it would be several different languages.

---

"Sneftel is correct, if rather vulgar." --Flarelocke

quote:

---

Original post by Sneftel
A perfect language would be both imperative and nonimperative. It would be both functional and procedural. It would be interpreted, bytecode-compiled, and native compiled. It would place ease of use over execution efficiency, execution efficiency over ease of use, and sacrifice everything for hard-realtime capabilities.

---

lol, apart from the hard-realtime guarantees you've almost exactly described OCaml

[edited by - JuNC on January 19, 2004 12:41:50 PM]

quote:

---

Original post by OrigamiMan64
what features do you think would create the perfect language for game programming? I personally feel that if the Java features of interfaces and properties were added to C++, it would be near perfect... but are there any other powerful features C++ lacks?

---

Build in thread library, GUI/other graphic programming functions, proper strings, lazy synchronization, multiplatform capability WORA type, possibility of functional programming, reasonable STD library/commonly used objects, gate joining, error handling (without blasting out OS), proper excepions, multipass compiler, namespace without clashes, proper library handling, multiple entry points, ability to use MASM like syntax, compilers fully compatibile with standard on all main platform without quirks, proper documentation, and less silly tutorials.
/you might add optional garbage collecting as part of main library/

It has on other hand something more than it should have: preprocessor, two source files (.cpp .h), compiler that is hard to use without makefiles, or IDE.

Of course you can have both procedural and functional language. And language with compiler both to byte, or MSIL code, and to native code depends on OS/processor specification. It's just that nobody would throw at something like that enough money to get it working without quirks.



[edited by - Raghar on January 19, 2004 12:50:37 PM]

quote:

---

Original post by Raghar

quote:

---

Original post by OrigamiMan64
what features do you think would create the perfect language for game programming? I personally feel that if the Java features of interfaces and properties were added to C++, it would be near perfect... but are there any other powerful features C++ lacks?

---

Build in thread library, GUI/other graphic programming functions, proper strings, lazy synchronization, multiplatform capability WORA type, possibility of functional programming, reasonable STD library/commonly used objects, gate joining, error handling (without blasting out OS), proper excepions, multipass compiler, namespace without clashes, proper library handling, multiple entry points, ability to use MASM like syntax, compilers fully compatibile with standard on all main platform without quirks, proper documentation, and less silly tutorials.
/you might add optional garbage collecting as part of main library/

It has on other hand something more than it should have: preprocessor, two source files (.cpp .h), compiler that is hard to use without makefiles, or IDE.

Of course you can have both procedural and functional language. And language with compiler both to byte, or MSIL code, and to native code depends on OS/processor specification. It''s just that nobody would throw at something like that enough money to get it working without quirks.



[edited by - Raghar on January 19, 2004 12:50:37 PM]

---

Apart from the silly tutorials part, you just described brainfuck.

J/k

And where is multiplication, and threading?
I could live without EMMS, but without mul and div? NaN +-0. That language was severaly lacking

You kids today and your new-fangled words. When I was your age, we put in ONES AND ZEROES and we LIKED it!

quote:

---

Original post by Sneftel
A perfect language would be both imperative and nonimperative. It would be both functional and procedural. It would be interpreted, bytecode-compiled, and native compiled. It would place ease of use over execution efficiency, execution efficiency over ease of use, and sacrifice everything for hard-realtime capabilities.

In short, it would be several different languages.

---

"Sneftel is correct, if rather vulgar." --Flarelocke

---

Ah, Common Lisp.


CoV

quote:

---

Original post by Mayrel
Ah, Common Lisp.

---

Oh god, not another One True Language zealot. Quick tip: Lisp is utterly unreadable by anyone who doesn''t know Lisp.

---

"Sneftel is correct, if rather vulgar." --Flarelocke

Not really. I picked up the basic idea of Lisp in about 10 seconds after seeing some source. It took some getting used to to actually write it in of course, but only because I'm used to C. If you can't figure out what Lisp code does by looking at it, its because you don't know the functions. You couldn't read much C code either without knowing many things about the language. I find Lisps unified syntax easier to understand than the rather complex syntax of C/C++/etc.

I don't think Common Lisp is the ultimate language though, because it is missing quite a few simple things (like passing by reference or pointer). It is a good language, definitely, but not a universal language. The "C++ -> C#" thing(keeping the same ideas and basic syntax, but dropping compatability to {arguably} improve the language) needs to happen to Common Lisp IMO.

[edited by - extrarius on January 19, 2004 6:00:06 PM]

quote:

---

Original post by OrigamiMan64
what features do you think would create the perfect language for game programming? I personally feel that if the Java features of interfaces and properties were added to C++, it would be near perfect... but are there any other powerful features C++ lacks?

---

Dynamic multiple dispatch

In standard C++, the following code outputs "Foo".

[sample]
struct Foo;
struct Bar: Foo;
void MyClass::doIt (Foo *foo) { printf("Foo"); }
void MyClass::doIt (Bar *bar) { printf("Bar"); }
int main ()
{
Foo *o = new Bar();
MyClass::doIt(o);
}
[/sample]

With dynamic multiple dispatch, it would output "Bar".

Events

Garbage Collection

States

Making state-based objects is quite possible in C++, but has its issues. One is that there''s no easy way to ensure that every function can cope with every state. The other is that one must use a switch or several ifs to choose between each state.

If each state of a class were represented by a vtable, then the overhead of switching between states would never be higher than the overhead for virtual function calls.

A simple example a string class that might be a complete string or a substring.

[sample]
struct String
{
state char &operator[] (int index) {
if (index > 0 && index < length)
return data[index];
throw "Out of bounds";
};
state char &operator[] (int index) {
if (index > 0 && index + offset < length)
return data[index + offset];
throw "Out of bounds";
};
int length, offset;
char *data;
};
[/sample]

In this case, the use of states is not a significant advantage: if offset was zero, the SUBSTRING version of the function would work just the same as the COMPLETE version. However, there are other situations where a class may need to perform quite distinct operations depending upon its state.

CoV

C++ is also missing first-class functions, metatypes, closures, and powerful macros (simple text replacing as done by the C++ preprocessor isn''t nearly as useful as say Lisp macros).

quote:

---

Original post by Extrarius
Not really. I picked up the basic idea of Lisp in about 10 seconds after seeing some source. It took some getting used to to actually write it in of course, but only because I'm used to C. If you can't figure out what Lisp code does by looking at it, its because you don't know the functions. You couldn't read much C code either without knowing many things about the language. I find Lisps unified syntax easier to understand than the rather complex syntax of C/C++/etc.

I don't think Common Lisp is the ultimate language though, because it is missing quite a few simple things (like passing by reference or pointer). It is a good language, definitely, but not a universal language. The "C++ -> C#" thing(keeping the same ideas and basic syntax, but dropping compatability to {arguably} improve the language) needs to happen to Common Lisp IMO.

[edited by - extrarius on January 19, 2004 6:00:06 PM]

---

My personal issue with CL is the lack of 'immediate' data types.

For example, in C++, a vertex structure containing a 3-vector position and normal and 2-vector texture coordinate would be a sequence of 8 floats.

struct vertex {
  float position[3];
  float normal[3];
  float texCoord[2];
};
 

In CL, it might be a sequence of three pointers to vectors, which themselves contain references to their types, their length, and their contents, which may be pointers to similarly self-describing floats. I say 'might' and 'may' because the standard allows an implementation to make the structure just as efficient as in C++.

(deftype vec-float-3 () (vector 3 float))
(deftype vec-float-2 () (vector 2 float))
(defstruct vertex
 (position :type vec-float-3)
 (normal :type vec-float-3)
 (texture-coord :type vec-float-2)
 )
 

Note that, in CL, struct member types may only be symbols: to contain a complex type, you must first declare a name for it. In this respect, it is similar to Pascal.

Also of concern is the lack of lvalues. Whilst in C++ any function that returns a reference can be used for an lvalue, in CL you must write distinct functions for getting a value and for setting a settable value:

C++:
int & getSomeInt () { return someInt; }
printf("%i\n", getSomeInt());
getSomeInt() = 12;
printf("%i\n", getSomeInt());

Common Lisp:
(defun getSomeInt () someInt)
(defun (setf getSomeInt) (v) (setf someInt v))
(print (getSomeInt))
(setf (getSomeInt) 12)
(print (getSomeInt))
 

CoV

[edited by - Mayrel on January 19, 2004 7:35:26 PM]

quote:

---

Original post by Extrarius
C++ is also missing first-class functions, metatypes, closures, and powerful macros (simple text replacing as done by the C++ preprocessor isn't nearly as useful as say Lisp macros).

---

The fact that non-member functions, member functions and functors lack a common supertype is inconvenient. The complete lack of bound member functions is a bizarre omission.

Take the following:

struct {
  int operator() (void *, void *);
} cmp_functor;
struct {
  int cmp_bound(void *, void *);
} object;
int cmp_function(void *, void *);
  

In C++, one can do

qsort(list, sizeof *list, list_len, cmp_function);
  

It would be good to also be able to do:

qsort(list, sizeof *list, list_len, cmp_functor);
qsort(list, sizeof *list, list_len, object.cmp_bound);
  

Whilst one could do the first by overloading the qsort definition, one simply cannot do the second without changing the syntax of qsort: a bound function is not an object.

The lack of reflection is also quite silly. Types are available as objects, but there's no way to compare two types to check if one is a subtype of the other, to get a listing of the members of a type, or to construct new instances of a typeinfo type.

I don't tend to find the lack of closures an issue, but I do use them in Lisp and I'd imagine I'd use them if they were available in C++.

The thing about Lisp-style macros is that they're relatively easy to define and implement. I don't think the same would be true for C++ macros.

Macro-like functions could easily be introduced, to allow for arguments that may, or may not, be evaluated.

template<typename T>
T iif(bool test, lazy T if_true, lazy T if_false) {
  return test ? if_true : if_false;
}
  

In this example, lazy arguments would be pointers to closures which would be evaluated when their values were needed -- in this case the value is needed to cast a lazy T to a T in the return statement.

However, I don't think that syntactical macros would be easy, particularly given C++'s already twisted syntax.

CoV

[edited by - Mayrel on January 19, 2004 8:07:34 PM]

quote:

---

Original post by OrigamiMan64
*snip*
I personally feel that if the Java features of interfaces

---

C++ already has this, they''re called virtual classes. The designer of C++ correctly applied Occam''s razor to realize that there is no distinction between a class with abstract members and an ''interface''. Java shouldn''t have interfaces, it should just use abstract classes, since that''s what interfaces are.

quote:

---

and properties

---

Java has properties? Aren''t you thinking of C#?

quote:

---

were added to C++, it would be near perfect... but are there any other powerful features C++ lacks?

---

CoV

Everyone who said there is no one perfect language is absolutely correct.

Haskell is one of the better ones for what it does, though. Very clean and consistent. But it can be slow, somewhat bloated, and difficult to handle some tasks. Every langauge has advantages and disadvantages, and what works well in some situation may be completely rediculous to try in another. Right tool for the job.

The following statement is true. The previous statement is false.
Shameless promotion:
FreePop: The GPL Populous II clone.

Assembly is the perfect language. Because it''s the fastest.

(yes, I''m being facetious)

"Without deviation, progress itself is impossible." -- Frank Zappa

quote:

---

Original post by Doc
Everyone who said there is no one perfect language is absolutely correct.

Haskell is one of the better ones for what it does, though. Very clean and consistent. But it can be slow, somewhat bloated, and difficult to handle some tasks. Every langauge has advantages and disadvantages, and what works well in some situation may be completely rediculous to try in another. Right tool for the job.

---

My personal gripe with Haskell is that you can''t have a vector containing different types of objects. [ "a", 12 ], for example, isn''t valid.

quote:

---

The following statement is true. The previous statement is false.
Shameless promotion:
FreePop: The GPL Populous II clone.

---

CoV

quote:

---

Original post by Mayrel
My personal gripe with Haskell is that you can''t have a vector containing different types of objects. [ "a", 12 ], for example, isn''t valid.

---

Depending on your needs, there are solutions. For instance, the Prelude contains the Either type, so in your example, you could have something like

> eitherList :: Num n => [Either String n]
> eitherList = [Left "a", Right 12]
 

You could easily generalize this to more than 2 types with your own data type. Or, maybe something with tuples

> tupleList :: Num n => [(String, n)]
> tupleList = [("a", 12)]
>
> listTuple :: Num n => ([String], [n])
> listTuple = (["a"], [12])
 

A common problem is combining instances of a class into one list. You can use a common extension called existential types (which I haven''t played with yet, but might even be a more elegant solution), or, with standard Haskell 98, create a general object, for instance

> class SomeThing s where
>   foo :: s -> IO ()
>   bar :: s -> Float -> s
>
> data SOMETHING = SOMETHING (IO ()) (Float -> SOMETHING)
> instance SomeThing SOMETHING where
>   foo (SOMETHING f _) = f
>   bar (SOMETHING _ b) = b
>
> packSomeThing :: SomeThing s => s -> SOMETHING
> packSomeThing s = SOMETHING (foo s) (\f -> packSomething $ bar s)
 

Or, as I was commonly told when I came to problems in C++, maybe you need to rethink the problem.

As a little disclaimer, this wasn''t to convince anyone to use Haskell, let alone that Haskell is the greatest language. More like admitting that every language has issues, and its users have means of handling those issues. I guess I like mixing languages, because often I see a good solution for one part in Haskell, a good solution for another part in C, and then use both (it helps that I find Haskell''s FFI fairly clean). In short, I guess I agree with Sneftel.

The perfect language would allow the programmer to do all things with no effort (like one command,
eg: makewebbrower


Humans are Human oriented, it is because of there nature: a design flaw-greed, jelosy the solution: AI- never greedy, and they stick to there ethics no matter what.