|
How about Cobol+?
Cobol, PL/1, etc., have a lot of nice features.
I like the tasking (multi-threading), resource management/control and arithmetic formula capabilities of PL/1.
I like the sentence-like structuring of COBOL.
What would a "new" language look like that incorporated this stuff?
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
Oh, yeah!
I forgot to add: "Communications is two or more individuals sharing AND understanding an idea."
The "and understanding" part often gets overlooked in programming.
|
|
|
|
|
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
?
|
|
|
|
|
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.?
|
|
|
|
|
Yes, well a bare equal-sign should be an error; assignment should be with :=, a la Pascal and others.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
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++ )
;
}
|
|
|
|
|
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
|
|
|
|
|
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).
|
|
|
|
|
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...
|
|
|
|
|
Well, the weak typing you suggest probably isn't less error-prone. Consider this for example.
S = 12; .
.
.
S += 34; .
.
.
print S;
Now someone else comes and hijacks the variable in between.
S = 12; .
.
.
String tmp = S; S = "Test";
...
S = tmp; .
.
.
S += 34; .
.
.
print S;
How long will it take you to find this?
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
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' ...
|
|
|
|
|
Sould note that when Programming (talking to) humans is much education between Chemists and physicists. Agree we need a pretty good AI to take over the details of creating a program and avoiding the failures of precision (as in missing commas etc.)but the AI needs to be able to learn how we think. And we write math using integer to real and back quite often and only occasionally blow the wad. Think about translating the gibs free energy - from chemistry - to the conservation of energy as in all else. Confuse those two and the barn goes up in a hot one. One damn smart computer to follow us into our thousands of specialties.
|
|
|
|
|
So I had a lot of practice spotting poorly placed operators. I would much rather spend one day every other year looking for a misplaced semi-colon than spend the time adding verbosity. Plus, in my opinion, the ability to see on screen without scrolling the maximum amount of logic is paramount in writing good systems. The eyes move orders of magnitude faster than scrolling. I have seen some beautifully written, well documented code that was nearly impossible to trouble shoot for all the novel in the code.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Plus, in my opinion, the ability to see on screen without scrolling the maximum amount of logic is paramount in writing good systems. The eyes move orders of magnitude faster than scrolling. I have seen some beautifully written, well documented code that was nearly impossible to trouble shoot for all the novel in the code.
I have seen all too much code that took most the screen to display a simple concept. E.g.,
if ( a = b )
{
c = d;
}
else
{
if ( p == q )
q = r;
};
This coder use spacing to up his LOC/day count. Comprehension....well...that leaves a lot to be desired.
And I agree about beautifully written code. I saw a 1000 character program written in one line with no white space. Couldn't begin to understand what it was doing.
Ennis Ray Lynch, Jr. wrote: So I had a lot of practice spotting poorly placed operators. I would much rather spend one day every other year looking for a misplaced semi-colon than spend the time adding verbosity.
If there is time, and no pressure, a misplaced semi-colon isn't a problem. But, add pressure, such as commodities trading, and you have 2 minutes to find and fix the bug, well....pass the Maalox please.
|
|
|
|
|
This is a major rant I have about default (e.g. StyleCop) formatting conventions. They waste so much space that you can't actually see what the code does.
|
|
|
|
|
|
Wow, at >8000$ for a smartphone resolution screen? Seriously? 
|
|
|
|
|
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: 2) 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: 3) 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: 5) 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: 6) 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 
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
