Language Syntax Preferences

[MasterRacker]

This is in response to a comment dilettante made in another thread about hating the syntax C-style languages. I'm more of an admin type, but I've done some programming on and off over the years. I've used a half dozen Basics, a couple Fortrans, Pascal, an industrial robot language based on Pascal, VBA and a little bits of a few others.

In my case, when I got to C, I thought it was food of the gods. It could just be that I like terseness, but I find it to be the easiest to read language I've used yet. Just kind of curious to see what others think.


Jeff
If your mind is too open your brains will fall out...

 

[sleipnir214]

CajunGrocer:
Discussion of the "andalso" and "orelse" operators does sound like it falls under "language syntax preferences".


All:
To explicitly state my opinion, I prefer the syntax of a language that optimizes logical operators in the compiler to a language that resorts to squirrely syntactic workarounds.


lionelhill:
On most unix-like OSes, where commands tend to be small and simple, it is very common in shell script to invoke an application and process the return of the application.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[CajunCenturion]

The compiler is and should always be subordinate to the language.

If and when someone changes the language because of inefficienies in the compiler/interpreter, then they are committed the crime of solving the symptom, and not fixing the problem.

That type of thinking and action invariably creates issues that need not be created, and usually in the long, causes more harm than good.

Plain and simply, "if you can fix the problem, then redefine the problem" is poor engineering.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[sleipnir214]

How long have these squirrely operators been a part of the language?

It's obvious you can't just patch VB<current version> to change the behavior of the logical operators. Too much existing code would break.

But it seems to me that the optimization could be included in VB<version current + 1> and documented as a change in behavior.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[MasterRacker]

sleipnir, you're right on my point.

If you could do something like

IF (C=B+5)> 10 AND (A=47-T) < 50 THEN...

you would have a case for evaluating the whole expression even if the first case is false since there are also assignments being made. To my knowledge, you can't do this in VB, so what code could even possibly break, by simply optimizing the behavior of AND in the next release? To my mind, you enhance it and move on, not create a new operator.


Jeff
If your mind is too open your brains will fall out...

 

[CajunCenturion]

You cannot do that in VB, although you can in C. I agree MasterRacker, fix the compiler and move on.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[lionelhill]

I wouldn't sacrifice optimised evaluation of boolean expressions just to help out the programmer who can't be bothered to type his/her assignments in another line.

Thanks sleipnir about unix. Haven't had much to do with unix myself (all dos and windows)

 

[CajunCenturion]

I agree with you lionelhill, but I also would not change the definition of language to help out the programmer who can't be bothered to put proper optimizations in the compiler.

One other aspect of this discussion that although is no longer an issue, was an issue at the time C was first developed. Memory Management.

Memory was not as cheap, nor available, like it is today. Every byte counted. writing this:
IF (C=B+5)> 10 AND (A=47-T) < 50 THEN...
instead of this
C=B+5
A=47-T
if ((C>10) and (A<50)) THEN ..
could result in a saving a just a few bytes, and those few bytes could make the difference between being able to finish a program and not.

I know it's hard to understand things in those terms today because memory is cheap and available, but those who were around, and programming PCs in the 70's, and even mainframes in the late 60's and earlier, remember that each and every byte was a precious commodity.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[AndyWatt]

> ... every byte was a precious commodity.

Hence the Y2K problems.

Andy
&quot;Logic is invincible because in order to combat logic it is necessary to use logic.&quot; -- Pierre Boutroux
&quot;A computer program does what you tell it to do, not what you want it to do.&quot; -- Greer's Third Law

 

[jrbarnett]

Andy,

<slightly off topic as it refers to operating systems rather than languages>
I wonder if the same thing will happen towards 2038 when all the 32 bit machines with date/time stored as long variables from 1 Jan 1970 00:00 rollover back to 1941 (or something around that time)...
What's the likelihood of not having had mass 64 bit rollouts by then, or large amounts of 32 bit code still in use.
</slightly off topic as it refers to operating systems rather than languages>

Could it end up being my generations pension provider?

John

 

[donttreadonme]

You could also say that if they run out of SSN's then they are in trouble because almost all apps have space for 9 digits.

People could make a killing if they could convince and market this &quot;stuff&quot; to those paying for it!

 

[lionelhill]

ohje, brings back &quot;happy&quot; memories of the Acorn Atom with its 2K of memory, 0.5K for user programs. Basic abbreviated to
10 F.A=1TO12
20 PR.A*5
30 N.
40 E.
or letters to that effect. Yuk yuk yuk. But it was still a nice little machine, and I'm still proud of getting moonlander into 256 bytes...

 

[AndyWatt]

jrbarnett

What's the likelihood? Damn good, if the last cock-up was anything to judge by. It always amazes me how short-sighted everyone in business is.

lionelhill

My first computer was a Sinclair ZX-81: 1KB internal memory, of which only 0.3KB was usable by the user - the rest was &quot;OS&quot;. Non-ASCII character set, &quot;touch-sensitive&quot; co-called keyboard, etc., etc. Oh they were the days... Mind you, nostalgia isn't what it used to be.

Andy
&quot;Logic is invincible because in order to combat logic it is necessary to use logic.&quot; -- Pierre Boutroux
&quot;A computer program does what you tell it to do, not what you want it to do.&quot; -- Greer's Third Law

 

[dilettante]

Date/Time values have been stored as double-precision floating-point values in most modern Microsoft products and programming environments for some time: those using the Automation (OLE) date/time format.

The troublemaker is C/C++, which has a tendency toward the simplistic - though of course for a number of (usually) valid reasons. In this case the problem is historical. Fundamental C libraries were &quot;cast in stone&quot; only somewhat later than Cobol 2-digit year practices became de rigeur in the last century. Luckily, alternatives exist even for C/C++ programmers.

One brief item on this can be found at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnguion/html/msdn_090798a.asp

 

[theoxyde]

donttreadonme:
You could also say that if they run out of SSN's then they are in trouble because almost all apps have space for 9 digits.

Not only that, but SSNs aren't guaranteed to be unique. SSNs of dead people can be re-used at a later date -- but to date it hasn't been necessary. Think of all the databases with SSN fields that have uniqueness constraints on them...

 

[chiph]

The SSN isn't guaranteed to be unique even for the non-dead among us. There was a case where two women were born on the same day in the same hospital and had similar names. Of course, one grew up to be an outstanding citizen and the other wrote bad checks & had other bad habits.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first