What makes Centum a bad language?

Centum is a basically functional language with some object oriented features. While I and a few other people enjoy the language it has not had any real momentum in terms of building a community. For example I thought that Centum might appeal to some of the people who liked LISP, since they share some ideas. One explanation that has occurred to me is that the language has obvious flaws (besides the initial implementation being on Windows). However I have not received any feedback as to what makes this language uninteresting/unwanted. Hopefully you kind folks can help me out a bit.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Appealing to Lispers?

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.

there is *some* variation

I agree that a big problem with Centrum is no new innovation over Lisp, but there are also things lacking in Centrum that Common Lisp has. First and foremost, a large library (though many languages beat Lisp in this respect, too). There is also less powerful OO in Centrum, and the syntax is more complicated and, from a Lisper's perspective (or my perspective), very ugly. It's not even terser for its ugliness. Centrum seems to encourage control structures like while without providing Lisp's loop or tail call optimization.

As to a large library size ..

As to a large library size ... well it takes time to build one. However it is possible to create and use Java classes from within Centum, so that helps close the gap a bit. As for sytax comparison: (mapcar #'(lambda (num) (+ 1 num)) list) to Centums: foreach (list) {+ 1 p_0} Both do the same thing, but in Centum you had to type less, and there was less conceptual effort in terms of nested ()s.

Well, if you believe that con

Well, if you believe that conceptual effort is related to the use of brackets, you could re-engineer your syntax so that foreach is a function taking list as an argument without the need for brackets, and a block/lambda/function (whatever you like to call it) as the second argument. I would also note that you have reduced the need for bracket nesting by replacing '(lambda' with '{' and the corresponding ')' with '}', and having a specific syntax for free variables. You can always reduce the number of symbols needed to encode a message by increasing the size of your alphabet. This is not necessarily the best way of going about things.

about (list)

I put the () arround list because I assumed it was a function that was retuning a list. If you has a fixed list then: foreach a b c ... x y z {+ 1 p_0}

Right, because in the lisp ca

Right, because in the lisp case, the list would be fixed (already stored in a variable). Anyway, in this case, it isn't clear why the final argument isn't part of the list.

The language figures out that

The language figures out that the last argument to a foreach statment is always going to be a function, and thus finds the last argument and call it once on each other member of the list and then returns the results.

Part of the syntax gives me nightmares.

#include.. ARGH.

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

What's its hook?

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.


Why does creating a message box appear that we are trying to enter the same problem space as TCL (we aren't)

Well, you claim to be lisp-li

Well, you claim to be lisp-like, and the examples focus on programming for GUIs. This description could easily apply to Tcl.

Anyway, by asking that question, you have missed my point: It is not at all clear from the website what Centum is for. The only thing it looks like it might be for is graphical interfaces. The statement that it is intended that it be "easy to express algorithms" can probably be applied to all modern programming languages - including C++ - , and certainly all functional languages. This is probably why it has no buzz around it. I think that everyone on this site will be able to tell you that language designers who want to promote the use of their language cannot take a build-it-and-they-will-come approach.

The reason that the first few

The reason that the first few examples displayed message boxes is because I felt that introducing the console came with a bit more overhead, and felt it best to go with message boxes first. As soon as the console is introduced message boxes are no longer used in the examples. I have to admit that "easy to express algorithems" was not the best coice of words. Perhaps I should have used something along the lines of "terse" or "compact", but I had the feeling that that would lead people to view the language as inscrutable. So if taking a "build-it-and-they-will-come approach" is bad, what is a better idea?

not necessarily bad

"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 appreciate criticism, but c

I appreciate criticism, but could you please be more specific. What exactly made the syntax "repugnant"?

Not so much criticism

OK so maybe it was criticism. But that wasn't my intention per se.
I was just telling you why I would not have bothered to get interested in your language. As if you had not posted to LtU and I'd just stumbled along it.
As for the syntax being "repugnant", I will say that it suffices that it was different from what I've seen. That may not be a good reason at all; in fact it isn't. But most people, including myself, are turned off by new syntaxes. In other words the main reason for my above post was to try to explain why your language might be unpopular.
Let me say that I'm a lisp fan. More of a scheme fan actually. Now when I first saw scheme syntax I was revolted. It almost stopped me from looking at the language seriously, but I had been told (by people I respected) that its semantics were novel and learning them would be an enlightening experience. So I did learn scheme and then went on to CL (although I'm not a lisp guru), and now I like the syntax. Does that put my first post in a more understandable light?
And, I should say I'm sorry, because I should most assuredly have been more clear when I wrote my post, to make it clear that the repugnant thing was a first impression, which is more subjective than anything.

The benefits

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


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


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

    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.


Program either functionally, imperatively, or both

That's not functional vs. imperative; that's just different styles of writing the same expression.

Smooth integration of multiple return values
somevalues {
    return "A Number: " 4

I'm sorry, but that's a dreadful syntax. You're using whitespace as an infix operator, which is really hard to read. I find it painful enough that ML uses the whitespace operator to mean function application; and that's something that gets used all over the place. Multiple return values are rarely needed, which means I'd rarely get practice in reading the syntax.

Name parameters or leave them anonymous:

That's one of the things I hate about Perl.

Dynamic scope:

What you've got here isn't what's generally called dynamic scope; I'm not sure what it should be called (explicit scope?), but it seems to have the effect of a limited form of polymorphism. (Note that dynamic scope, in the standard sense, has been Generally Recognized As Unsafe for 20 or 30 years.)

Bad vs Not Good Enough

Peter asks on his PL project Centum: "While I and a few other people enjoy the language, it has not had any real momentum in terms of building a community".

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!

Learning new languages

It's worth keeping in mind the LtU readers are more adept at learning new languages, and like doing it more than the average programmer. So, in some sense, if you can't convince people here to spend time on the language, you might find it hard to convince what Scott calls "the user base".

It's ugly...

It also has such complex syntax that trying to generate code would not be fun.

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.