Archived

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

Khaos

Feedback on: a perfect programming language

Recommended Posts

I think it would be interesting to hold a discussion on an optimal programming language. I am using the term "perfect" loosely in this case. Essentially: what constructs, instructions, data types and uses, programming paradigms, syntax, et cetera; would best be seen in a programming language, if you [we] were to design our own? For a formal discussion it would be nice to get more than four replies, so I hope this is effective enough. To keep things organized:
    * Using /source or /code tags, highlight key features, or general syntax of a language you have in mind.
    * Reply to what others' have posted, discussing the pros and cons of what they included in the discussion.
      If you truly like someone's concepts, make it known, to bring their feature into a more noted state.
    * Don't forget the simple stuff. Discussing super advanced metamorphical templated
      vector monoliths does not have to be your only point.
      There are looping constructs and text display and variable allocation and memory
      managing and very basic syntax to think about too.
    * Possibly one could discuss compiler features, libraries, and other subcategories of such a language.
   
And so on. Please comment on what other people say as well. Thus, we can really get down to what is good and what is not good in a programming language of our design. This should be fun and interesting. Please don't be shy to get a good forum discussion going of more than a few replies, that actually has anything to do with the computer world. So, if you were to design a language, how would we do it? [edited by - khaos on October 22, 2003 7:23:53 AM]

Share this post


Link to post
Share on other sites
Multiple paradigm support (imperative/OO/functional)
Strongly typed
A good IDE (don''t underestimate this one)
Optional reflective capabilities
Type inference
Lets you make every decision concerning it
Integrated, but optional garbage collector
Functions as first class objects
Small runtime
Intuitive syntax
Good library support
Namespaces/packages
Discourages Hungarian notation through compiler warning (just kidding, that will get some responses)

I can post code snippets later

Share this post


Link to post
Share on other sites
Constructs

Obvious ones are for-each; switch statements that accept more than just integers and can do comparisons. Break and continue with a labelled construct (ala perl) is essential.


for (x) = (list)
doSomethingTo(x);

switch (string)
{
case < "bar":
...
case > "foo":
...
case else:
...
}


Lambda expressions, higher order functions (functions that return functions) and partial application are also dead nifty:


// Lambda && higher order functions...
template
T(T) makeAddFunctor (T a)
{
return lambda (int x) { return a+x; };
}
int(int) add_to_12 = makeAddFunctor(12);

// Partial application
int(const char*) theCmp = strcmp("hello", @0);
for (char* x) = (string_list)
{
if (!theCmp(x))
{
printf("Match found");
return;
}
}


Data types

Support for rationals would be nice, as well as complex numbers. Resizable arrays and trivial hashes.


int a[];
a.append(5);

int a[string];
a["foo"] = 69;
a["bar"] = 42;


Type inference is also nice: something which C++ partially supports via templates, but which many functional languages do automatically.

A unified type system is terribly useful. One can use ''boxing and unboxing'' to pretend that the primitive types are varieties of lang.Object.

Regular expressions are also good. Inline XML might be nifty, also:


dom.Node myDoc = <foo>text<bar>more text</bar></foo>;


Programming paradigms

Genericity is necessary. ''Nuff said.

OOP is excellent. Everything must be an object, including the classes themselves. Double dispatch is nice.

In-language support for events.

State-based programming allows a class to customize the behaviour of its functions according to the situation, with little additional overhead at call-time:


class Matrix
{
state Translation:
float[3] apply (float[3] vec)
{ /* apply simple translation */ }
state Complex:
float[3] apply (float[3] vec)
{ /* apply complex generic transformation */ }
};


Lazy evaluation and delayed evaluation are rather nifty, also.


// Lazy maybe. Evaluates its argument 50% of the time.
template
void maybe(lazy T v)
{
if (rand % 2)
v;
}

// Delayed repeat, evaluates its second argument TIMES times.
template
void repeat(int times, lazy T expr)
{
for (times)
expr;
}


Tail-recursion is highly desirable.

Garbage collection is required by standard. Options to control/disable for certain classes or during certain parts of the program.

Exolanguage wise, an IDE with debugger is essential. Tools for the language like lexer and parser generators, and documentation generators, are dead good.

Share this post


Link to post
Share on other sites
quote:
Original post by antareus
Lets you make every decision concerning it.


How do you mean?
quote:

Good library support


This could mean one of two things. Either that the language needs a good library of its own, or that it needs to be able to use other libraries without unreasonable difficulty. I agree with both.

