Shift or not, oddly placed or not, it's still a little easier to type. But the main reason I prefer symbolic is because it becomes easier to distinguish different types of commands from one another at a quick glance, plus it looks much cleaner.
Printable View
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?
xPCode: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
}
}
Not strictly any one language, I've borrowed elements from the likes of Progress, PL/SQL, and Cobol here, this is probably about the most descriptive you can get before getting repetitive in your verbosity :D.Code:DECLARE IDENTIFIER SECTION
HELLO_WORLD AS CHARACTER
END IDENTIFIER SECTION
DECLARE PROCEDURE SECTION
PROCEDURE PRINT_HELLO
BEGIN PROCEDURE
PRINT HELLO_WORLD
END PROCEDURE
END PROCEDURE SECTION
BEGIN
EXECUTE PROCEDURE PRINT_HELLO
END
I prefer that over the likes of Ruby and Perl which can be terse to the point of being incomprehensible.
The optimum is somewhere in between, where languages like C++, Java, and Pascal reside.
@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]
or unless they're used for multiple, inconsistent, purposes.Quote:
I agree that the meanings of the different types of symbols doesn't really confuse anyone unless they're really new to the language.
Having a language use the same symbol for different things depending on placement is confusing.
That's in fact one big potential disadvantage of operator overloading, it allows language users to introduce such inconsistencies.
I use mostly C++/C# and Javascript so all the "C-based" languages are more familiar to me. I am also learning (or trying to learn) ruby, which is kind of weird in the way it's structured. To me, Symbolic is more descriptive than descriptive. I don't find Descriptive languages as intuitive as they are made out to be.
>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.
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:
While mean it's a very very ugly code, xD, harder to read, harder to debug, and very unsuitable for open source application :(Code:write("Say no to drugs! " + theStr.substr(theStr.indexOf("abc")-1, theStr.length) + parseDouble(...) + ... + "Oh my God!");
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:We need to think twice to understand the code above sometime.Code:result /= point.x + ++y * sin(node.angle)
... zzz ...
Will "Code convention" solve this problem, maybe?