Computer Languages aren't Human Languages

Though I've become agnostic about the utterly meaningless non-choice between VB.NET and C#, the inherited syntax of C leaves a lot to be desired, in my opinion. And not just in the case sensitivity department. Daniel Appleman, in his excellent e-book, VB.NET or C#, Which to Choose?, concurs:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/08/computer-languages-arent-human-languages.html

i’ve never used AppleScript, either, but if it’s not COBOL in lower case; it’s hard to imagine what else could be. gad.

Yeah, but in some languages writing FORTRAN-style code is considered the epitome of good practice.

Assembler?

APL?

Intercal?

Brainf*ck?

I have some experience with AppleScript, and it’s as bad as it seems. But.

The problems of AppleScript are not inherent in the fact that it tries to mimic natural language. It does so poorly and incompletely and with ill-defined boundaries, and that makes it look bad. It has other, more serious, problems; the specific one I remember is that support for it is application-dependent; application developers are (or were - it’s been a long time) required to define their own dictionaries and implement language support themselves. Some, needless to say, did a better job than others.

What was tantalizing and mind-blowingly frustrating about trying to use AppleScript is how much it looked like HyperTalk - the successfully English-like language of HyperCard. HyperTalk really did read, on occasion, like poetry. It was entirely application-specific, and the only classes were predefined. It was interpreted and occasionally confusing. And it drew a lot of amateur programmers in and they wrote a lot of amateur programs. But on the whole I have to say it was a genuine success as a language.

I don’t see what’s not clear, or verbose enough, about the following. It’s concise.

public class BClass: AClass, Iint

The VB.NET version is like the above but with comments:

// BClass Inherits from AClass and Implements Iint
public class BClass: AClass, Iint

Which is completely unnecessary and too verbose. Just like the VB.NET syntax. It’s like the rule of not commenting exactly what the code is saying:

i = i + 1; // add one to i

“Though I’ve become agnostic about the utterly meaningless non-choice between VB.NET and C#, the inherited syntax of C leaves a lot to be desired, in my opinion.”

C (as you’ll know) never had inheritance or interfaces. I don’t see why it wouldn’t have been possible to make C# be more verbose, like the VB.NET style inheritance/interface syntax. I think C++ is the guy you’ll want to point a finger at. :slight_smile:

The inheritance syntax is one area where I wish C# had ripped of Java a little more.

On the other hand, in this age of AJAX development, sticking with the mostly-consistent JavaScript/C# syntax actually makes a lot of sense.

Read a funny post on VB/C# by Rob Howard a while back, and he pullod out a quote I just love from Rocky Lhotka of CSLA fame:

“Basic was designed specifically to cater to the way people think. C-style languages were designed specifically to cater to the way machines work”

Interesting! You can read more of Rob’s post here:

http://weblogs.asp.net/rhoward/archive/2005/12/07/432579.aspx

I use C# simply because the structure of it is easier to navigate, mostly because I don’t READ code, I see it in my mind (blond… brunette… readhead) as patterns of execution. Your point about language is spot-on: coding is instruction, not prose. Though the fusion of both would be pretty damn cool :).

The flaws in AppleScript’s english-like syntax are obscured by its many other flaws, such as the compiler that not only changes your source code (as if that wasn’t bad enough), but changes it in a way that no longer compiles.

http://girtby.net/articles/2005/05/05/automated-bug-generation

In general though I take your (and Gruber’s) point. The although the word “nothing” is more common in natural language, it does not by any means capture the sematics of what we programmers call void - so having a separate word for “void” is a good thing. Computer languages are different to human languages because they are used to describe different things.

You know, this post reminds me of someone I heard once who actually believed that COBOL was the only true, high-level language because it was the most English-like… absolutely ridiculous.

In the UK, at least, many (most? not sure) of the higher end of the old VB community, of which I was a member since VB 1 was released, have migrated to C# through choice, despite the obvious superiority of VB.NET in places, including those you already mentioned.

I think a possible reason for this is that they (we) just kept tripping up over the .NETty aspects of the new VB, to the extent that they (we) were frustrated by the differences. C# on the other hand, was sufficiently different - and so much more accessible than C++ - that we (they) started out slower and found that paradigm assimilation was less painful that way.

