Thread: Symbolic vs Descriptive

Simbolic just looks tighter and cleaner as already some said. Besides that, I don't think you can do this with descriptive.

I prefer symbolic because it is more compact and succinct and also
less to type than the descriptive syntax.

Uhhmm... I gonna make a symbolic language then.. xD

If all keywords begin with an uppercase letter, is it OK?

Code:

If(something == True) {
  Console.print("Something is true"); //Console is a class
} Else {
  gui.messageBox("Oh, something bad happen!"); // gui is a package
}

For(Var i:Integer=0; i<10; i++) {
  Var c:Char = aString[i];
  If(c == 'X') {
    //Do something
  }
}

xP

@audinue: sure, making all keywords have initial caps, or all variables uppercase, or whatever might be a good idea to make your parsing simple to begin with.

But really, it's not too difficult to allow variable and keyword names with similar capitalization. You just have to keep a list of your keywords; for every alphanumeric symbol that looks like a variable or a keyword, you check to see if it's in this list. If it is, well, it's a keyword. If it isn't, it's not.

[edit] Oh, and I much prefer symbolic languages, as you've put it, like C and C++. BASIC involves too much typing for me.

But then, I like programming in Perl, sometimes not very legibly, so don't ask me.

From a parsing perspective, there probably isn't much difference between the two. In the one case, you look for special symbols like "}"; in the other, special tokens (words).

I agree that the meanings of the different types of symbols doesn't really confuse anyone unless they're really new to the language. [/edit]

>I should seriously hope the latter.
It's not uncommon to find a language you enjoy working with and mold your preferences around it. The end result is the same: you prefer working with that particular language and any similar languages. In fact, it's hard to know what you like without pointing to something that already exists and saying "I like that". I'd be more worried if Elyssia uses only C++ (or a small number of similar languages) to determine preference.

To answer the original question, I like them both. There aren't sufficient differences to prefer one over the other; the difference between symbolic and descriptive in this case doesn't affect the transparency of the code at all.

Originally Posted by MattW

I sometimes wonder if your likes conform to C++ or if C++ conforms to your likes, Elysia. I should seriously hope the latter.

To add to that, I have also seen C and done a lot of C++ in a C way, and C is symbolic too.
I have used VB/VBA, and I am not a fan of either.
I have lots of Javascript, which is not as good as C++, but still symbolic.
I have used VBScript, though not a particular fan of it.
I have done lots of PHP. It's certainly OK, and it's symbolic.
I have seen and messed with Perl. Not a big fan of it, mostly because it's too symbolic.
I have also done Managed C++ and C++/CLI, and hugely dislike both of them. Managed C++ was far better with its symbolic usage than C++/CLI which was just horrible.
I have also used C#, and while I do like the symbolic parts, I hate the descriptive parts where you had to explicitly tell "pass by reference" when you pass something, for example. This is apart from my usual hate for dotNet in general, naturally.
I have done lots of HTML too (naturally), mostly XHTML, CSS and dynamic HTML. HTML is very descriptive, and so is CSS, but I think they could all be no more than descriptive. Symbolic would not fit these.

...And I think that's about it. As you can see, I lean more towards symbolic than descriptive.
Perhaps it is part of why I like C++ so much. Indeed, it is a part of why I like it. I have looked into some of D, and I was a little turned off by some awkward symbolic syntax.

Perl is my best friend and my secret lover... I think you should look into it again. Nothing handles string parsing quite as elegantly as Perl.

Yes, it does. It's very powerful, but all those symbols for parsing & all that makes me go crazy. That's why it's a little too symbolic for me.

Something I worried in symbolic languages:

When we develope open source applications and since most of them still undocumented...

I just want prevent the user of, say, xxx language using a statement like:

Code:

write("Say no to drugs! " + theStr.substr(theStr.indexOf("abc")-1, theStr.length) + parseDouble(...) + ... + "Oh my God!");

While mean it's a very very ugly code, xD, harder to read, harder to debug, and very unsuitable for open source application

Yeah, you will find yourself disappointed when reading the source of an open source symbolic language applications, which should not to be like that.

And yet, a simple statement like:

Code:

result /= point.x + ++y * sin(node.angle)

We need to think twice to understand the code above sometime.

... zzz ...

Will "Code convention" solve this problem, maybe?