PDA

View Full Version : Symbolic vs Descriptive



audinue
12-06-2008, 02:26 AM
Symbolic:

main {
var n:Integer = 10;
swap<Integer>(n, 20);
printf("%d", n);
}

function swap<T>(&var1, &var2:T) {
var temp:T = var1;
var1 = var2;
var2 = temp;
}

Descriptive:

Main
Var n As Integer = 10
swap<Integer>(n, 20)
printf("%d", n)
End Main

Function swap<T>(Byref var1, ByRef var2 As T)
Var temp As T = var1
var1 = var2
var2 = temp
End Function


Which do you like?
Tell me the reason, please,,

hauzer
12-06-2008, 02:33 AM
Umm.. Err.. The first one, because the second looks like VB, which I hate.

Elysia
12-06-2008, 03:55 AM
I do have to agree. C++ is symbolic, as well, so I like symbolic.

SlyMaelstrom
12-06-2008, 04:10 AM
I wouldn't call it appropriate to associate the syntax style with a complete language... I also wouldn't say that descriptive syntax is what makes Visual Basic a pretty lousy programming language. Descriptive languages are easier to pick up for new programmers, obviously, because there is less syntax you really need to memorize. However, since most symbolic languages tend to use the same symbols... once you know one, almost all of the other ones are pretty easy to pick up and understand. Symbolic languages tend to make it easier to identify variables and functions than descriptive languages do... especially when you're looking at the code on paper rather than a color-coded IDE. So, for that, I'd say I prefer symbolic languages. If however, all programming languages tended to do their own thing with symbols like using angle brackets for scope and braces for grouping... I could see myself appreciating the simplicity of descriptive languages more.

lruc
12-06-2008, 06:10 AM
I like descriptive better actually. I mostly prefer it because I like tabs over {'s.

C_ntua
12-06-2008, 06:26 AM
Generally descriptive. But something more like:


Main
n::Int = 10
swap<Int> n 20
printf "&#37;d" n
End

void swap<T> &var1 &var2::T
temp::T = var1
var1 = var2
var2 = temp
End

So you don't put ";". You just change a line. You don't put "," you just pug " ". You don't put (,) except some occasions (like Haskell). You don't put brackets but you put <tab>.
But you use symbols like <,> for "additional" information. I don't like using "byref" or "ref". They get "confused" a bit with the variables. I want to be clear "this is the variable and this is how you pass it".

twomers
12-06-2008, 07:15 AM
I don't mind either. I do a lot of C and a lot of Matlab, so I use both at a regular basis. One thing I'll say for 'descriptive' syntax is that it is sometimes nice to be able to see colours flagging scope rather than searching for braces.

abachler
12-06-2008, 08:45 AM
I don't mind either. I do a lot of C and a lot of Matlab, so I use both at a regular basis. One thing I'll say for 'descriptive' syntax is that it is sometimes nice to be able to see colours flagging scope rather than searching for braces.

oh god that woud be ugly as hell, id keep thinking a certain scope was all keywords or comments and the whole program woudl be at the same scope (no {'s )

BASIC is intended to be a teaching language, Visual Basic is not. There are a lot fo reasons I don't use VB, but honestly the syntax isnt one of them. VB just lacks the flexibility of C/C++. I'm sure you could do anythign in VB that you can do in C/C++, except maybe write an OS, but the mental acrobatics you would need to perform to twist the languge into doing some of the things I need would make it so painfully obvious that it is unsuited to anything but web toys and excel scripts you would pull your eyeballs out. Then again, I wish excel would support C/C++ instead of or at least in addition to VB.

I honestly dont see whats so hard about learning C/C++.

Yarin
12-06-2008, 11:06 AM
Definitely symbolic, descriptive may be easier for the non-coder to read, but it really gets annoying having to type "End Function" when you can just slap down "}", a programmer can read them at pretty much the same rate, but you can type symbolically a lot faster. Brackets are also less "in your face" than full words are, making it easier for you the programmer to pay attention to the involving parts of code.

lruc
12-06-2008, 01:12 PM
Definitely symbolic, descriptive may be easier for the non-coder to read, but it really gets annoying having to type "End Function" when you can just slap down "}", a programmer can read them at pretty much the same rate, but you can type symbolically a lot faster. Brackets are also less "in your face" than full words are, making it easier for you the programmer to pay attention to the involving parts of code.

I disagree. A simple 'end' would suffice rather than 'End Function'. I would also find it easier to type the word out because you wouldn't have to use shift along with an oddly placed symbol.

Elysia
12-06-2008, 01:13 PM
The oddly placed symbol looks better IMHO.

anon
12-06-2008, 01:38 PM
What if END also happens to be a command to end execution?

C_ntua
12-06-2008, 01:46 PM
What if END also happens to be a command to end execution?
Well, it would be a keyword so it wouldn't be used as a command (dunno if I got what you meant...probably not)

lruc
12-06-2008, 02:03 PM
What if END also happens to be a command to end execution?

What distinguishes a } at the end of a function from a } at the end of the program? I certainly don't see a difference...

anon
12-06-2008, 02:51 PM
I just meant that in Basic there already is an END command, so it is taken up. In a hypothetical language, do as you wish.

I don't think there is a } at the end of a program. There's one at the end of main(), but the program may stop in a number of other places (e.g exit).

Yarin
12-06-2008, 04:44 PM
I disagree. A simple 'end' would suffice rather than 'End Function'. I would also find it easier to type the word out because you wouldn't have to use shift along with an oddly placed symbol.
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.

hauzer
12-06-2008, 06:17 PM
Simbolic just looks tighter and cleaner as already some said. Besides that, I don't think you can do this (www.ioccc.org) with descriptive. :)

stevesmithx
12-07-2008, 02:30 AM
I prefer symbolic because it is more compact and succinct and also
less to type than the descriptive syntax.

audinue
12-07-2008, 06:23 PM
Uhhmm... I gonna make a symbolic language then.. xD

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


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

whiteflags
12-07-2008, 11:35 PM
Simbolic just looks tighter and cleaner as already some said. Besides that, I don't think you can do this (www.ioccc.org) with descriptive. :)

Yes, you can. Being too verbose can be rather obfuscating as well.

jwenting
12-08-2008, 12:11 AM
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


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.

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.

dwks
12-08-2008, 09:17 PM
@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. :)

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.

jwenting
12-08-2008, 11:13 PM
I agree that the meanings of the different types of symbols doesn't really confuse anyone unless they're really new to the language.

or unless they're used for multiple, inconsistent, purposes.
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.

indigo0086
12-09-2008, 05:13 AM
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.

MattW
12-09-2008, 02:41 PM
I do have to agree. C++ is symbolic, as well, so I like symbolic.

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

Prelude
12-09-2008, 03:10 PM
>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.

Elysia
12-10-2008, 06:00 AM
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.

SlyMaelstrom
12-10-2008, 06:13 AM
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.

Elysia
12-10-2008, 06:16 AM
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.

audinue
12-10-2008, 02:30 PM
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:

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:
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?

Prelude
12-10-2008, 02:37 PM
audinue, what you've described is sloppy programming, and probably also poor library interface design, not any inherent problems with the language syntax.

matsp
12-10-2008, 02:42 PM
I agree with Prelude - redesigning the language elements to be descriptive, does not change a programmers ability to write bad code - it just changes what the stuff AROUND the code looks like.

--
Mats

audinue
12-10-2008, 05:26 PM
Yeah it would not change anything,...

You right.