Time for a new programming language paradigm
-
After two decades of cobol I am ready to chuck it out the window
After three decades of COBOL and more languages than I have fingers and toes, COBOL still is the language that comes the closest to the ideal that rjmoses described.
-
So... what you want is a common business oriented language? COBOL it is!
COBOL was the first thing that came to my mind. After working through all of the fancy toy languages from Lisp to C#, it still remains the most readable and "natural" in my experience.
-
Not to be a smart-a$$, but if you failed English, how can I as a user/buyer/customer/manager of your software be reasonably assured that you understood the requirements well-enough to implement them accurately?
I've only met one project managers, one client, and two senior developers capable of giving concise requirements. If a client say "this needs to be for each item", when really they mean "this needs to be shared by all items", then no understanding of English will help. Only an understanding on the clients business will help, that way you can understand what they mean even though it's not what they said.
-
After three decades of COBOL and more languages than I have fingers and toes, COBOL still is the language that comes the closest to the ideal that rjmoses described.
in your opinion
-
Not to be a smart-a$$, but if you failed English, how can I as a user/buyer/customer/manager of your software be reasonably assured that you understood the requirements well-enough to implement them accurately?
As a owner of two companies I don't see your point, and if I was stupid enough not to have someone go over my work before trying to sell an app well it wont make money will it. Grade 12 math ability in grade 2... English is for communications, it means nothing to the end result, unless English is the only way possible for you to understand something, then I would be worried more about you.
-
Smalltalk?
Indeed, SmallTalk ! I suspect many of the newly-minted prophets-with-visions on this thread would gasp if they knew what SmallTalk was capable of in 1968, and what software development tools were like at Xerox PARC at that time. Of course, the expen$ive hardware needed to run SmallTalk was not available to mere mortals.
“I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying : ‘I know all about it. I've already found it.’ As far as I'm concerned, the word means: ‘I am looking. I am hunting for it. I am deeply involved.’” Vincent Van Gogh
-
rjmoses wrote:
trace their origins back to the days when terseness was a desirable quality.
First, compilers (of which interpreters are just a subset) have deterministic requirements that cannot and should not be circumvented. Thus certain language constructs exist to insure that there is no ambiguity. And this is a feature of compilers (specifically compiler theory) and not just some misunderstanding by the author of the language. Second, terseness serves another need in that communications requires one to transfers thoughts to the computer. Increasing the verbosity would decrease the rate at which that can occur. Third one must be aware that no language can be perfect and no user of that language can be perfect either thus the compiler must strive to report errors to the best of its ability. At least in my experience doing that is one of the hardest parts of writing a compiler. Fourth languages are meant to serve different purposes and no one language can meet the needs of all possible uses without adding complexity that circumvents the original desire for simplicity.
rjmoses wrote:
Among other things, a New Programming Language should:
There are a large number new programming languages created every year and presumably many start with the idea that they are going to be 'better' than what already exists. Many, many, fail to achieve that goal. So many that one can bet that not even one language introduced within one year will ever achieve anymore than a very, very small niche (even that is due to promotion by the author rather than acceptance.) But you could venture forth into that realm yourself. However, if you haven't ever done so or haven't done so recently, you might want to learn a little about compiler theory first. It helps.
Very eloquently said, Sir !
“I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying : ‘I know all about it. I've already found it.’ As far as I'm concerned, the word means: ‘I am looking. I am hunting for it. I am deeply involved.’” Vincent Van Gogh
-
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 agree wholeheartedly with your sentiment about perversely curt languages. 1) Your 'FORTRAN' = example is highly flawed. It would read: IF (X.EQ.Y) ... No assignment confusion at all. 2) VB.NET is the answer to most of your woes. Not C#, as it suffers far too much from the legacy of the dreadful C & C++ abortions.
-
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.
The brace matching of Visual Assist is good enough that I usually don't need to do this. However, I often comment the else node in larger if constructs to keep track of the conditions needed to get there. Something like this:
if (a > 0)
{
if (b > 0)
{
...
}
else // a > 0 && b <= 0
{
...
}
}
else // a <= 0, b not tested
{
...
}The good thing about pessimism is, that you are always either right or pleasently surprised.
-
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.?
Well, the weak typing you suggest probably isn't less error-prone. Consider this for example.
S = 12; // no type specified -> int
.
.
.
S += 34; // arithmetic operation
.
.
.
print S; // writes: 46Now someone else comes and hijacks the variable in between.
S = 12; // no type specified -> int
.
.
.
String tmp = S; // save the variable
S = "Test";
...
S = tmp; // restore it, but S is "12" now
.
.
.
S += 34; // oops, now a concatanation
.
.
.
print S; // writes: 1234How long will it take you to find this?
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
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 TheArrayColborne_Greg wrote:
Here is an example of code, with no documentation, lets see if you can figure out what it does.
The fallacy in that statement is that it presumes that the reader only needs to know what the code does. However to maintain code one also needs to know 'why' code is doing what it it does. For example, in your code example 'why' is "Nothing" acceptable? Is the caller expecting that as a valid condition or is the caller going to error on that? Or perhaps it is up to the caller to decide that themselves? Additionally how does that work for a caller who wants to use the code but does not care how it is implemented? Where is the contract for the code defined? How can the caller be sure that even if the implementation changes that the contract will not? How will the maintainer be sure that they can make a modification to that code without breaking that code?
-
Colborne_Greg wrote:
Here is an example of code, with no documentation, lets see if you can figure out what it does.
The fallacy in that statement is that it presumes that the reader only needs to know what the code does. However to maintain code one also needs to know 'why' code is doing what it it does. For example, in your code example 'why' is "Nothing" acceptable? Is the caller expecting that as a valid condition or is the caller going to error on that? Or perhaps it is up to the caller to decide that themselves? Additionally how does that work for a caller who wants to use the code but does not care how it is implemented? Where is the contract for the code defined? How can the caller be sure that even if the implementation changes that the contract will not? How will the maintainer be sure that they can make a modification to that code without breaking that code?
In generic programming there is no why. As a programmer of 25 years, we in the field usually did not comment code or even tried to make the code readable, job security... That is retired code, otherwise I would not allow anyone else to see my work, as the concepts are experimental and solve just about every problem known in computing. Also if a programmer I hire creates a piece of code that was not well thought out in the first place, and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages. See I believe that if you can't understand code just by reading it, you need more experience, the readability should just be what gets the job done faster.
-
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 like you want something like VB for the dynamic if you want and begin/end instead of curlies. Or perhaps Ada - though it's a lot similar to Pascal - only much more pedantic. The trouble with the is/as/whatever "words" instead of operators - they can be very ambiguous. Especially when used as an equality comparer. About the == for equality and = for assignment ... I'm with you. I think that might have been the worst choice in C bar none. In this case I prefer the Pascal-like := assignment and the = for equality, only slightly better. But there are languages which figure out that = is used inside a condition and thus uses its equality override, while in other cases it's an assignment. So obviously it must be possible - just that C (and its progeny) has effectively removed that possibility from their syntax. Personally though, I don't mind characters too much. As long as they're as consistent as possible I'm fine with having a decent editor which matches them for me (indents / auto-close / etc.). It's when the "vocabulary" of these punctuation marks becomes huge with various "grammatical" rules where it becomes a pain in the @$$. Actually I hated having to type out the begin/end every single time when working in Pascal/Delphi, at least with VB some of it's automaticaly done from the IDE. But I still prefer the absolute consistency of Lisp over all other languages - everything is simply a function call, and you type it in that way too (no need to learn all sorts of different combinations for different aspects).
-
In generic programming there is no why. As a programmer of 25 years, we in the field usually did not comment code or even tried to make the code readable, job security... That is retired code, otherwise I would not allow anyone else to see my work, as the concepts are experimental and solve just about every problem known in computing. Also if a programmer I hire creates a piece of code that was not well thought out in the first place, and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages. See I believe that if you can't understand code just by reading it, you need more experience, the readability should just be what gets the job done faster.
Colborne_Greg wrote:
and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages.
All I can say is that you work in vastly different industries than I do. Or you don't work with anyone else. Code doesn't last "ages" because requirements don't. Requirements can change monthly (thankfully they don't change even more often than that.) Individuals work on certain code by themselves for years and then move on leaving someone else to figure it out. I write code with the goal of allowing someone else to be able to modify it and understand it because I know it will happen.
-
Colborne_Greg wrote:
and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages.
All I can say is that you work in vastly different industries than I do. Or you don't work with anyone else. Code doesn't last "ages" because requirements don't. Requirements can change monthly (thankfully they don't change even more often than that.) Individuals work on certain code by themselves for years and then move on leaving someone else to figure it out. I write code with the goal of allowing someone else to be able to modify it and understand it because I know it will happen.
How much does the code structure of SQL changes? Like never, and SQL is my competitor, Unidex which was invented in 2003 to index characters in memory, therefor every single column is indexed, and every record can have all or none of the columns in a table or extras only for that one record, it can also store pictures, songs and video inside a record. Code does last for ages, the code that doesn't wasn't written correctly.
-
How much does the code structure of SQL changes? Like never, and SQL is my competitor, Unidex which was invented in 2003 to index characters in memory, therefor every single column is indexed, and every record can have all or none of the columns in a table or extras only for that one record, it can also store pictures, songs and video inside a record. Code does last for ages, the code that doesn't wasn't written correctly.
Colborne_Greg wrote:
How much does the code structure of SQL changes?
The language? Since no one actually uses just SQL and rather they use a vendor specific extension, such as PL/SQL the question is rather moot. And PL/SQL and TSQL changes every couple of years. But even those don't change that much - but then that is far, far from what the vast majority of programmers do. The write with SQL they don't create the language itself.
Colborne_Greg wrote:
Code does last for ages, the code that doesn't wasn't written correctly.
As I already said, and pointed out, no it doesn't. There are applications that will not run on newer systems. There are new applications that will not run on old systems. I have personally worked on multi-million dollar projects that were delivered ahead of time and which were accepted by the customer and yet was never used at all by the customer. I have worked on a project that went through tens of millions of dollars and after 7 years the vast bulk of the software (and entire service suite offering) was abandoned. This is despite the fact that it was successfully processing 4 billion dollars in transactions at the end. I worked on the project that very, very likely allows your current phone to work and I know for a fact that although conceptually the system is the same the details have changed.
-
Colborne_Greg wrote:
How much does the code structure of SQL changes?
The language? Since no one actually uses just SQL and rather they use a vendor specific extension, such as PL/SQL the question is rather moot. And PL/SQL and TSQL changes every couple of years. But even those don't change that much - but then that is far, far from what the vast majority of programmers do. The write with SQL they don't create the language itself.
Colborne_Greg wrote:
Code does last for ages, the code that doesn't wasn't written correctly.
As I already said, and pointed out, no it doesn't. There are applications that will not run on newer systems. There are new applications that will not run on old systems. I have personally worked on multi-million dollar projects that were delivered ahead of time and which were accepted by the customer and yet was never used at all by the customer. I have worked on a project that went through tens of millions of dollars and after 7 years the vast bulk of the software (and entire service suite offering) was abandoned. This is despite the fact that it was successfully processing 4 billion dollars in transactions at the end. I worked on the project that very, very likely allows your current phone to work and I know for a fact that although conceptually the system is the same the details have changed.
again I state
Quote:
Code does last for ages, the code that doesn't wasn't written correctly.
Also look into generic programing Its what programmers should be doing, and when they do the code lasts forever. Oh look code really does last for a long time