Time for a new programming language paradigm
-
All of my code is self documenting enough that maintenance well never happens because it was written clear and concise to begin with.
Just joking - I do concede that it's remarkably well structured for a BASIC program. Bonus points for using declarative variable names! :thumbsup: But don't expect me to have a look and understand what it really does - I'm sure I could do it, but I've never programmed in VB and don't intend to start now ;P
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 joking - I do concede that it's remarkably well structured for a BASIC program. Bonus points for using declarative variable names! :thumbsup: But don't expect me to have a look and understand what it really does - I'm sure I could do it, but I've never programmed in VB and don't intend to start now ;P
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[^]
It simplifies the use of arrays to be allowed to be controlled more like collections without the overhead. That is a self contained module of a 4000 line program. No basic program here.
-
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:
"if a is 5..." can be a lot clearer than "if (a=5)..." in many cases.
Honestly, no. Does "is" mean "has same value as"? Is it a value comparison or a reference comparison? Or does it mean "is an instance of..." or "belongs to the same type/class/struct definition"? Or does it mean, which is what I would expect if we spoke plain English, "a and 5 are simply two names for one single enity"? (After all, if A is 5 it means that A and 5 are the same object, like saying that Obama is the President of the USA and the President of the USA is Obama).
-
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've been working on this for a while. First, you may have noticed that all the innovation in software and languages is just really continuous re-invention of minor variations in existing languages and language paradigms. The "new" language is just another language with a not particularly well thought out hodgepodge of features that the author would like to see together in a language. There is no real innovation taking place in software languages today. I've been looking at PhD programs in CS and there's not really any real good movement towards the next generation software environment. Which is unfortunate. Thus, I am working on it. Why is there no forward movement in software? That I need to explain in my Software Innovation Psychology Theory which I am working on right now to produce first a concise booklet, an eBook, and then a video. In a nutshell, it is cause by people mistaking copycat innovation with true innovation (which is very rare). There are also a number of visualization and cognitive factors as well. And also the type of work in software does not really attract true innovators since most of the work is really grunt code work. So there are reasons why the current stasis exists. Now, on to what a next generation programming language will include/be like/encompass: 1. True Object based instead of just Object "oriented". 2. Combines database, software, and transport protocol into one. There will be no impedance mismatch, no dedicated conventional database servers as such, etc. 3. Definition based rather than procedural based. 4. Smart components instead of dumb controls. 5. Replacement of the conventional function argument passing mechanisms with a definition language based approach. This will eliminate function overloading and re-implement dynamic polymorphism and class overriding in more natural approach. 6. The new definition language will be expressible in both terse and verbose modes. Verbose mode is a very human readable (yeah!) while terse mode can be used to save space and bandwidth when necessary. 7. SQL will no longer be necessary. It will be replaced by a universal data definition language that brings software and data persistence together into one unity. 8. XML will be replaced by a human readable data definition form and format. I've built successful prototypes on this and am converting all of my current code to run with it. Fully human readable and writable. BTXML - Better Than XML! 9. The definition scripting language will not need to b
-
This?[^] [Edit] On a less idiotic note, I'm pretty sure I read somewhere that natural language processing on a machine is impossible because it would break one of the Goedel incompleteness theorems. I think the argument goes the machine needs the language to be consistent to actually run on a machine. On the other hand the language must also be complete to express the full range of ideas you might be able to have. :~
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.[^]
Even HTML defies this requirement :)
-
This?[^] [Edit] On a less idiotic note, I'm pretty sure I read somewhere that natural language processing on a machine is impossible because it would break one of the Goedel incompleteness theorems. I think the argument goes the machine needs the language to be consistent to actually run on a machine. On the other hand the language must also be complete to express the full range of ideas you might be able to have. :~
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.[^]
Keith Barrow wrote:
I'm pretty sure I read somewhere that natural language processing on a machine is impossible because it would break one of the Goedel incompleteness theorems.
Tell that to the GrandNagUs. :-D
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
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.?
The question I'd ask is why aren't you running lint (or an equivalent) on your codebase? Would find and flag both of these...
-
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.
I admit I do this nowadays in Delphi (three cycle, a case and a try..except down) - and remember Excel VBA, as it wrote If after End for me, while the Delphi IDE is unable to do it for me :) So long, VB haters...
-
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
Except for the interpreted part, it sounds like C/C++, but you need to use a modern compiler that whines about things like assignments in ifs (or maybe do a lint pass) and a modern IDE for it.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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 ==Thanks! Here's a set of C macros I found real useful that's along the same lines. I tripped them across 20 years ago when I had a programmer working for me that couldn't keep his braces balanced. I known I will take heat about these macros from certain types of people on this thread, but, remember, this is a problem some of us have been wrestling with since Day 1. So, for the purists in the group, be thankful for all your experience, but remember back to your early days and, if your were writing bug-free programs back then, you're welcome to comment. /* (e) is any valid C expression */ /* Uppercase is necessary because of the cursive processing of statements like "else" by the C pre-processor */ /* IF-THEN-ELSE-ELSEIF */ #define IF(e) { if (e) #define THEN { #define ELSE_IF(e) } else if (e) { #define ELSE } else { #define END_IF ;}} #define DO_N_TIMES(e) { int __Iii; for (__Iii = 0; __Iii < (e); __Iii++) { #define END_DO ;}} #define DO_UNTIL(e) { for (; !(e); ) { #define END_UNTIL ;}} // END_DO will work also #define DO_WHILE(e) { while (e) { #define END_WHILE ;}} // END_DO will work also #define FOR(e) { for (e) { #define END_FOR ;}} #define CASE(e) { switch (e) { #define CASE_OF(e) case e: { #define DEFCASE default: { #define DEFAULT default: { #define END_COF } break; #define END_CASE }} #define BEGIN { #define END } #define AND && #define OR || #define NOT ! #define EQ == #define NE != #define LT < #define GT > #define LE <= #define GE >= #define BAND & #define BOR | #define BXOR ^ #define BNOT ~ #define LSHF << #define RSHF >> #define INC ++ #define DEC -- #define MOD % #define ADDR(e) &(e) #define PTR(e) *(e) #define BOOLEAN unsigned char #define BYTE unsigned char #define REAL double #define INTEGER int #ifndef TRUE #define TRUE 1 #define FALSE 0 #endif
-
Sounds like you really just want a compiler to be more helpful with errors. Tools like Resharper help with this in Visual Studio! Hogan
In a way, yes! What I'm really driving at is more along the lines of psychologically helpful. I read a study not that long ago that the average programmer is now producing 1.2 lines of code per man-day. I don't know if this correct or not, but it causes me to wonder "why?" and what could be done to change it. So my question becomes: What can we do differently?
-
All of my code is self documenting enough that maintenance well never happens because it was written clear and concise to begin with.
-
What you tell a computer to do must be precise. Computers are machines, they have no intelligence or subjectivity, and in the end everything we tell them to do comes down to bit twiddling in particular memory or disk locations. There are whole levels of existing code (OSs and byte code executors, then compilers) between you and that, but in the end that's what it comes down to, and in order to translate your code into those low level instructions for the computer, your code must be entirely unambiguous. Natural language is ambiguous, subjective and often imprecise and confusing. That's why mathematicians use a formal way of writing (equations and carefully phrased theorems/axioms/etc), rather than a normal talking language. And do you really want to be working in a code base where one person has typed
if(a == 5) { DoSomeStuff(); }
... and someone else
if a is 5 then dosomestuff end
?
I think the crux of the problem is that we need Service Pack 1 on the Human OS, but this runs the risk of breaking 'being human'. The alternative is the embedded artificial intelligence into all machines so they know to do what we 'meant', not what we 'said'.
-
In a way, yes! What I'm really driving at is more along the lines of psychologically helpful. I read a study not that long ago that the average programmer is now producing 1.2 lines of code per man-day. I don't know if this correct or not, but it causes me to wonder "why?" and what could be done to change it. So my question becomes: What can we do differently?
There is no one party at fault here... On the employee side, there is personal responsibility. There needs to be a desire to be a better developer and to work hard. On the employer side, they need to be more organized. I've heard and experienced issues with companies (mostly large ones) who hire people but don't utilize them anywhere near a person's capacity. I spent a few weeks waiting to get access to systems and be assigned work to do. I left because the job was not fulfilling. From my perspective, I should strive to be better each day. Secondly, mentor people around me that don't know as much. That was the main way I got up to speed. Hogan
-
I've been working on this for a while. First, you may have noticed that all the innovation in software and languages is just really continuous re-invention of minor variations in existing languages and language paradigms. The "new" language is just another language with a not particularly well thought out hodgepodge of features that the author would like to see together in a language. There is no real innovation taking place in software languages today. I've been looking at PhD programs in CS and there's not really any real good movement towards the next generation software environment. Which is unfortunate. Thus, I am working on it. Why is there no forward movement in software? That I need to explain in my Software Innovation Psychology Theory which I am working on right now to produce first a concise booklet, an eBook, and then a video. In a nutshell, it is cause by people mistaking copycat innovation with true innovation (which is very rare). There are also a number of visualization and cognitive factors as well. And also the type of work in software does not really attract true innovators since most of the work is really grunt code work. So there are reasons why the current stasis exists. Now, on to what a next generation programming language will include/be like/encompass: 1. True Object based instead of just Object "oriented". 2. Combines database, software, and transport protocol into one. There will be no impedance mismatch, no dedicated conventional database servers as such, etc. 3. Definition based rather than procedural based. 4. Smart components instead of dumb controls. 5. Replacement of the conventional function argument passing mechanisms with a definition language based approach. This will eliminate function overloading and re-implement dynamic polymorphism and class overriding in more natural approach. 6. The new definition language will be expressible in both terse and verbose modes. Verbose mode is a very human readable (yeah!) while terse mode can be used to save space and bandwidth when necessary. 7. SQL will no longer be necessary. It will be replaced by a universal data definition language that brings software and data persistence together into one unity. 8. XML will be replaced by a human readable data definition form and format. I've built successful prototypes on this and am converting all of my current code to run with it. Fully human readable and writable. BTXML - Better Than XML! 9. The definition scripting language will not need to b
-
I think the crux of the problem is that we need Service Pack 1 on the Human OS, but this runs the risk of breaking 'being human'. The alternative is the embedded artificial intelligence into all machines so they know to do what we 'meant', not what we 'said'.
... sorry, being human, meant to say 'is to embed artificial intelligence' ...
-
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
Whenever I read one of these "desires to fix programming languages", I laugh. I have been programming since the 80's and I too went through that phase right after college. However, I never had to work with all these silly pseudo-languages that come and go. We used ASM and C. Then Byorn Stroustroup (?) comes along and says, "hey, I hate programming, I'll add a bunch of junk to keep myself from making mistakes." I would've suggested he find a new line of work instead. C++ is a mess. It's poorly conceived, coerced and unnatural. It does nothing that a professional programmer can't accomplish in plain old C. As is usually the case, it causes more problems than it fixes, or it fixes one set but creates another set. Considering that most of the world is embedded micro-controllers, those of us who program them don't have gigabytes of memory or gigahertz processors as we need to be more efficient. Over 20 years this has taught me to appreciate C and ASM more. I'm glad I never got my wishes to have a bullet-proof language. I suggest if you're having issue with a particular part of a language, create a preprocessor directive and use it! For example, if your problem is:
if (x = y)
this can be fixed by defining:
#define IS_EQUAL ==
then used everywhere as:
if (x IS_EQUAL y)
No need to suggest the world change, or hope someday this 'gets fixed' for you. The C preprocessor is probably the most overlooked part of C. You can easily invent an entirely new language using the preprocessor. In fact, Linus Torvalds, who is a pretty awful programmer, took to using the preprocessor in ways most professionals would recommend against. But he recognized that it could keep him from repeating certain mistakes he tended to make.
-
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.
-
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
Smalltalk?
-
The bug was embedded deep within an error recovery routine that got invoked maybe once every 2-3 weeks with the result that the system would crash with little evidence as to why. It had been written by a programmer who had moved on to the next project.
Sorry. I was harsh. However, a decent language such as my current favorite, C#, almost always catches such things. Eg,
int i = 9;
int j = 10; // or 9, or 8 or whatever
if (i = j)
{
DoSomething();
}... won't compile. I've been writing code since '81. I cannot find anything to complain about with C#. EVERY other language I've used, not so.