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
- 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
- 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
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[^]
- 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[^]
Dalek Dave wrote:
COBOL
PLease, keep it KSS in the lounge. We don't need that kind of language!
Dalek Dave wrote:
MSX BASIC
GW-BASIC?
Dalek Dave wrote:
Pascal
It was a good teaching language. Once you had learned it, you could move on into the real world, and do real things, with real languages...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
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[^]
I did quite a bit of Algol programming, way back when. So, where do you find an Algol compiler for .NET?
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
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[^]
Dalek Dave wrote:
You are way too young then.
Perhaps I am, or perhaps you're just falling behind.
Try COBOL, structured? they never heard of the word.
Maybe, though in that case it seems they jumped straight to the next step.
MSX BASIC, you just hated it, that was all there was.
I beg to disagree. I did some MSX BASIC programming when I was around 10 years old, and it was alright back then.
Pascal,
Been there, done that, and have you ever heard of Delphi?
Let's just say that if you knew ALGOL, you stuck with ALGOL
Can't speak for ALGOL, but then again it's debatable whether programming itself was well understood back then. Perhaps it was more of a C++ case – where you have to select and stick to a subset of the language to make it work?
-
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
- Always use
-
Dalek Dave wrote:
COBOL
PLease, keep it KSS in the lounge. We don't need that kind of language!
Dalek Dave wrote:
MSX BASIC
GW-BASIC?
Dalek Dave wrote:
Pascal
It was a good teaching language. Once you had learned it, you could move on into the real world, and do real things, with real languages...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
OriginalGriff wrote:
GW-BASIC?
(shudder) Whoa. Bad flashbacks of an old green screen CP/M Altos edited with WordStar. My first statement was GOTO LiquorStore.
Christopher Duncan
www.PracticalUSA.com
Author of The Career Programmer and Unite the Tribes
Copywriting Services -
OriginalGriff wrote:
GW-BASIC?
(shudder) Whoa. Bad flashbacks of an old green screen CP/M Altos edited with WordStar. My first statement was GOTO LiquorStore.
Christopher Duncan
www.PracticalUSA.com
Author of The Career Programmer and Unite the Tribes
Copywriting ServicesChristopher Duncan wrote:
GOTO LiquorStore
Sounds like the best GW-Basic program ever written. :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
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
Yes, but not for the reasons you think. A programming language stinks if: 1) You can't readily hire a replacement programmer 2) It doesn't have a quality debugger As for the rest, I pretty much disagree with most of your points, but won't bother arguing here except to say that anyone who says "forget structs" and "avoid using pointers" has no credibility whatsoever in my book.
- 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
xperroni wrote:
What about you? Do you think there are inherently "bad" languages, or is it essentially a matter of poor practice?
There aren't "bad" languages so much as "toy" languages. As I see it, there are three types of languages... 1) Languages that can be used to write real software. 2) Languages that can kind of write software, if you don't have the time/knowledge/infrastructure to go with #1. Just don't try to do anything complicated, or you'll be ripping your hair out in record time. 3) Languages that should stay in academia and never, ever emerge. Useful to learn principles, perhaps, but just don't belong in the real world.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) - 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
5!
xperroni wrote:
Do you think there are inherently "bad" languages, or is it essentially a matter of poor practice?
It is inherently poor practice. As someone "wiseman" has said, do not program in the language, program into the language. You clearly demonstrate that. Now 5 points for those who can name who is the "wiseman", I am quoting.
- 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
Object as Variant Object = Agree.Strongly() On Error Resume Next GoTo DLLHELL()
Oh take me out to the climber's crag, take me to the sun. Buy me some white gold and cams for my rack; I don't care if I ever get back. Rope, rope up with a partner. Let them lead the climb. They can way-lay the high belay and you can just take your time. Oh take me out to the climber's crag, take me into the sun. A rope on back, a climbers rack, good friends and strangers come on! Climb On!
- 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
- Always use
-
Yes, but not for the reasons you think. A programming language stinks if: 1) You can't readily hire a replacement programmer 2) It doesn't have a quality debugger As for the rest, I pretty much disagree with most of your points, but won't bother arguing here except to say that anyone who says "forget structs" and "avoid using pointers" has no credibility whatsoever in my book.
Joe Woodbury wrote:
As for the rest, I pretty much disagree with most of your points, but won't bother arguing here except to say that anyone who says "forget structs" and "avoid using pointers" has no credibility whatsoever in my book.
It's only fair. In my book, if you don't know enough about C++ to (mostly) go without pointers, then you don't know enough about C++.
-
Joe Woodbury wrote:
As for the rest, I pretty much disagree with most of your points, but won't bother arguing here except to say that anyone who says "forget structs" and "avoid using pointers" has no credibility whatsoever in my book.
It's only fair. In my book, if you don't know enough about C++ to (mostly) go without pointers, then you don't know enough about C++.
Why would you forgo pointers? They are very powerful and if you think references are safe, you are delusional (a poster here hates references so much, he advocates never using them!) Moreover, they are there and pretending they're not is pure foolishness. They key isn't to avoid using pointers, but to understand them (point being that it is my experience that most programmers who rant against pointers don't understand them.)
-
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[^]
Dalek Dave wrote:
Pascal
What about it? Pascal and Object Pascal (Delphi) are a nice languages from the C\C++\Java\C# family.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Why would you forgo pointers? They are very powerful and if you think references are safe, you are delusional (a poster here hates references so much, he advocates never using them!) Moreover, they are there and pretending they're not is pure foolishness. They key isn't to avoid using pointers, but to understand them (point being that it is my experience that most programmers who rant against pointers don't understand them.)
Joe Woodbury wrote:
Why would you forgo pointers? They are very powerful and if you think references are safe, you are delusional (a poster here hates references so much, he advocates never using them!)
Not unlike goto, pointers are powerful and very useful, but almost just as dangerous. References are not 100% safe, granted. But in my experience, the pointer / reference cockup ratio has been somewhere around 1000 / 1. It takes a lot more effort to defeat reference consistency than to come up with pointer errors - that is, provided you take the time to rethink you programming paradigms (e.g. forget return values, think output arguments).
Joe Woodbury wrote:
Moreover, they are there and pretending they're not is pure foolishness.
I'll assume you wrote that without realizing most modern languages (e.g. Java, C#, Python) do precisely that when they largely automate memory management.
Joe Woodbury wrote:
They key isn't to avoid using pointers, but to understand them (point being that it is my experience that most programmers who rant against pointers don't understand them.)
I never advocated doing away with pointers entirely, but merely not using them where they're not needed – which in C++ is an awful lot of places.
-
Joe Woodbury wrote:
Why would you forgo pointers? They are very powerful and if you think references are safe, you are delusional (a poster here hates references so much, he advocates never using them!)
Not unlike goto, pointers are powerful and very useful, but almost just as dangerous. References are not 100% safe, granted. But in my experience, the pointer / reference cockup ratio has been somewhere around 1000 / 1. It takes a lot more effort to defeat reference consistency than to come up with pointer errors - that is, provided you take the time to rethink you programming paradigms (e.g. forget return values, think output arguments).
Joe Woodbury wrote:
Moreover, they are there and pretending they're not is pure foolishness.
I'll assume you wrote that without realizing most modern languages (e.g. Java, C#, Python) do precisely that when they largely automate memory management.
Joe Woodbury wrote:
They key isn't to avoid using pointers, but to understand them (point being that it is my experience that most programmers who rant against pointers don't understand them.)
I never advocated doing away with pointers entirely, but merely not using them where they're not needed – which in C++ is an awful lot of places.
xperroni wrote:
I'll assume you wrote that without realizing most modern languages (e.g. Java, C#, Python) do precisely that when they largely automate memory management.
Wow, be a little more clueless and condescending. C++ isn't one of those languages, so why pretend it should be. If you want automatic memory management and all that goes with it, use a language that gives that to you. Don't try to force C++ to be something it isn't. You way overestimate the safety of references and apparently ignore their many other downsides. The resistance to pointers creates seriously awful code. If you want the features of C#, use C#. However, needless bloating up code because you might shoot yourself in the foot in C++ is absurd and ignores the fact that C++ is relentless in not only handing you the gun, but loading and cocking it as well. :)
