Lambda the Ultimate

Probably the wrong crowd to target for a language. About the only thing that really appeals to the Lisp community is a variation of Lisp (like Scheme). I think that's the concern Guido was appealing to in his recent idea to dump lambda from Python.

#include.. ARGH.

Even if it's not really a preprocessor directive (it's not, is it?) it reminds me of very bad C++ experiences.

It's not really clear what the big deal with the language is. Who do you expect to use it? How is it similar to lisp?

Looking briefly at the website, especially with the message-box "hello world!" it strikes me that you are going up against Tcl, a language which is popular, and which in my experience has no detractors, only people who don't use it.

"bad" and "unpopular" are two independant ideas. I'd sooner argue that, if they are dependant, they are inversely proportional, since the evidence we have seems to indicate that.
as for me, when I looked at it, I thought the syntax was repugnant. I'm sorry, I know this language is your baby, but that was my reaction. That in combination with the fact that it didn't offer a novel semantic benefit made me uninterested. That was my off-the-cuff reaction to your language; I didn't thoroughly read your website/documentation or even your post, but that's what I do for most languages.

I have had a request to first ellaborate on what I think is good, so here it is


Why you want to use Centum:

Note that some of these features are not unique to Centum, and I am not claiming

that they are here, merely collected in one place for your convenience.



Program either functionally, imperatively, or both

Centum fully supports your favorite method of programming, weather you prefer:

dostuff f (morestuff x y (even_more) c) e

or

valueA is (even_more)

valueB is (morestuff x y valueA c)

dostuff f valueB e




Smooth integration of multiple return values

A function can return more than one value with no extra work. Given the

functions:

somevalues {
    return "A Number: " 4
}

dostuff {
    return p_0 (* 2 p_1)
}

the commands

PrintLn (somevalues)

PrintLn (dostuff (somevalues))

will print A Number 4 and A Number 8 to the console.



Name parameters or leave them anonymous:

When working with a small function you can leave its parameters anonymous, or you

can name them for clarity in a longer function. For example:

functionA {
    params: a b c
    + a (/ b c)
}

functionB { + p_0 (/ p_1 p_2) }

Mathematical operations that look normal:

If you include the nicemath header then the following will have the

same result:

+ 3 (/ 2 6)

3 + 2 / 6



Dynamic scope:

Functions have the ability to change what they do at run-time. For example:

PrintThreeNumbers {
    PrintLn (getNumber) (getNumber) (getNumber)
}

NumberFromConsole {
    static getNumber {
        # read from console
        # validate input
    }
}

NumberFromClient {
    static getNumber {
        # network code
    }
}

NumberFromDatabase
{
    static getNumber {
        # database code
    }
}

Now with these definitions the following calls:

PrintThreeNumbers using NumberFromConsole

PrintThreeNumbers using NumberFromClient

PrintThreeNumbers using NumberFromDatabase

will all perform differently, using the appropriate getNumber

function, without having to re-write the PrintThreeNumbers function.



Easy exception handling:

There is no need to place a try block where exceptions may occur, simply place

handle or case statements where you wish exceptions to be caught. For example

function {
    # stuff that may thrown an exception
    case DivisionException {
        # when there is an error
    }
}

Ability to use Java classes and methods:

Can’t find something in Centum? Well then simply call into Java to get what you

need done. For example if you need to connect to a database, send email, or use

existing code you have written in Java.

I haven't paid much attention to the details of Centum. I certainly won't make (or agree with) any claims that it is "bad" (or good); although I will note that such claims are virtually meaningless without some context.

Nor am I going to get into any technical evaluation of the language here, other than to note it does have some interesting ideas.

Instead, I am going to ask the following questions:

* What have you done to promote your language, and expand your user community?

* What problems does your language solve better than existing languages?

The first question relates to the dirty business of marketing, of course--just because you build that better mousetrap; the world isn't going to beat a path to your door. By "marketing", I don't mean advertising necessarily--though that's one way to build mindshare, especially if you have the money to do it. However, languages like Tcl, Perl, and Python have become mainstream despite no support from any well-heeled commercial interests.

Posting to LTU is useful for getting feedback; but many of us represent the competition rather than the user base, so I wouldn't consider it an effective means for evangelism. :)

Obviously, nobody will consider your language if they have never heard of it.

The second question relates to why someone should consider your language once they have heard of it. And the answer needs to be in the language of users, not the language of the PLT community. Many of us 'round these parts like languages well-stocked with features (espcially those we consider to be "good")--as well as languages with interesting theoretical properties such as reduction to the [insert Greek letter of your choice] calculus. And obviously, a good language should be theoretically sound.

But users don't care about any of that. Many programmers consider advanced features a burden rather than a benefit, have no interest in theoretical aspects whatsoever, and have little time to invest in learning new languages to begin with. Just by making the suggestion they learn a new set of tools, you start off in the hole. What they DO care about is being able to deploy Web pages, or business apps, or embedded systems faster and more reliably. We take it as a given 'round here that theoretical goodness implies greater productivity and a higher degree of correctness; those in industry (and in hackerdom) are inherently suspicious of such claims. (And rightly so, as many such solicitations arrive in my in inbox every month, from vendors looking for a piece of my employer's wallet. Most are discarded unread into the wastebasket.)

In the case of your language, you don't explain why it's more suitable for Lisp-like problems than Lisp, or why it's more suitable for ANY problem than the current in-vogue solutions. Perhaps the language isn't intended for such a purpose--it's your pet project which you do for fun. That's OK--it's following Dennis Ritchie's advice--but you shouldn't expect the world to take notice if you don't take notice of the world's problems.

Good luck!

Here's a scoop for all language designers out there. Even the (fairly) conservative company I work for is writing code generators. If you want to get fancy, think about it the way you'd think about the RISC/CISC tradeoff. Although CISC machines can take care of a lot of details for manually crafted code, it's usually easier to write compilers for RISC machines due to orthogonality. Similarly, when you write code generators, the more regular and simple the target syntax, the easier it is to do; the more obtuse and baroque your syntax is, the harder it is to build code that would work in all of the contexts your compiler might want to place the code into.

And that's why I like Lisp - the code has built-in generation operators (macros) and a simple syntax to target.

As for other issues about Centum... it's not that it's a bad language - it's just not a great language. It does nothing interesting. As for the stated rationale of a mix of OO and functional? Who cares? Static typers have OCaML while dynamic typers have Lisp. Why do we need another language here?

If you have some particular axe to grind, by all means do so. But often what I see touted as revolutionary is simply a new syntax for hackneyed ideas. And that's fine for what its worth. But it won't make users beat a path to your door (vidi Dylan as a stunning example of how much changing syntax does for the popularity of the language).

My recommendation? Do something new.