Time for a new programming language paradigm
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
So you want to learn COBOL?
I wanna be a eunuchs developer! Pass me a bread knife!
-
All your answers are at The Osmosian Order[^]
cheers Chris Maunder
You beat me to it Chris. I read this title in CP daily news, & came rushing here to suggest the legendary Osmosian. Great! You have a good memory too ;). Hail Osmo!
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
Visual Basic .NET have almost all those features
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
As for missing equal signs, try Yoda conditions[^]! :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
20 years of programming in Cobol, C++, and html The language that meets your requirements is Visual Basic 2013. Everything that C++ can do Visual Basic 2013 can do. Here is an example of code, with no documentation, lets see if you can figure out what it does.
Public Interface iArray(Of someType)
Event ItemAdded(ByRef Item As someType)Sub AddRange(Range() As someType) Function Clear() As someType() Property Collected() As someType() Function Count() As Int64 Property Item(Index As Int64) As someType WriteOnly Property NewItem() As someType WriteOnly Property NewItems As someType() Property Populated As Boolean Function LastIndex() As Int64End Interface
<Serializable>
Partial Public Class Array(Of SomeType)
Implements iArray(Of SomeType)Private mCollected() As SomeType Private mPopulated As Boolean Public Event ItemAdded(ByRef Item As SomeType) Implements iArray(Of SomeType).ItemAdded Public Property Collected() As SomeType() Implements iArray(Of SomeType).Collected Get If mCollected Is Nothing Then mCollected = New SomeType() {} Return mCollected End Get Set(value As SomeType()) mCollected = value End Set End Property Public Sub AddRange(Range() As SomeType) Implements iArray(Of SomeType).AddRange Allocate(Collected, Range) Populated = True End Sub Public Shared Function Allocate(ByRef TheArray() As SomeType, ByVal Value As SomeType) As SomeType() Return Allocate(TheArray, Value, LastIndexOf(TheArray)) End Function Public Shared Function Allocate(ByRef TheArray() As SomeType, ByVal Values() As SomeType) As SomeType() Return Allocate(TheArray, Values, LastIndexOf(TheArray)) End Function Public Shared Function Allocate(ByRef TheArray() As SomeType, ByVal Values() As SomeType, ByRef Index As Int64) As SomeType() Try For Current As Int64 = 0 To Values.Length - 1 Allocate(TheArray, Values(Current), Index + Current) Next Catch End Try Return TheArray End Function Public Shared Function Allocate(ByRef TheArray() As SomeType, ByVal Value As SomeType, ByRef Index As Int64) As SomeType() Try TheArray(Index) = Value Catch ReDim Preserve TheArray(Index) TheArray(Index) = Value End Try Return TheArrayIt does create a maintenance hell ;P Seriously though: you can write undocumented code in any language. And it is never a good idea!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
If it was easy, everybody could it it! But on a more serious note, not using Visual Studio is a choice... For the hourly costs of developers (at least in the US), its worth the money to equip people with the best tools to accomplish work. And before going off on costs, there are free versions of VS. Hogan
snorkie wrote:
If it was easy, everybody could it it!
Did Resharper help you fix that sentence? No? Then why didn't you use VS to write your posting? ;P On a more serious note: 1. VisualAssist beats Resharper and (Un)Intellisense on C++ coding (at least unmanaged C++ - no experience wrt managed C++/CLI). 2. I do miss quite a few official standard C++11 features that VS still doesn't support. And I hate to figure out the exact syntax on certain template constructs with virtually no documentation on how to do properly (or at all)! (E. g. defining a template friend function inside a class) 3.
snorkie wrote:
And before going off on costs, there are free versions of VS.
... which don't support Resharper (or any other plugins) I do agree that VS is a great tool. But for some people it may not be the right one.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Sounds like a reason to requisition a larger monitor[^] :laugh:
Wow, at >8000$ for a smartphone resolution screen? Seriously? :wtf:
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Let's see.. there must be a relevant XKDC... oh, yeah, this'll do: http://xkcd.com/927/[^] :-D Such language should not be English-centric like most of today's languages; rather each developer should be able to view and edit the code in his own chosen language. (And formatted as the individual likes as well.) In fact, I think a new language should be XML-based with the IDE applying styling and such as specified by the user. :-D Of course, I would never use such a language, I'd stick with good old C#.
You'll never get very far if all you do is follow instructions.
Algol-67 was defined in terms of abstract syntax elements that could be represented using any suitable set of concrete symbols. I never saw much Algol-67 source code, but most of what I have seen used German keywords. (Algol-67 never caugth on - it was way ahead of its time. Even today, 47 years later, it would definitely be descibed as a very advanced language. I haven't looked at the specification for a while, but I am sure that some of its useful features are still missing from today's languages.) Maybe it was Algol-67 that inspired us when we as students made a Norwegian version of Pascal. It really was a simple word replacement program replacing MEDAN with WITH, BYRJ with BEGIN and STOGG with END (those who know Norwegian will see that we chose the dialect-based Norwegian variant), writing it to a temporary file and invoking the standard compiler on that temporary one. It worked perfectly as long as you in you user defined symbols stayed away from both the Norwegian and English reserved words.
-
Eddy Vluggen wrote:
rjmoses wrote:
- The language should be portable.
It's not the language that decides on what platforms it will be implemented. VB6 will never appear on Linux without starting a major war.
Every language* is portable, but not every language gets ported everywhere. * With the possible exception of the various assembly languages, but I suspect that even they could be compiled for a system they weren't intended for, perhaps with some limitations, but I'm no expert on that.
You'll never get very far if all you do is follow instructions.
-
It looked like a description of a BASIC to me :laugh:
PB 369,783 wrote:
I just find him very unlikeable, and I think the way he looks like a prettier version of his Mum is very disturbing.[^]
My thoughts exactly, except portability part. I work in VB.NET, have weak typing, good descriptive code etc... And recently I had a discussion with a colleague who prefers C# who espouses "real" programming, symbols instead of words for start/end of function etc...until we got to code review and I got to see: while () { ... ... if () { ... ... break; } // end if ... } // end while :-\ I didn't call him on it, really :cool:
I intend to live forever. Or die trying.
-
rjmoses wrote:
trace their origins back to the days when terseness was a desirable quality.
It still is. A decent C# class uses less characters to convey the same info as written in Object Pascal. Less characters to convey the same info - do you really need a "begin" and an "end" block?
rjmoses wrote:
Be clear and obvious in describing the functionality of the module.
When is something obvious? If you've ever hunted a swallowed exception in VB6, you'll know that this is not possible. Code should be unambigious, simple and clean. It should not become an exercise to omit documentation.
rjmoses wrote:
- The language should be portable.
It's not the language that decides on what platforms it will be implemented. VB6 will never appear on Linux without starting a major war.
rjmoses wrote:
- The code should be almost self-documenting.
Only if you're not coding, but scripting. That means that we'd limit this "programmer" to an IDE like MS Access. You'd never get InterOp or call the WinAPI. You'd never get a pointer.
rjmoses wrote:
- The language should incorporate most commonly-used functionality.
I've yet to meet the (broadly used) language that doesn't. Type-safety is something valuable - suggesting to remove it would be a step back.
rjmoses wrote:
- And, finally, it should be easily extensible.
A language? Please not; how would your old code react to changes? Can you oversee whether or not your change "breaks" something? Sorry, but only MS Access has these properties. I don't see it being used in the same way we use programming languages.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
A decent C# class uses less characters to convey the same info as written in Object Pascal. Less characters to convey the same info - do you really need a "begin" and an "end" block?
If you are looking for terseness, go APL. On a more moderate scale: What is really the purpose of those parentheses around if conditions, while conditions and for loop specification? Pascal can make due without them. Why do you have to double up the equals sign? Pascal can make due without that. Why do you have to double up all logical operators? The answer: Because the language "designers" didn't have a clue about language design. Why do you have this ugly try-catch mess? In Chill, any statement may include an exception handler before its closing semicolon; it doesn't have to be pre-announced. The presence of an ON clause implies exception handling; you don't need to pre-announce it. Why do you have to explicitly declare that "this is the end of the handling of this alternative", when the specification of the next alternative follows immediately? In Pascal you don't. Why do you have to enclose exception handling in braces? The braces must , unconditionally, be there, but Chill makes due without them. A general rule in Pascal and its derivatives is that {...} is a block, and a simple statement is a block, so wherever a block is called for, a simple statement can be used. Why to you have to include the body of a switch statement in braces, creating two nesting levels (the second one is each of the alternatives) when there logically is only one? etc. etc. Terseness is to remove from the language selected keywords and markers on your private hate list. The keywords/markers on someone else's hate list that is not on yours, you might fiercely defend as a way to improve readability, provide redundance to catch errors etc etc. Very few people really sat down to "tersify" a language specification, removing ALL unneccessary blurb; they use terseness as an argument to defend their own hate list.
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
Most of the problems you describe are the reason why coding guidelines and code reviews exist. If you choose not to use coding guidelines, or don't bother to hold reviews to ensure guidelines are followed, many of these problems simply can't be avoided: a language definition can't stop a programmer from calling a variable
irather than, more descriptively,row_index. Only guidelines and reviews can achieve that! Some specific comments: 3) As pointed out above, variable naming and code documentation cannot be enforced by a language. 4) I disagree: Strong typing helps the compiler (or interpreter, whatever) to decide whether a given statement is ok or maybe a typo. It helps the compiler find many errors of the types you earlier described! The main reason for strongly typed languages is that they improve the automation of error detection in the code. It also helps people understand other people's code, specifically since documentation and sensible variable names cannot be enforced by a language: when you can look up the exact type of a variable, that alone may offer a hint what it is used for. Type information is the only part of code documentation that can be enforced through a language! If documentation is important to you, then you want strong typing! 5) Neither number formats nor definitions of formats are truly universal. You have to accept that anything relating to format either must be defined specifically, or will deliver different reults in different locations. 6) That is a direct conflict with 2: you can't dynamically create new types in a compiled language. That said, your example describes an entirely different situation: that your program can deal with an arbitrary external object. Short answer: impossible. Long answer: Hollywood lies! No you can't interface Alien Computer hardware with a run-off-the-mill lapktop! Not even if you're Jeff Goldblum!GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
BobJanova wrote:
if(a == 5) { DoSomeStuff(); }
Take away one '=' in the if statement, put it in a seldom used error recovery routine and you have the bug I spent six months chasing. The mental skills required to spot the difference between '=' and '==' is difficult overcome when you are under pressure. I also chased a bug where a statement was inserted between the closing parenthesis and the opening brace, thus changing the entire program flow. (if (a == b) dosomethingnew; { dosomething }; What I want is to be able to look at a piece of code and accurately comprehend the meaning, intention and function of what the original programmer was trying to convey. "if a is 5..." can be a lot clearer than "if (a=5)..." in many cases. And, I'm not suggesting allowing mixed language constructs that do the same thing, although that is not out of the picture. And, as you stated so well, the machine requires precision. I agree! The question I'm raising is: How can we design a programming language that is easier, more accurate, less error prone, easier to modify, etc.?
rjmoses wrote:
Take away one '=' in the if statement, put it in a seldom used error recovery routine and you have the bug I spent six months chasing. The mental skills required to spot the difference between '=' and '==' is difficult overcome when you are under pressure.
A good IDE like Visual Studio will catch that one, and many other errors, when debugging. With ReShaper installed it will catch it when typing.
-
BobJanova wrote:
if(a == 5) { DoSomeStuff(); }
Take away one '=' in the if statement, put it in a seldom used error recovery routine and you have the bug I spent six months chasing. The mental skills required to spot the difference between '=' and '==' is difficult overcome when you are under pressure. I also chased a bug where a statement was inserted between the closing parenthesis and the opening brace, thus changing the entire program flow. (if (a == b) dosomethingnew; { dosomething }; What I want is to be able to look at a piece of code and accurately comprehend the meaning, intention and function of what the original programmer was trying to convey. "if a is 5..." can be a lot clearer than "if (a=5)..." in many cases. And, I'm not suggesting allowing mixed language constructs that do the same thing, although that is not out of the picture. And, as you stated so well, the machine requires precision. I agree! The question I'm raising is: How can we design a programming language that is easier, more accurate, less error prone, easier to modify, etc.?
Fire up any text editor, compile the code below as pure C and you have what you asked for ...
#define IF if (
#define THEN ){
#define ELIF } else if (
#define ELSE } else {
#define ENDIF }
#define IS ==
#define EQUALS == -
rjmoses wrote:
Take away one '=' in the if statement, put it in a seldom used error recovery routine and you have the bug I spent six months chasing. The mental skills required to spot the difference between '=' and '==' is difficult overcome when you are under pressure.
A good IDE like Visual Studio will catch that one, and many other errors, when debugging. With ReShaper installed it will catch it when typing.
In C / C++ the IDE cannot catch it, because it as an absolut correct statement ! Ever seen the simple strcpy() function:
void strcpy( char *source, char *destination )
{
while (*destination++ = *source++ )
;
} -
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
Something is wrong if you're spending 6 months chasing "==" for "=". With the debuggers/IDEs of today I find chasing them (no, they never go away [someone elses code]) to be fairly efficient. As for the rest, well, it's the same old programmer-preference thing. No one thing or set of things will satisfy everyone. I believe Abe Lincoln said that. Personally, I really like braces vs. BEGIN/END. Any anyone who feels the need for "// end of some-block" has written a block that is too long; just break it out into smaller chunks/methods/functions.
-
As for missing equal signs, try Yoda conditions[^]! :)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
This will not help you if you are comparing two variables ...
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
Sounds good to me. I have to admit skepticism, though. Even well design systems can be derailed by idiots (or by intelligent noncompliance), or otherwise "gamed" to work against itself. I see it all the time in every human system I encounter. Figure out how to address that factor in the design, and you've got something. </soapbox>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
-
This will not help you if you are comparing two variables ...
True. But I've found that to be an exception. Most often tests for equality test for a certain (constant) value, whereas tests between actual variables check the order, i. e. they use
<or>rather than==. I've been using Yoda conditionso for more than 20 years, and I can't recall the last time I couldn't apply it. It happens, but it's extremely rare.GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Just spent the better part of two weeks trying to find a bug in a Linux bash script (missing ".") and I'm tired of looking for things like a missing equal sign in the middle of an C if statement, missing period in a PHP script, lower case variable name mixed with an upper case variable name, missing brace in a C++ object, undelared function or operator overloading....get my drift?...in other people's code. (Being the perfect programmer, I never make those kinds of mistakes! And I have swamp property if you're interested.) All too many programming errors are occurring because programming languages, like C, C++, java, etc., trace their origins back to the days when terseness was a desirable quality. Printing a program listing on an ASR 33 teletype at 10 CPS on a single threaded machine made using braces in C if statements instead of a clear if-then-else-endif highly desirable. (Remember the origins of C?) Those extra 9 characters took TIME to read in and to print out. And then there's issues of language diversity. C, C++, PHP, Java, Javascript, HTML, CSS, SQL, and other languages--what works where? So, here's a few of my thoughts: (And please don't be too anal about my examples--I really want to hear how programming languages could be advanced so that I can be more productive.) Among other things, a New Programming Language should: 1) Be clear and obvious in describing the functionality of the module. The resulting code should almost be language like. A sentence like "If (A equals 10) then print B as "xx.xx" else B = 0 end". But, that statement might also be written in a more mathematical syntax (like Fortran) as "If (A = 10) then....". Note the "=" in the second statement does NOT have the implied assignment and resulting TRUE logical decision (Spent 6 months chasing THAT bug!). 2) The language should be portable. The language should be executable as an interpreted, compiled, scripted or shell'ed running under most commonly available OS's and browsers. Perhaps Interpreted for testing, Compiled for execution speed, scripted for portability or shell'ed for utility work. Take features from scripting languages like Powershell, bash, incorporate execution speed of C, objectivity of Java or C++ and put them under one roof. Write a module that runs under IE, Firefox, Chrome, Opera, Windows, Linux, BSD, OS X, or anything else. 3) The code should be almost self-documenting. Nothing I hate worse than to have to go looking for the a type declaration, a
I have been in the field for 40 years and have worked fluently in over 12 different languages and their off-shoots including PROLOG. Hands down, the two best languages I have worked with have always been BASIC and Pascal. However, for ease of use and capability you cannot beat BASIC. There is no need for a new language since nothing new will be able to do anything better than the existing language stalwarts... At least not until a completely new architecture is available for development.
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com