Time for a new programming language paradigm
-
So... what you want is a common business oriented language? COBOL it is!
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?
-
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
-
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
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
?
-
All your answers are at The Osmosian Order[^]
cheers Chris Maunder
Oooohhh!!!!
I'd rather be phishing!
-
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 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.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
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
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[^]
-
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.?
-
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.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
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.
-
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
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.
-
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[^]
I just did my 29th update to Firefox the other day. It took me about 3 hours to get it back to where it was. Windows 7 keeps bugging about "New updates are ready to install". And Adobe Acrobat keeps crashing.... My point is: How can the programming process be improved? Such that we don't have 29 versions of FF? Or weekly updates ready to be installed. Or "Should a crash report be sent..."?
-
All your answers are at The Osmosian Order[^]
cheers Chris Maunder
I'm pretty sure that you implied that I was cruel a while back when I was teasing Pete... I sir, am not even in your league! I bow in your presence. :cool:
Government is not reason; it is not eloquent; it is force. Like fire, it is a dangerous servant and a fearful master. ~ George Washington
-
I'm pretty sure that you implied that I was cruel a while back when I was teasing Pete... I sir, am not even in your league! I bow in your presence. :cool:
Government is not reason; it is not eloquent; it is force. Like fire, it is a dangerous servant and a fearful master. ~ George Washington
:cool:
cheers Chris Maunder
-
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.
-
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.
-
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 really just want a compiler to be more helpful with errors. Tools like Resharper help with this in Visual Studio! Hogan
(Not everyone uses Visual Studio.)
You'll never get very far if all you do is follow instructions.
-
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
-
(Not everyone uses Visual Studio.)
You'll never get very far if all you do is follow instructions.
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
-
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.
-
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:
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.