If new languages had some degree of new design or design likely implemented as truly thought through as a language, I'd agree with your assessment. However, over the last decade or so, almost every new language has done the "we've got some new ideas, let's implement them using C syntax as the base". As such, it's hard to find innovation. It isn't C's quirks that I object to, it's the blind assumption that unless there's a good reason tied to the purpose of the new language, it should always include all of those quirks as though they were both intuitively obvious and blindingly close to perfect. Note the blind defense of such meaningless constructs such as the curly brace. People have stopped thinking about language and just accept C as some sort of religious doctrine.
I started with punch cards as well and, frankly, I've never found any reason to associate masochism with quality. If a programming environment makes it harder for me to make typos, great. I can spend more time making sure the logic is right. It isn't a really good use of my time spending my time finding the spelling errors when the computer can do a better job for me.
The question isn't whether you have automatic enforcement of case rules, it's whether you can have two object in the program that are represented by names that only differ by case of one or more letters.
In your example, having Foo denote a class is great. Having foo denote a method is great. Having the editor (or even just the compiler) enforce those rules is fine.
Having both Foo and foo in the same program is just waiting for trouble and making life more complicated for no good reason.
Of course it's a contrived example. A real example would be a couple of pages of code with dozens of curlys and parens on each page printed out in a small font that has, typically, only a few pixels different between (, { and [
But I didn't think all of slashdot would want to read a 200 line post just to make a point.
No. That's case preservation and is typically enforced by a good editor (Even QuickBASIC 4 in 1988 had it). Case sensitivity is when MyVar and MYVAR refer to different objects in the system.
Actually, if I look through a page of case-insensitive code for Buf_Check, I still won't read symbols like foo_this or BAR_THAT. The difference is that I won't have to worry about looking for Buf_Check and missing buf_Check.
On the contrary, case in human languages generally does not change meaning. A Chair is still a chair. It is not by it's case suddenly a fish.
As for word shape, while that has great value in ludic reading it has virtually none in arbitrary names such as those used in coding where meaning is not identical to a symbolic shape learned by the brain to represent a concept. To use your example, there IS no learned shape memory for Buf_Check any more than there is for buf_check or for that matter BufCheck or bufcheck or BUFCHECK.
For those of you not familiar with non-C based languages, the reserved words only being reserved in context comes from PL/I. C compilers still don't have it although with try/catch/finally they're getting sort of in the neighborhood of PL/I and REXX ON events for error trapping.
Just to be picky, traditionally (it may not be required now) all REXX programs start with a comment line so VM's script processor will know not to execute it as EXEC.
Oh, and just to be precise, if they use a corrected base, perhaps it should be labeled that they're extending ECMAScript or ECMA Standard 262 Scripting Language or JScript since the name JavaScript was just a silly attempt for Netscape to try to glom on to SUN's Java PR machine by renaming their LiveScript language despite Java and JavaScript having nothing in common except being C derivatives written by companies that hated Microsoft.
Maybe this time they'll actually not think that two digit years are automaticaly in the 20th Century.
Or, heaven forbid, they'll actually use the actual standards based (and *GASP* Microsoft sponsored) ECMAScript as a base which had already fixed their embarassingly humerous (for a 1995 language) Y2K bug...
Actually, that's one of the arguments FOR case insensitivity as well. The complexity of representation of symbols means that a simple comparison (the one real advantage of case sensitivity) is in reality useless since canonicalization rules are far too complex to prevent mismatches. Think Unicode vs ASCII vs HTMLEncoded vs URLEncoded vs Shift-JIS versions of the same character and you get the idea.
Thinking C style "compare two consecutive byte streams of memory until you hit a null" as an string comparison these days makes as little sense as thinking 5-bit BAUDOT code. (And, frankly, causes a huge percentage of buffer overflow attacks)
Case sensitivity does not mean you can't use mixed case, it just means you don't support multiple meanings based on case.
Three-part loop construct: Perhaps the stupidest coding convention since it allows indeterminate and complex logic inside the structure of the construct rather than writing code that logically follows its design
Curly braces: Tell me, would you pick a character that's shifted as one of the most commonly used? How about a pair that are, in many fonts, virtually identical to another grouping set? Say, this: {(({(({()}))})})}? Tell me, on a quick glance, what's the error?
What that really asks is; is it a good idea to have a constant named MYBIGNUM, a function named MyBigNum and a variable named myBigNum all in the same program since there's no conflict to you using whatever convention you want unless there'd be a naming conflict in the same program.
Frankly, I'd consider that to be unmaintainable and totally dependant on everyone ever using your program to have exactly the same coding convention. And the, somebody would probably also come up with mybignum, MyBiGnUm and mYbIgNum as well. The meaning of which is as intuitively obvious as any other arbitrary coding convention.
If you do declare variables then the compiler can perform validation that it otherwise can't and catch errors at compile time. It's a *good* thing.
Object Oriented Programming theory would disagree with you. While it's a "*good* thing" for the compiler writer it's a bad thing for the programmer. One of the four original tenets of OOP is that everything in an OOP system uses LATE BINDING so that the system can be flexible. It's only because Stroustrop couldn't get that working when he was writing his semi-OOP preprocessor to C (C++, perhaps you've heard of it) that this key part of OOP started getting ignored.
The world doesn't begin and end with what can be done easily in a C derivative language. Take a look at Smalltalk-72 to see what OOP was supposed to be.
Mansfield's KEDIT is a port of the old VM editor XEDIT. You might want to search for other XEDIT ports although KEDIT was the best for years. There used to be quite a few out there. In fact there were enough that PC Magazine did a comparison of XEDIT clones. (btw: I personally don't like the XEDIT family but editors are a very individual thing)
>You don't need to declare or predefine your variables.
Isn't this a bad thing?
For some problems it's a bad thing, for others it's a good thing. It's actually a good thing on some small projects as it adds some flexibility and the cost of accidental variable declaration doesn't rear its head until the project gets large or gets multiple people working on it.
And your example is, by the way, also a great explanation why case sensitivity is a bad idea. For example, "I start using a variable named 'myBigNum' then the next day I mistakenly start using a 'MyBigNum' variable even though I mean the same thing."
Yep, I'd forgotten about IBM PC DOS 7.0 (as had everyone else). Remember that by the time it shipped nobody who was still using DOS as their OS was doing upgrades. DOS based systems were legacy project that were being touched as little as possible by then.
As for cool things in REXX, take a look at the PARSE PULL command. Very, very handy for writing user input routines in a scripting system.
Is anyone else uncomfortable with case insensitive languages? That was one of the things I'd hoped REXX would address when it came out as a replacement for EXEC, I've always thought aside from the confusion factor of ignoring case (ever lose a file in Windows because of this?), not distinguishing case throws away an entire semantic of elegance for creating better and more maintainable code.
No, actually you misplacing files because the case wasn't what you expected on an old Windows 3.x system was the result of using badly ported case-sensitive tools in a case-insensitive environment. (btw: Windows has always been case-insensitive and case-preserving in the NT codebase)
Case sensitivity is, frankly, not only useless but flat out stupid and a vast step backward as it doesn't match human readable languages or other human experience thus breaking the paradigm of programming language as translator between human intent and hardware inflexibility. It leads to huge numbers of easily avoidable errors, increased maintenance time and cost and increased overall development time while providing no benefit. Sure, it makes life a little easier for lazy compiler writers and it's habit in people who've never bothered to learn any languages not derived from C but the point of a programming language is to make things easier for the human and not the compiler. Read some code in PL/I or ALGOL or LISP or Smalltalk or SNOBOL or, for that matter, REXX and you may expand your idea of what a language can be.
Other signs of C-blinders are thinking that three-part loop constructs are a good thing, that curly braces are actually either ergonomic or intuitive or that semicolons are how you end sentences;
First of all, REXX is hardly the first popular scripting language, there were lots of them before it. REXX was designed as an alternative to EXEC2 which was a replacement for EXEC and that's just on IBM's VM mainframe systems. Listing other scripting systems prior to REXX is left as an exercise for the reader.
As for history, REXX wasn't developed as an official IBM project. It was developed as an internal tools project by Mike Cowlishaw at IBM's research lab in Hursley, England (the VENTA lab) because EXEC2 basically sucked. It was distributed on IBM's internal tools system (VMTOOLS and IBMVM) and became hugely popular inside IBM.
It was made available as an unsupported tool through the IBM VM user group and became so popular that despite IBM managment wanting EXEC2 to be the "official" scripting language, nobody in their right minds used EXEC2 and REXX became almost universal. Pressure from their commercial VM/CMS and VM/XA users forced IBM to make REXX a supported product.
In the mid 1980s, a PC version became available internally on the IBMPC and PCTOOLS systems and quite a few internal tools were written in REXX but despite internal popularity, IBM didn't release the PC version of REXX until much later when a vastly expanded (some would say bloated) version was released as a fairly expensive commercial product.
As a side note, REXX was released as a scripting language for PCs with later versions of OS/2 but by that time OS/2 was insignificant in the PC industry.
One unrelated note, Cowlishaw is also famous as the keeper of the IBM Jargon Dictionary - a tongue firmly in cheek listing of IBMisms.
Slashdot Mirror
If new languages had some degree of new design or design likely implemented as truly thought through as a language, I'd agree with your assessment. However, over the last decade or so, almost every new language has done the "we've got some new ideas, let's implement them using C syntax as the base". As such, it's hard to find innovation. It isn't C's quirks that I object to, it's the blind assumption that unless there's a good reason tied to the purpose of the new language, it should always include all of those quirks as though they were both intuitively obvious and blindingly close to perfect. Note the blind defense of such meaningless constructs such as the curly brace. People have stopped thinking about language and just accept C as some sort of religious doctrine.
Funny, I'm quoting Alan Kay from private conversation at OOPSLA '87.
Nonsense.
I started with punch cards as well and, frankly, I've never found any reason to associate masochism with quality. If a programming environment makes it harder for me to make typos, great. I can spend more time making sure the logic is right. It isn't a really good use of my time spending my time finding the spelling errors when the computer can do a better job for me.
The question isn't whether you have automatic enforcement of case rules, it's whether you can have two object in the program that are represented by names that only differ by case of one or more letters.
In your example, having Foo denote a class is great. Having foo denote a method is great. Having the editor (or even just the compiler) enforce those rules is fine.
Having both Foo and foo in the same program is just waiting for trouble and making life more complicated for no good reason.
Of course it's a contrived example. A real example would be a couple of pages of code with dozens of curlys and parens on each page printed out in a small font that has, typically, only a few pixels different between (, { and [
But I didn't think all of slashdot would want to read a 200 line post just to make a point.
No. That's case preservation and is typically enforced by a good editor (Even QuickBASIC 4 in 1988 had it). Case sensitivity is when MyVar and MYVAR refer to different objects in the system.
Actually, if I look through a page of case-insensitive code for Buf_Check, I still won't read symbols like foo_this or BAR_THAT. The difference is that I won't have to worry about looking for Buf_Check and missing buf_Check.
On the contrary, case in human languages generally does not change meaning. A Chair is still a chair. It is not by it's case suddenly a fish.
As for word shape, while that has great value in ludic reading it has virtually none in arbitrary names such as those used in coding where meaning is not identical to a symbolic shape learned by the brain to represent a concept. To use your example, there IS no learned shape memory for Buf_Check any more than there is for buf_check or for that matter BufCheck or bufcheck or BUFCHECK.
And the time it took to find that shows my point about readability of ]}) ...
For those of you not familiar with non-C based languages, the reserved words only being reserved in context comes from PL/I. C compilers still don't have it although with try/catch/finally they're getting sort of in the neighborhood of PL/I and REXX ON events for error trapping.
Just to be picky, traditionally (it may not be required now) all REXX programs start with a comment line so VM's script processor will know not to execute it as EXEC.
That would be case preservation (which is good) not case sensitivity (which is evil)
Sheesh. And then I blew the parens. Which proves another of my points...
You forgot the obvious:
...
if (MyBigNum(myBigNum)) == MYBIGNUM
Oh, and just to be precise, if they use a corrected base, perhaps it should be labeled that they're extending ECMAScript or ECMA Standard 262 Scripting Language or JScript since the name JavaScript was just a silly attempt for Netscape to try to glom on to SUN's Java PR machine by renaming their LiveScript language despite Java and JavaScript having nothing in common except being C derivatives written by companies that hated Microsoft.
Maybe this time they'll actually not think that two digit years are automaticaly in the 20th Century.
Or, heaven forbid, they'll actually use the actual standards based (and *GASP* Microsoft sponsored) ECMAScript as a base which had already fixed their embarassingly humerous (for a 1995 language) Y2K bug...
Actually, that's one of the arguments FOR case insensitivity as well. The complexity of representation of symbols means that a simple comparison (the one real advantage of case sensitivity) is in reality useless since canonicalization rules are far too complex to prevent mismatches. Think Unicode vs ASCII vs HTMLEncoded vs URLEncoded vs Shift-JIS versions of the same character and you get the idea.
Thinking C style "compare two consecutive byte streams of memory until you hit a null" as an string comparison these days makes as little sense as thinking 5-bit BAUDOT code. (And, frankly, causes a huge percentage of buffer overflow attacks)
Case sensitivity does not mean you can't use mixed case, it just means you don't support multiple meanings based on case.
Three-part loop construct: Perhaps the stupidest coding convention since it allows indeterminate and complex logic inside the structure of the construct rather than writing code that logically follows its design
Curly braces: Tell me, would you pick a character that's shifted as one of the most commonly used? How about a pair that are, in many fonts, virtually identical to another grouping set? Say, this: {(({(({()}))})})}? Tell me, on a quick glance, what's the error?
What that really asks is; is it a good idea to have a constant named MYBIGNUM, a function named MyBigNum and a variable named myBigNum all in the same program since there's no conflict to you using whatever convention you want unless there'd be a naming conflict in the same program.
Frankly, I'd consider that to be unmaintainable and totally dependant on everyone ever using your program to have exactly the same coding convention. And the, somebody would probably also come up with mybignum, MyBiGnUm and mYbIgNum as well. The meaning of which is as intuitively obvious as any other arbitrary coding convention.
If you do declare variables then the compiler can perform validation that it otherwise can't and catch errors at compile time. It's a *good* thing.
Object Oriented Programming theory would disagree with you. While it's a "*good* thing" for the compiler writer it's a bad thing for the programmer. One of the four original tenets of OOP is that everything in an OOP system uses LATE BINDING so that the system can be flexible. It's only because Stroustrop couldn't get that working when he was writing his semi-OOP preprocessor to C (C++, perhaps you've heard of it) that this key part of OOP started getting ignored.
The world doesn't begin and end with what can be done easily in a C derivative language. Take a look at Smalltalk-72 to see what OOP was supposed to be.
Mansfield's KEDIT is a port of the old VM editor XEDIT. You might want to search for other XEDIT ports although KEDIT was the best for years. There used to be quite a few out there. In fact there were enough that PC Magazine did a comparison of XEDIT clones. (btw: I personally don't like the XEDIT family but editors are a very individual thing)
>You don't need to declare or predefine your variables.
Isn't this a bad thing?
For some problems it's a bad thing, for others it's a good thing. It's actually a good thing on some small projects as it adds some flexibility and the cost of accidental variable declaration doesn't rear its head until the project gets large or gets multiple people working on it.
And your example is, by the way, also a great explanation why case sensitivity is a bad idea. For example, "I start using a variable named 'myBigNum' then the next day I mistakenly start using a 'MyBigNum' variable even though I mean the same thing."
Yep, I'd forgotten about IBM PC DOS 7.0 (as had everyone else). Remember that by the time it shipped nobody who was still using DOS as their OS was doing upgrades. DOS based systems were legacy project that were being touched as little as possible by then.
As for cool things in REXX, take a look at the PARSE PULL command. Very, very handy for writing user input routines in a scripting system.
Is anyone else uncomfortable with case insensitive languages? That was one of the things I'd hoped REXX would address when it came out as a replacement for EXEC, I've always thought aside from the confusion factor of ignoring case (ever lose a file in Windows because of this?), not distinguishing case throws away an entire semantic of elegance for creating better and more maintainable code.
No, actually you misplacing files because the case wasn't what you expected on an old Windows 3.x system was the result of using badly ported case-sensitive tools in a case-insensitive environment. (btw: Windows has always been case-insensitive and case-preserving in the NT codebase)
Case sensitivity is, frankly, not only useless but flat out stupid and a vast step backward as it doesn't match human readable languages or other human experience thus breaking the paradigm of programming language as translator between human intent and hardware inflexibility. It leads to huge numbers of easily avoidable errors, increased maintenance time and cost and increased overall development time while providing no benefit. Sure, it makes life a little easier for lazy compiler writers and it's habit in people who've never bothered to learn any languages not derived from C but the point of a programming language is to make things easier for the human and not the compiler. Read some code in PL/I or ALGOL or LISP or Smalltalk or SNOBOL or, for that matter, REXX and you may expand your idea of what a language can be.
Other signs of C-blinders are thinking that three-part loop constructs are a good thing, that curly braces are actually either ergonomic or intuitive or that semicolons are how you end sentences;
REXX's history isn't even really mentioned.
First of all, REXX is hardly the first popular scripting language, there were lots of them before it. REXX was designed as an alternative to EXEC2 which was a replacement for EXEC and that's just on IBM's VM mainframe systems. Listing other scripting systems prior to REXX is left as an exercise for the reader.
As for history, REXX wasn't developed as an official IBM project. It was developed as an internal tools project by Mike Cowlishaw at IBM's research lab in Hursley, England (the VENTA lab) because EXEC2 basically sucked. It was distributed on IBM's internal tools system (VMTOOLS and IBMVM) and became hugely popular inside IBM.
It was made available as an unsupported tool through the IBM VM user group and became so popular that despite IBM managment wanting EXEC2 to be the "official" scripting language, nobody in their right minds used EXEC2 and REXX became almost universal. Pressure from their commercial VM/CMS and VM/XA users forced IBM to make REXX a supported product.
In the mid 1980s, a PC version became available internally on the IBMPC and PCTOOLS systems and quite a few internal tools were written in REXX but despite internal popularity, IBM didn't release the PC version of REXX until much later when a vastly expanded (some would say bloated) version was released as a fairly expensive commercial product.
As a side note, REXX was released as a scripting language for PCs with later versions of OS/2 but by that time OS/2 was insignificant in the PC industry.
One unrelated note, Cowlishaw is also famous as the keeper of the IBM Jargon Dictionary - a tongue firmly in cheek listing of IBMisms.