Having said all that, after 6 months away from VB6 I do find myself hankering for automatic casing. I wonder if it’s time to go home?

Just because you write End If or End Class, it does not make your code more readable. If you write a huge software solution, you are probably going to have several methods and classes, so a little End X will not save you. And if you have done your coding correct, I don’t think it is important to tell yourself or somebody else, what a class is. The important is to highlight what is important in your code, and if everything is text with words, it can be difficult in a quick glance to separate what you yourself have written and what is required from the language.

Speaking of vb.net, maybe you think that the “AndAlso” and “OrElse” bitwise operators are very readable, but as a programmer I find them very ugly. And I can still be confused when I try to do bitwise operations in my “if” statements, how does vb.net calculate it, because it is not like csharp. And why stick on to the sub/functions, when they still are converted to methods, at least in terms of dotnet reflection.

No matter how much human language you are trying to make your code look like, I still think that programming should be focused on Mathematics.

C# reads pretty much the same as VB.NET, you just have to replace the symbols with words as you read. As with anything, this becomes second nature after a while and then you have the bonus of a visual distinction between code semantics and variables.
Which is easier to tell where the variables are and whats going on at a glance?:
if number1 is more than number2 then let number3 equal number4 otherwise let number3 equal number5
if ( number1 number2 ) { number3 = number4 } else { number3 = number5 )
I know it’s an extreme example, but it’s a lot easier and clearer to see what is going on in the second version once you know what the basic operators and symbols mean, yet you read it like the first.

"Speaking of vb.net, maybe you think that the “AndAlso” and “OrElse” "

This was to “fix” the lame way that VB’s expression evaluation would not short circuit. Now you’ve got this garbage of AndAlso, OrElse etc.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=88311

I like where it says “Resolution: By Design” Yeah, bad design.

Jon, I always preferred:

if (filesProcessed) {}

If we put good forethought in coming up with variable names, the above should be extremely obvious, and the extra “== true” is really redundant. Here we get the best of both worlds – it reads like English only where it truly makes sense to.

The highest level language is what’s used to order another poor sap to write the code. :wink:

Dim svc As New System.Windows.Forms.IDataGridColumnStyleEditingNotificationService
vs.
System.Windows.Forms.IDataGridColumnStyleEditingNotificationService svc = New System.Windows.Forms.IDataGridColumnStyleEditingNotificationService;

Even assuming Forms is referenced and is unnecessary, which is kinder on the eyes? ;p Of course, it’s only an extreme example of where syntax can make one’s life easier.

I like case sensitivity because it forces you to have a consistent naming convention. CamelCase, PascalCase or underscore notation for private variables, public variables and methods? No matter what you use if you are forced to use the same case throughout it helps identify the scope of the variables.

I am accustomed to working in both VB and C#. When it comes down to getting work done I always find VB to be faster to type. It may be more verbose but my fingers and wrists don’t mind typing a short word instead of stretching to enter more brackets or parenthesis.

I also prefer Pepsi over Coke.

I’m currently in the process of generating more or less ISO SQL. SQL is a typical exemple of the evil of english language like syntax.
The “new” inner join syntax for instance forces you to pay attention on the order of declarationof your tables, for something that is SYMETRIC :
from A inner join C on (B.c = C.c) inner join B on ( B.c = A.C)
won’t work. The equivalent “where” syntax rightly does not pay attention to the order of tables in the from clause.

Aaron: “The syntax in C# is an adaptation from Delphi, and carries over the coding convention that interfaces should always start with an “I” (but drops the “T” in front of classes)”

The convention regarding interfaces actually comes from the original implementation of COM, so it’s from C++, not Delphi. Delphi just followed.

Well this is what happens when you use English, the worst language in the world when you’re trying to be precise about anything.

We should program everything in Korean. No synonyms, no homonyms, no upper/lower case, no silent letters, no “i” before “e” except after “c” except for “science”, and very exact, defined syntax rules.

I’m always amused by these silly “Let’s make computer languages look like English!” discussions. It seems as though most computer programmers have very, very little experience with foreign human languages that would give them some more insight into how to create better programming languages.