At the very least, it should be able to use C libraries.
quote:

Namespaces/packages


Very nifty.

On the topic of namespaces, enums should be supported, and an enum have a namespace:


enum MyEnum
{
FOO, BAR, BAZ;
};


Here the elements should be MyEnum::FOO, MyEnum::BAR and MyEnum::BAZ.

Sometimes enums aren''t used in the disjoint way that is intended. Enums are often used to declare related flags that can be combined. Enums should be enforced, and a new construct provided for grouping flags:


flagset MyFlags
{
FLAG1, FLAG2, FLAG3;
}

quote:

Discourages Hungarian notation through compiler warning (just kidding, that will get some responses)


Too right.

I''ll also risk some responses of my own by saying it definately should support multiple inheritance.

Share this post


Link to post
Share on other sites
No more #pragma, nor the preprocessor! No more compiler dependency - ie - no more porting code from one compiler to another. Thus - only one (open source) compiler (with IDE).

Oxyd.



---
Unreadable code is code written on a piece of paper, but not the one, in which its programmer is using a space in place you don''''t.

Share this post


Link to post
Share on other sites
-C/C++/Java syntax is fine , all the classic statements + foreach
-classes,Interfaces.
-all classic Java/C# types
-built in dynamic arrays and maps(tables)
-maps can be hased with any type except null
-higher order functions
-coroutines or continuations
-variant type
-components are natively supported(not a bounch of zipped classes)
-do not allow exposing classes thrugh components, just interfaces.
-generics(safe macros ala Java 1.5)
-no garbage collection, refcounting with cycle detection (+the compiler detects runtime what really needs refcounting), in alternative some sort of efficient ''linearity''.
-autoboxing
-small runtime(around 100-200k)
-fast register based virtual machine
-a good compiler

BTW I''m gonna implement this language as soon I''m done with the current one...I''ll call it "Solid Hamster"

ciao
Alberto



-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net

Share this post


Link to post
Share on other sites
Mayrel: choices over whether GC can be used, and if it is used, choices over whether object destruction is deterministic, perhaps some subsets of the language that make it suitable for demanding roles such as hard real-time tasks or looser tasks such as AI

On the libraries, I meant both, apologies for being vague.

fagiano: you'll like C#, it has a great majority of those things you listed.

Here are some more:
* partial evaluation/currying (lets you 'build' function calls)
* pointer usage is rare, not the norm (C++ is especially guilty of this)
* passing by reference requires function caller to acknowledge that it is passing by reference:
void f(ref int i)
{
i++;
}

// some function
f(ref i)

* embedded documentation generation that doesn't rely on ugly tokens in comments
* MI support
* More than double dispatch...multiple dispatch (proposal for C++ to support this thru n-dimensional jump tables)
* closures (construct an entire function call with args and call it at a later time (ties in with what I said earlier but its still important, I think Delphi has them)

What I get from the gist of all the comments is *some* sort of runtime system is needed. C++ is pretty close to as far as we can go with simply letting the compiler do the dirty work for us. But a tiny runtime would probably be more beneficial than not with all these language capabilities.

[edited by - antareus on October 22, 2003 2:03:01 PM]

Share this post


Link to post
Share on other sites
I think a good starting point would be a language as versatile as Lisp. While it is a good language, I think it could be made somewhat better by adding in support for lower level programming (things like pointers etc). Most people that know Lisp know that is a good language for many purposes, but it can''t do everything well yet(things like writing a driver - why be forced to choose abstraction OR hardware access?).

"You are my friends if you do what I command you."
[edited by - Big Brother on January 1, 1984 12:00:00 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Extrarius
I think a good starting point would be a language as versatile as Lisp. While it is a good language, I think it could be made somewhat better by adding in support for lower level programming (things like pointers etc). Most people that know Lisp know that is a good language for many purposes, but it can''t do everything well yet(things like writing a driver - why be forced to choose abstraction OR hardware access?).



scheme! scheme! scheme!

...Anyway.

The major issue I have with LISP-esque languages is the syntax. Genius as it may be, I find that the proliferation of parantheses makes it difficult to discern structure. I''d recommend following Dylan''s example and transforming an easier-to-read syntax into an underlying LISP format.

antareus:

Hmm, my understanding was that ''double dispatch'' was the official term for anything that wasn''t single dispatch. I always call it ''multiple dispatch'' in my head, and usually correct it as it comes out.

For my toy language, I have documentation embedded as XML as so:


import std.io.*;

@<fun name="main" type="int">
<arg name="args" type="char[][]" text="Arguments"/>
This program does blah, blah, blah.
</fun>
int main (char[][] args)
{
out.print(1 + @<note>This is seven, for no particular reason</note> 7);
return 0;
}


fagiano: Assuming I understand you correctly, you suggest no garbage collection or reference counting? I don''t know what "linearity" means here, could you clarify?

Share this post


Link to post
Share on other sites
Rather than LISP, start off with python...

Warning : the following is an advertisement for Python

  • Multiple paradigm support (imperative/OO/functional) yep
  • Strongly typed hmm, no, it does have some implicit conversions.
  • A good IDE (don't underestimate this one) well, it *does* have IDEs.
  • Optional reflective capabilities it's built-in
  • Type inference dynamic typing, baby!
  • Lets you make every decision concerning it metaclasses !
  • Integrated, but optional garbage collector gc.disable()
  • Functions as first class objects *everything* is an object
  • Small runtime well, it's smaller than java
  • Intuitive syntax check ! (try it before you bash it)
  • Good library support check - excellent standard lib
  • Namespaces/packages check
  • foreach check
  • case nope, use if/elif/else
  • lambda check
  • partial application/currying not built-in, but has been done - transparently
  • rationals nope
  • complex check
  • dynamic arrays built-in
  • hash check - that's arguably Python's core type; every nonmutable type (for obvious reasons) can be used as a hash key
  • unified type system check - everything is an object
  • type inference dynamic typing
  • regular expressions check
  • inline XML nope - there's an XML parsing lib, though
  • genericity dynamic typing
  • multiple dispatch not really
  • "state-based" programming classes are modifiabke objects
  • lazy evaluation no. generators provide 'lazy list' functionality though.
  • tail recursion no
  • use of C libraries need to write bindings, but can then be used as native python entities
  • multiple inheritance check, the method resolution order is open to introspection.
  • enums an enum metaclass exists (see Python Cookbook)
  • portable check
  • open-source check
  • coroutines/continuations yes, in the 'Stackless' implementation, otherwise, generators do the job
  • variant type dynamic typing
  • components vs. interfaces dynamic typing - adding interface testing is being discussed
  • refcounting with cycle detection check, with caveats for classes with destructors (there is no general algorithm to determine how to break a cycle and which object to delete first - the programmer must decide)
  • small runtime python23.lib is 175K - non-builtin library elements can add to that (script files - can be zipped).
  • pointers none, the C API let you muck around, though (e.g. numarray module for efficient C-style arrays).
  • references *everything* is passed by reference
  • embedded document generation yes, PyDoc relies on introspection and docstrings.
  • deterministic gc gc.collect()
  • fast VM err... well... err... not really...
  • good compiler the 'psyco' module gives you JIT compiling
  • closures yes, though a bit clunky, imho


There you go


[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]


[edited by - Fruny on October 22, 2003 4:44:01 PM]

Share this post


Link to post
Share on other sites
Part of the power of lisp is its 'ugly syntax'. If you don't write the code as lists, it becomes a LOT more difficult to have macros as powerful as Lisp macros. Think about Common-Lisp - it defines ways to change things all the way down to the parsing and all the way up to generating code, with things like modifying code at compile and runtime in between. Sure it allows for messes if you aren't careful, but I think the perfect language would be made for those that know what they are doing (otherwise you end up with something like a cross of basic and C with only the worst of both).
I do wish Lisp had a standard foreign function interface (aka ways to access libraries not made in Lisp), which is another important thing that is missing. I think there needs to be another Common Lisp revision about now. There isn't a whole lot that needs to be added/changed, but IMO the things that do are somewhat important.

[edited by - extrarius on October 22, 2003 5:06:17 PM]

Share this post


Link to post
Share on other sites
I will also note O features O''Caml has, and C features C++ has

- Strong typing (O)
- Type hints (C), like casting but as a "hint" to the compiler
- Recursive object definition (O)
- Garbage collection (O)
- Function polymorphism (O)
- Object polymorphism (O,C)
- Curryfied notation (O)
- Pattern matching (O, C++ has a little of it)
- value-ifs (O)
- Improved support for recursive solutions (O)
- clear outlining of blocks and scopes (C)
- modules (aka namespaces) (O,C)
- intuitive support for multi-file projects (C)
- easy library linking (C)
- multiple paradigm support (O)
- defining n-ary operators (with laziness) (C++ has it 50%)
- one-line commenting style (C)
- low-level memory acces, pointer-style (C)
- preimplemented casual-use constructs (O,C++ has STL)
- portable, ie the exact same code can be compiled to WIN, Linux or Mac binaries (O almost did it)
- simple, consistent, concise syntax and paradigm (NOT LIKE O''CAML)

So my perfect language would be some sort of mix between C++ and O''Caml. Now, for the IDE and compiler interface:

- intuitive suppport for multi-file projects
- debugger
- auto-complete
- ability to "close" scopes (just like you collapse directories in a tree view)
- color coding
- file map (ability to jump to one particular definition in a file)
- ability to show types (once compiled, the expected types of all objects are shown as hints on mouseover)
- an error highlights not only the line, but also the tokens where it occured
- possibility to have multiple code windows open at once (as tiled, for instance)
- fullscreen coding support

The main "new things" (ie not found in any language I know) I propose is :
*** n-ary operator definition

example:
let add_vectors (x1, y1, z1) (x2, y2, z2) = (x1+x2,y1+y2,z1+z2);;
let operator [+v] a b = add_vectors a b;;
let vector = (1,3,4)+v(-1,3,5);; <--- this equals(0,6,9)

meaning:
the "++" operator would then have the following type:
int*int*int -> int*int*int -> int*int*int

another example:
let do_something_weird a b c d = a + b - c mod d;;
let operator [al,ka,shi] a b c d = do_something_weird a b c d;;
let weird_stuff = 17 al 13 ka 5 shi 2;; <-- this equals 29

meaning:
the "al kashi" operator would then be of type
int -> int -> int -> int -> int

uses :

like this you can define more concisely operators such as *m (matrix multiply), +v (vector add), etc...

drawbacks :

since operators aren''t fixed anymore, you need spaces between operators and tokens

*** permanent equality

example:
(int) a = 5;
(int) b = 6;
(int) c == /* "always equal" */ a + b;
//here, c = 11
a <- 10
//here, c = 16
b <- -5
//here, c = 5

uses:

whenever you have "screencoords" and "worldcoords" in a 2d game, they are tied by a linear equation. since screencoords depend on worldcoords, just always-equal them.

drawbacks:

the value of always-equal variables cannot be changed (obviously)
also, the coder loses a lot of control on what is computed where.

...

Now, I could rant about this a whole lot more, but I gotta go and get some sleep, it''s getting late here...


ToohrVyk

Share this post


Link to post
Share on other sites
quote:
Original post by ToohrVyk
*** n-ary operator definition
like this you can define more concisely operators such as *m (matrix multiply), +v (vector add), etc...


This would be a pain in the arse to parse. Also, you have to deal, somehow, with order-of-precedence.

Couldn't vector add be defined as vector operator+ (const vector &, const vector &);?
quote:

*** permanent equality

example:
(int) a = 5;
(int) b = 6;
(int) c == /* "always equal" */ a + b;
//here, c = 11
a <- 10
//here, c = 16
b <- -5
//here, c = 5



This can be trivially implemented with closures:

a = 5;
b = 6;
c = [a + b];
// now, c would evaluate to 11
a = 10;
// now, c would evaluate to 16
b = -5
// now, c would evaluate to 5

quote:
Original post by Fruny
# Strongly typed hmm, no, it does have some implicit conversions.


Not really good enough. Without strong typing, you don't get multiple dispatch, certain classes of optimisations, and a great many runtime error checks cannot be performed.
quote:

# Type inference dynamic typing, baby!


Dynamic typing is not type inferencing.
quote:

# case nope, use if/elif/else


Switch is better than if/elif/else, because it allows for optimisation, and works with strong typing: e.g. the compiler can issue a warning or error if a switch on an enum type doesn't have cases for every member of the enum.
quote:

# rationals nope


I'm sure there's a rationals module somewhere.
quote:

# hash check - that's arguably Python's core type; every nonmutable type (for obvious reasons) can be used as a hash key


But, again, the lack of strong typing comes to the fore again. Python's hashes aren't typed.
quote:

# regular expressions check
# inline XML nope - there's an XML parsing lib, though


So you can do something like xml.parse("""<foo bar="wombat"/>"""), say. I still prefer the inline option: you could use it to initialise complex data structures, and it can be checked by the compiler.


struct MyStruct
{
char[] string;
int number1;
float number2;
} s = <MyStruct>
<string>The value</string>
<number1>42</number1>
<number2>6.9</number2>
</MyStruct>;


You could equally use:


MyStruct s = { string: "The value",
number1: 42,
number2: 6.9
};


quote:

# genericity dynamic typing


Dynamic typing is *not* the answer to everything, really.
quote:

# multiple dispatch not really


Which is bad.
quote:

# "state-based" programming classes are modifiabke objects


We want to modify the behaviour of instances, not entire classes. If you can 'rebase' an instance after it has been created, that would be nearly as good.
quote:

# multiple inheritance check, the method resolution order is open to introspection.


In C++, no resolution order is required -- conflicts are explicitly resolved. I'd suggest looking at Eiffel to see how a good multiple inheritance system works.
quote:

# refcounting with cycle detection check, with caveats for classes with destructors (there is no general algorithm to determine how to break a cycle and which object to delete first - the programmer must decide)


I believe Python also allows for true garbage collection, now.
quote:

# pointers none, the C API let you muck around, though (e.g. numarray module for efficient C-style arrays).


Pointers are handy, though.
quote:

# references *everything* is passed by reference


I think not:

def x (y):
y = 12
p = 7
x(p)
print p

The output is 7, is it not? 'Passing by reference' is not the same thing as 'passing a pointer to an object'.

EDIT: *mutter mutter* darned tags.

[edited by - Mayrel on October 22, 2003 6:38:51 PM]

Share this post


Link to post
Share on other sites
quote:
Mayrel
Assuming I understand you correctly, you suggest no garbage collection or reference counting? I don''t know what "linearity" means here, could you clarify?



Linearity:
In a non linear language there are 2 kind of variable semantics:
one is the "by value" semantic; for instance integers in 99% of the languages are manipulated by value.

a=1
b=a

in the expression "b=a" the value contained in the var a is copied in the var b.
The other case is the "by ref" semantic; Objects,strings and arrays are usually manipulated by ref

a=new Object;
b=a;

in this expression a and b will ponit to the same object instance.

A linear language only has the "by value" semantic, so every variable points to a different object
and an assignment always create a new instance of the object(like for integers).The object lifetime
is completely detected compile-time.

That''s can sound terribly inefficient, but beacuse is very easy for the compiler detect the lifetime
of an object compile-time, is also allows to carefully optimize the resource usage.

In any case there are very few linear languages out there, because linearity forces a different
approach to problems compared to classic imperative garbage collected languages.
Still I think is a technique that deserves more attention. I had the luck to work with the guy that
implemented the new system language for Amiga OS (that happen to be a linear language;unfortunately not out
yet because of amiga''s finacial problems) and have access to implementation details and papers;
I looks really usable and performance wise is not so far from C++.


In any case I think the most realistic solution for a ''traditional'' language would be a sort of localized ref counting.
The compiler should apply a strong analisys(similar to the one used in linear languages)
compile-time and apply ref countig only when needed. That would give both classic imperative
programming style and no GC(I hate GCs ).

Alberto


-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net

Share this post


Link to post
Share on other sites
quote:
antareus
fagiano: you''ll like C#, it has a great majority of those things you listed.



I know C#, is cool, but IMHO GC and the huge runtime make a language not suitable for multiplatform game programming. I had PS2, Xbox and Gamecube in mind when I wrote the post .

-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net

Share this post


Link to post
Share on other sites
Personally, I think that if Perl were made into something that was compiled into a proper executable [or somehow got equivalently fast] and had any decent sort of structure handling, it''d be pretty ideal.

Though personally, I''m pretty sheltered in my CS knowledge. Having regexes so ingrained into the language is an exceptional advantage [imo]

Share this post


Link to post
Share on other sites
I have two questions.

Concerning the prospect of using C/C++/C#/Java style syntax (or something similar), I ask: why? Is it not the point of progress to try new things? Form new paradigms? Be original. Being original is how Fords were made and how integrated circuits came to be. Sure, ideas can be borrowed and shared, however, entirely new implementations should also be attempted. Why use a syntax or grammar base that has been used and used and used, time and time again. Sure, I know. It has been tried and tested. It works. People like it. But when you think about it, nothing is changing, we are staying in our current state. If we could redesign the face of programming, shouldn't we start with the code itself? Why create a new language that looks the same as C, uses the exact same paradigms (perhaps, only improved), and is different only in terms of a few new keywords?

Would anyone agree it might be time to think outside of all current paradigms? If not, explain why.

Secondly, how would one attempt creating a truly, fully, and easily portable language? Portable not only in terms of operating systems, but also processors. And not just standard IA-32 or similar x86 processors, but also Z80s and PICs and other, low-level processors. What considerations would need to be detailed and included in the language, and how would it affect things?

Thanks for the replies. This is getting exciting. Keep it going. Keep responding to other replies. Reciprocate.

[edited by - khaos on October 22, 2003 10:02:52 PM]

Share this post


Link to post
Share on other sites
Today''s conversation in Comparative Langs:
quote:
Kid: Why do you hate imperative languages?
Professor: I never said I hated imperative lang..
Kid: Okay, why do you dislike them?
Professor: ...Every breakthrough I''ve made in my career has not been with an imperative language

Our teacher commands a great deal of nerd respect.

Share this post


Link to post
Share on other sites
I''ve given languages, OS and DBMS a lot of thought.

Personally, I thinkt they''re basically all should be components of a whole.

An OS and DB really shouldn''t differ. If anything the DB should be a logical view of the OS which handles hardware quibbles. THis is also your runtime. Since we''re always manipulating data, we should have databases that can handle all sorts of data formats and structure formats. I should simply be able to define my structure, it''s properties and give whatever other optimisation hints and the DB should implement the most optimal solution for me. It''ll be Quasi-imperative. Basically the programmer isn''t instructing, it''s more guidance with hints and possible instructions.

The language for the database should be SQL on crack. If you think about it, a lot of programming is simply viewing the same data in a different form. We do a LOT of filter programming. Queries are pretty damn good at this -- hell they pwn!

I like symmetric languages, they make me happy. I like Scheme for its symmetry. I dislike scheme for its arcane syntax. I don''t want to see or hear about lambda, cons, cdr, car, let, let-rec, let*... They is teh suck! I want less colloquial syntax. How about pair, function, procedure and so on and so forths??? Of course, I''d rather see symmetry via indentation to enforce well laid out code over parentheses -- I''m the style Nazi.

The IDE should be part of the language, documentation... should be part of the language. There is no excuse that IDEs are an after thought. If anyone has used code completetion they know all else is teh suck.

There are some issues, overly flexible languages become convoluted when many retards start defining macros all over the place and end up making a mess. The language becomes soooo abstract one looses the language completely and the medium of communication becomes null and void.

The other thing is the language needs AWESOME constructs for parallel execution. Programmers should be able to easily indicate atomic operations and compound operations.

Contracts are also necessary, this gets rid of a lot of invariance code that programmers get burdened with. Usually leaving the code marred with horrific exception/if/else constructs.

Try/catch SUCK! I hate exceptions with a passion. Semi-preidcates are sooo much nicer. Expressions are spiff, statements are pretty boring fare. Easily created compound returns are necessary, atomic returns require annoying packing.

If you wanna see a neat language check out Icon or Idol/Unicon.

Support for interesting object networks would kick ass. Multi-cast messages and all that. I believe someone covered this in their comments about dispatching.

I don''t like the idea of linearity. Personally, I think this is something the compiler can figure out via contracts and other hints.

Share this post


Link to post
Share on other sites
quote:
Original post by msn12b
No.

Wow, an excellent response that is sure to prompt amazing responses like this one!

(Someone had to call him out. Either put some reasons up or shut up.)

Share this post


Link to post
Share on other sites
It''s fine that you responded with a negative answer, but simply saying "no" makes your post seem sarcastic and quite mean. Please, could you explain why? Or if someone else agrees, back him up with opinions and facts. Yes or no answers do not get us anywhere.

If one were to deviate from C-style syntax, what are some examples of aesthetically pleasing syntax? New and original syntax ideas would be interesting to share.

Also, could one invent new paradigms (like logical and object-oriented, et cetera) to solve new problems? Examples? I find it hard to start completely fresh. I think I''d be better at improving object-orientation, but creating a entirely original paradigm, like creating a new literature genre, seems to be a difficult task. But any ideas are welcome.

Share this post


Link to post
Share on other sites
A Python-style core language with Lisp-like macros to extend it with new constructs.
quote:
Original post by Mayrel
For my toy language, I have documentation embedded as XML as so:

import std.io.*;

@<fun name="main" type="int">
<arg name="args" type="char[][]" text="Arguments"/>
This program does blah, blah, blah.
</fun>
int main (char[][] args)
{
out.print(1 + @<note>This is seven, for no particular reason</note> 7);
return 0;
}

Dude.. That's truly ugly. And way too redundant.

[edited by - civguy on October 23, 2003 9:38:20 AM]

Share this post


Link to post
Share on other sites