The Ultimate Programming Language!

[Banana fanna fo fanna]

Python! No, seriously now, what do you think would comprise the ultimate programming language? I think:

- optional garbage collection which is on by default
- as native as C (none of this VM shit)
- modern language features like packages
- operator overloading with a slew of new operators (like slicing)
- continuations and other LISPy things
- concise, less-typing syntax
- macros
- __maybe__ an intermediate code which can be compiled to native code on various OS's once to generate executabels

I'm asking this because I'm going to write another compiler this semester.

[tA-Kane]

Disassemblers are more fun to write, let alone a heck of a lot easier, I think.

If you're just writing a compiler, could you not use a language that already exists? Like, write another C compiler?

[iago]

- concise, less-typing syntax
- macros

Those tend to lead to horrible lazy code.  Macros are the root of many evils, and many hard-to-find problems.  As an example:

#define MAX(a,b) (a<b?b:a)

.......
int c = 4, d = 10;
c = MAX(c++, --d);

Because of the macro expansion, that will expand to:
c = (c++<--d?--d:c++)
Which will, of course, return 8 (because --d is run twice), which is a completely unexpected result.

Anyway, that's my argument against Macros.  Take it how you like

[Arta]

There's nothing wrong with a thoughtful, well-written macro. That macro is stupid. It ought to be a function.

People rail on about macros being bad, but I think that's crap. Macros are an incredibly useful tool. Like anything, they can cause problems when they're misused.

[Adron]

"garbage collection" and "native" don't go together...

[Kp]

Actually, you can make a native program which has a garbage collector.  It's just not necessarily going to run as fast as a GC-free language, since the compiler will need to convert all references to complex types into extra record-keeping code to ensure that the reference count is right so it can be garbage collected on schedule.

[Adron]

But as native as C? You're supposed to be able to cast between numbers and strings and pointers freely, with no type checking, and insert assembler code virtually arbitrarily....

[iago]

There's nothing wrong with a thoughtful, well-written macro. That macro is stupid. It ought to be a function.

People rail on about macros being bad, but I think that's crap. Macros are an incredibly useful tool. Like anything, they can cause problems when they're misused.

So any macro that uses a variable more than once is "stupid"?  Any macro that uses a variable more than once will succumb to that problem, unless the programmers using the macro are aware that it's a macro and that it might have that effect.

[Kp]

But as native as C? You're supposed to be able to cast between numbers and strings and pointers freely, with no type checking, and insert assembler code virtually arbitrarily....

I see your point.  From his statement of "as native as C (none of this VM shit)", I took it merely to mean that he wanted processor-native code, as opposed to interpreted bytecode.  It would complexify the language a bit (and introduce extra work for programmers who wanted to do casting), but I still think he could make a machine-native garbage collector.  It'd merely require a convention such as "You must keep a visible reference to an object or it'll go away, even if your inlined assembly still knows about it" for garbage-collected objects.  He already specified that garbage collection would be optional, so arbitrarily crafted pointers would be declared as not-garbage-collected.

[Banana fanna fo fanna]

I was thinking something along the lines of:

Code Select Expand


class MyClass extends GarbageCollected {
   ...
}


[dxoigmn]

I was thinking something along the lines of:

Code Select Expand


class MyClass extends GarbageCollected {
   ...
}


Then you need to implement multiple inheritance which is icky.

[Adron]

But if all you're doing is create a class to inherit from to get garbage collection, you might as well use C++ and write a garbage collector for it, or use one of the existing ones

[tA-Kane]

That wouldn't be a bad idea of garbage collection wasn't a bad idea in the first place.

Nothing like keeping track of your garbage yourself...

[dxoigmn]

That wouldn't be a bad idea of garbage collection wasn't a bad idea in the first place.

Nothing like keeping track of your garbage yourself...

Garbage collection is the best.

[tA-Kane]

Btw, I think having all user variables *not* stored on the stack may be a good idea for a language... especially not arrays...