Never found a programming language I couldn't love
-
Some say that "when the lady can't dance, she complains the band can't play". Generally that's my feeling towards complaints that such-and-such language is "bad", or that it produces "bad" code. I do agree that some languages lend themselves more than others to certain good (or bad) practices, and that some languages are better/worse suited than others for some problems. However, in my experience the most crippling problems are the result of poor programming style: the respective programmer community either doesn't know, or seems to forget how to write clear code once they join in. As way of example, this is my list of good practices for several widely-belittled languages. It's mostly about how you can use each language's specific features to uphold the principles of structured / OO programming: Visual Basic
- Always use
Option Explicitfor enforcing variable declaration; - Shun
Variantvariables – always use definite types; - Horribly misnamed as they are, embrace "Classes" as the way to go for behavior encapsulation;
- Use the
Objecttype sparingly, but learn to recognize where it can be leveraged for generalizing algorithms; - Well employed, the
On Errormachinery can make do as an effective Exception system; - Prefer Collections over Arrays, and learn to explore their associative features.
C
- Just because the language doesn't enforce a type-oriented form of programming doesn't mean you shouldn't. Always think about problems in terms of data types and accompanying operation (function) sets;
- Structure your code as a collection of header / source pairs, where the header defines (ideally) one data type and its API, and the source contains the implementations;
- Create more complex types by composing simpler ones, and likewise implement their API's in terms of the lower types' interfaces;
- When designing a type's API, remember to provide functions for dynamic instantiation, initialization of stack-defined instances, and deletion. Consider providing macros for access to struct fields, instead of conceding to direct dereference;
- Preserve the global namespace by defining symbols as
staticwhenever they don't have to be seen outside their compilation units; - Use function pointers for generalizing complex algorithms;
- Though dreadful when used carelessly, macros have great potential for simplifying progr
By the way, "Cue epic battle over programming languages" indeed. Funny thing is, what I was aiming at was the exact opposite of that. The point I was trying to make is that, while different languages do have their relative pros and cons, with a little discipline it's possible to write clean code in pretty much anything. Unfortunately it seems you can't swing a dead cat around a programmers' forum without starting a spat over which language is "best" (and I count myself as part of the problem).
- Always use
-
No they aren't. Pascal uses the obscene basic style
begin endpairs X| X| X| X| X| X| to define statement blocks; not the divine{ }pairs :cool::cool::cool::cool::cool::cool: of a C style language. They're nothing alike.3x12=36 2x12=24 1x12=12 0x12=18
Dan Neely wrote:
No they aren't. Pascal uses the obscene basic style begin end pairs to define statement blocks; not the divine { } pairs of a C style language. They're nothing alike.
ROFL!!! +5
Remember in November: But when a long Train of Abuses and Usurpations, pursuing invariably the same Object, evinces a Design to reduce them under absolute Despotism, it is their Right, it is their Duty, to throw off such Government, and to provide new Guards for their future Security.
-
Some say that "when the lady can't dance, she complains the band can't play". Generally that's my feeling towards complaints that such-and-such language is "bad", or that it produces "bad" code. I do agree that some languages lend themselves more than others to certain good (or bad) practices, and that some languages are better/worse suited than others for some problems. However, in my experience the most crippling problems are the result of poor programming style: the respective programmer community either doesn't know, or seems to forget how to write clear code once they join in. As way of example, this is my list of good practices for several widely-belittled languages. It's mostly about how you can use each language's specific features to uphold the principles of structured / OO programming: Visual Basic
- Always use
Option Explicitfor enforcing variable declaration; - Shun
Variantvariables – always use definite types; - Horribly misnamed as they are, embrace "Classes" as the way to go for behavior encapsulation;
- Use the
Objecttype sparingly, but learn to recognize where it can be leveraged for generalizing algorithms; - Well employed, the
On Errormachinery can make do as an effective Exception system; - Prefer Collections over Arrays, and learn to explore their associative features.
C
- Just because the language doesn't enforce a type-oriented form of programming doesn't mean you shouldn't. Always think about problems in terms of data types and accompanying operation (function) sets;
- Structure your code as a collection of header / source pairs, where the header defines (ideally) one data type and its API, and the source contains the implementations;
- Create more complex types by composing simpler ones, and likewise implement their API's in terms of the lower types' interfaces;
- When designing a type's API, remember to provide functions for dynamic instantiation, initialization of stack-defined instances, and deletion. Consider providing macros for access to struct fields, instead of conceding to direct dereference;
- Preserve the global namespace by defining symbols as
staticwhenever they don't have to be seen outside their compilation units; - Use function pointers for generalizing complex algorithms;
- Though dreadful when used carelessly, macros have great potential for simplifying progr
Try pure assembly language, in the processor of your choice. Now, that's a real hard mans language; head down, arse up and with no safety net - scary stuff ;P
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
- Always use
-
By the way, "Cue epic battle over programming languages" indeed. Funny thing is, what I was aiming at was the exact opposite of that. The point I was trying to make is that, while different languages do have their relative pros and cons, with a little discipline it's possible to write clean code in pretty much anything. Unfortunately it seems you can't swing a dead cat around a programmers' forum without starting a spat over which language is "best" (and I count myself as part of the problem).
I am from the old school - so I am quite happy with pointers. If you ever had to work with any kind of assembly language where you regularly used instructions like (390 assembler - LA) then using pointers; especially in a language like C/C++ seems very natural. After all most computing really just involves loading/accessing stuff/data in one location - doing something to it and then putting it in another location. Pointers rock. Additionally - once you understand the concept and are comfortable using them - you can develop programs/applications on a platform where you might not have the sophisticated library support you might otherwise currently rely on. Know the basics!
-
Some say that "when the lady can't dance, she complains the band can't play". Generally that's my feeling towards complaints that such-and-such language is "bad", or that it produces "bad" code. I do agree that some languages lend themselves more than others to certain good (or bad) practices, and that some languages are better/worse suited than others for some problems. However, in my experience the most crippling problems are the result of poor programming style: the respective programmer community either doesn't know, or seems to forget how to write clear code once they join in. As way of example, this is my list of good practices for several widely-belittled languages. It's mostly about how you can use each language's specific features to uphold the principles of structured / OO programming: Visual Basic
- Always use
Option Explicitfor enforcing variable declaration; - Shun
Variantvariables – always use definite types; - Horribly misnamed as they are, embrace "Classes" as the way to go for behavior encapsulation;
- Use the
Objecttype sparingly, but learn to recognize where it can be leveraged for generalizing algorithms; - Well employed, the
On Errormachinery can make do as an effective Exception system; - Prefer Collections over Arrays, and learn to explore their associative features.
C
- Just because the language doesn't enforce a type-oriented form of programming doesn't mean you shouldn't. Always think about problems in terms of data types and accompanying operation (function) sets;
- Structure your code as a collection of header / source pairs, where the header defines (ideally) one data type and its API, and the source contains the implementations;
- Create more complex types by composing simpler ones, and likewise implement their API's in terms of the lower types' interfaces;
- When designing a type's API, remember to provide functions for dynamic instantiation, initialization of stack-defined instances, and deletion. Consider providing macros for access to struct fields, instead of conceding to direct dereference;
- Preserve the global namespace by defining symbols as
staticwhenever they don't have to be seen outside their compilation units; - Use function pointers for generalizing complex algorithms;
- Though dreadful when used carelessly, macros have great potential for simplifying progr
FORTH is the only one and true language. You dynamically bend the language to the application, not the other way around. FORTH programs can read its own source code while compiling, allowing you to create new syntax as required. I've got this great chunk of code that "looks" like documentation of Quad-OPTO modules for hardware control, but in actual fact, the code reads itself to dynamically create the needed addresses and bit positions that are assigned to a symbol. Even the guys from Forth, Inc when looking at a program I had developed for conveyor controls after pronouncing the majority of the code vanilla (as I had intended) they flipped to the I/O definition section and said, "But this was neat!" It had the rudiments of object orientation long before the concepts were around (being old school, I prefer BUILDS> DOES> to CREATE DOES>). FORTH also lets you write "bridging verbs" so that you can write code that will bridge the gap between syntaxes of different versions. So from whatever version of FORTH you are using, you add a few bridging verbs, and then you can compile FORTH from a different vendor with slightly different syntax. You don't have to crawl over the code to convert a working program into a non-working version as most conversions seem to do as a first pass. AND you can intermix high level FORTH with low level Assembly. Keyhole optimizations can be made by replacing high level FORTH with Assembly code. As long as they both eat and excrete the same stack contents, you are good to go. But I'll admit if I need to parse strings, BASIC (any variation) is my first choice.
Psychosis at 10 Film at 11
- Always use
-
Some say that "when the lady can't dance, she complains the band can't play". Generally that's my feeling towards complaints that such-and-such language is "bad", or that it produces "bad" code. I do agree that some languages lend themselves more than others to certain good (or bad) practices, and that some languages are better/worse suited than others for some problems. However, in my experience the most crippling problems are the result of poor programming style: the respective programmer community either doesn't know, or seems to forget how to write clear code once they join in. As way of example, this is my list of good practices for several widely-belittled languages. It's mostly about how you can use each language's specific features to uphold the principles of structured / OO programming: Visual Basic
- Always use
Option Explicitfor enforcing variable declaration; - Shun
Variantvariables – always use definite types; - Horribly misnamed as they are, embrace "Classes" as the way to go for behavior encapsulation;
- Use the
Objecttype sparingly, but learn to recognize where it can be leveraged for generalizing algorithms; - Well employed, the
On Errormachinery can make do as an effective Exception system; - Prefer Collections over Arrays, and learn to explore their associative features.
C
- Just because the language doesn't enforce a type-oriented form of programming doesn't mean you shouldn't. Always think about problems in terms of data types and accompanying operation (function) sets;
- Structure your code as a collection of header / source pairs, where the header defines (ideally) one data type and its API, and the source contains the implementations;
- Create more complex types by composing simpler ones, and likewise implement their API's in terms of the lower types' interfaces;
- When designing a type's API, remember to provide functions for dynamic instantiation, initialization of stack-defined instances, and deletion. Consider providing macros for access to struct fields, instead of conceding to direct dereference;
- Preserve the global namespace by defining symbols as
staticwhenever they don't have to be seen outside their compilation units; - Use function pointers for generalizing complex algorithms;
- Though dreadful when used carelessly, macros have great potential for simplifying progr
Folks must be forgetting the good old days. Remember when Basic Interpreters only allowed two character variable names? I don't care how creative you are, try to build a relatively simple system of today with two character names. That lady couldn't dance and that band couldn't keep time. StCroixSkipper
scooter_jsm
- Always use
-
Folks must be forgetting the good old days. Remember when Basic Interpreters only allowed two character variable names? I don't care how creative you are, try to build a relatively simple system of today with two character names. That lady couldn't dance and that band couldn't keep time. StCroixSkipper
scooter_jsm
-
Wotsa Matter U? :wtf: Can't deal with A-Z, A0-A9...Z0-Z9, AA...AZ...ZA...ZZ? Not enough variables????? Why just add comments to explain them all :laugh:
Psychosis at 10 Film at 11
As I recall a very familiar name's claim to fame was his development of a Basic Interpreter with 2 character variable names. His accomplishment was so profound it was mentioned in a recent movie. I couldn't help but think it was tongue in cheek but only a developer who was there would recognize the humor.
scooter_jsm
-
Some say that "when the lady can't dance, she complains the band can't play". Generally that's my feeling towards complaints that such-and-such language is "bad", or that it produces "bad" code. I do agree that some languages lend themselves more than others to certain good (or bad) practices, and that some languages are better/worse suited than others for some problems. However, in my experience the most crippling problems are the result of poor programming style: the respective programmer community either doesn't know, or seems to forget how to write clear code once they join in. As way of example, this is my list of good practices for several widely-belittled languages. It's mostly about how you can use each language's specific features to uphold the principles of structured / OO programming: Visual Basic
- Always use
Option Explicitfor enforcing variable declaration; - Shun
Variantvariables – always use definite types; - Horribly misnamed as they are, embrace "Classes" as the way to go for behavior encapsulation;
- Use the
Objecttype sparingly, but learn to recognize where it can be leveraged for generalizing algorithms; - Well employed, the
On Errormachinery can make do as an effective Exception system; - Prefer Collections over Arrays, and learn to explore their associative features.
C
- Just because the language doesn't enforce a type-oriented form of programming doesn't mean you shouldn't. Always think about problems in terms of data types and accompanying operation (function) sets;
- Structure your code as a collection of header / source pairs, where the header defines (ideally) one data type and its API, and the source contains the implementations;
- Create more complex types by composing simpler ones, and likewise implement their API's in terms of the lower types' interfaces;
- When designing a type's API, remember to provide functions for dynamic instantiation, initialization of stack-defined instances, and deletion. Consider providing macros for access to struct fields, instead of conceding to direct dereference;
- Preserve the global namespace by defining symbols as
staticwhenever they don't have to be seen outside their compilation units; - Use function pointers for generalizing complex algorithms;
- Though dreadful when used carelessly, macros have great potential for simplifying progr
How about brainf*ck, INTERCAL, and Whitespace?
modified on Tuesday, October 26, 2010 8:08 PM
- Always use
-
You are way too young then. Try COBOL, structured? they never heard of the word. MSX BASIC, you just hated it, that was all there was. Pascal, Let's just say that if you knew ALGOL, you stuck with ALGOL.
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC League Table Link CCC Link[^]
First thing I thought of was COBOL when I saw the title. It works. It was the first thing I learned after assembler. I have to say, I preferred assembler to COBOL even if it is less readable. Its usable. I coded in it for two years straight before I found a transfer that used FORTRAN. A year later, I was brought kicking and screaming back to it because my new partner liked it. It certainly is good background knowledge when told to use PLI (very COBOLesk) Love is a very serious term. Can't say I've ever seen code where that term applies. A lot of them I Like. NEVER EVER COBOL.