Never found a programming language I couldn't love
-
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. :)
Joe Woodbury wrote:
C++ isn't one of those languages, so why pretend it should be.
Never meant to. My point is that, in principle, abstracting away pointers is not bad. C++ has numerous facilities for doing it, from references to
autopointers to the STL collections; so it's hardly about "forcing" anything, more like putting to use support that's already there. Actually the point I've been trying to make all along is "don't program C++ as if it was C". C++ has several features that simplify memory management, and they're much easier to leverage when you restrict pointer usage. -
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.
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
-
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:
pointer / reference cockup ratio has been somewhere around 1000 / 1
Much like the handgun / butter knife ratio.
-
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++.
xperroni wrote:
you don't know enough about C++
I've only ever dabbled in C++, because C was paying the bills*. So, yes I don't know much about C++. But last week I was dabbling again and really didn't see the point of references. I've been using raw unadulterated pointers for decades and I don't miss what I aim at. * More recently, C# was paying the bills. Now it's VB. X|
-
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:
debugger
Once it's been buggered it can't be debuggered. :-D
-
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
A language that's bad for me to use is one that gets in my way or frequently annoys me even when I make repeated efforts to adopt its "style". Good code can be written even in "bad" languages (with a few exceptions), given enough careful attention, but for some languages, it's typically just not worth the effort. (Granted, different people have different opinions on which languages those are.) That being said, I've been known to willingly write code even in the languages I dislike, because there was money to be had from it.
- 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
This was funny. :) And also no real language is allowed to have a name longer than one character and undefined number of special characters. Apart from the sarcasm, I also despite “begin-end;” construction.
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.
-
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
PL/1 was certainly "interesting". (Showing my age now.) :doh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
- Always use
-
xperroni wrote:
pointer / reference cockup ratio has been somewhere around 1000 / 1
Much like the handgun / butter knife ratio.
PIEBALDconsult wrote:
Much like the handgun / butter knife ratio.
Exactly! Much like a butter knife, references are cheap, straightforward and perfectly suited for the task they were crafted for. Of course, when employed outside their original scope they may not feature so stellarly, but generally they won't blow your face off (though you can hurt yourself with one, if you try hard enough). Likewise, pointers are just like handguns...
-
xperroni wrote:
you don't know enough about C++
I've only ever dabbled in C++, because C was paying the bills*. So, yes I don't know much about C++. But last week I was dabbling again and really didn't see the point of references. I've been using raw unadulterated pointers for decades and I don't miss what I aim at. * More recently, C# was paying the bills. Now it's VB. X|
PIEBALDconsult wrote:
But last week I was dabbling again and really didn't see the point of references.
Think of them as pointers that are guaranteed (well, sorta) to point to a valid instance. This is checked at compile time, so in principle they would ensure that no "dangling pointer" errors happen, ever. Of course the reality is a little more complicated, and there are still ways you can overflow your leg off. Also they take some practice to use effectively, but in my experience they largely deliver - I've been on and off C++ programming for 10-odd years and only once I managed to screw a reference, whereas I pierce my feet on C wild pointers (mine and other people's) every other week.
-
A language that's bad for me to use is one that gets in my way or frequently annoys me even when I make repeated efforts to adopt its "style". Good code can be written even in "bad" languages (with a few exceptions), given enough careful attention, but for some languages, it's typically just not worth the effort. (Granted, different people have different opinions on which languages those are.) That being said, I've been known to willingly write code even in the languages I dislike, because there was money to be had from it.
-
PIEBALDconsult wrote:
But last week I was dabbling again and really didn't see the point of references.
Think of them as pointers that are guaranteed (well, sorta) to point to a valid instance. This is checked at compile time, so in principle they would ensure that no "dangling pointer" errors happen, ever. Of course the reality is a little more complicated, and there are still ways you can overflow your leg off. Also they take some practice to use effectively, but in my experience they largely deliver - I've been on and off C++ programming for 10-odd years and only once I managed to screw a reference, whereas I pierce my feet on C wild pointers (mine and other people's) every other week.
xperroni wrote:
to point to a valid instance
I don't see that as a big deal.
-
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, Let's just say that if you knew ALGOL, you stuck with ALGOL.
Oh yes! I wrote a payroll system in Algol 60, followed some years later by a vector based plotting system in Pascal - Algol 60 was definitely a nicer beast to work with (but not available on the equipment I was using for the plotting software...) I've only ever written one COBOL program in my entire programming career (coming on for 40 years now FFS!), and that was only a mod to an existing research suite at Uni - never felt the need to touch it again (although I do have to process data produced by a bank's COBOL mainframe software, so knowing how the ISAM files are put together is useful...) :omg:
-
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
Hi friends, It's clear that using a specific programming language may sometimes influence the way you develop, unless you have a solid programming experience. If you only worked with the C language, then when you will turn yourself to C++, you will be inclined to develop in C++ like you used to develop in C. But once you have worked with several programming languages, and designed several software architectures and algorithms, using a new language becomes a matter of performing analogies with your past experiences and, magically, this is no more the new language you just learned that guides your way of developing things, but your own experience. I just have one counter-example about that : it's IBM's RPG language (I don't know what it has become today, but I've used RPG II and RPG III). I worked with that during one year in 1992 and this was the worst programming experience I have had. I'm sometimes inclined to think that programming in Brainfuck would be more effective. If you are curious, have a look at the following site which offers an exotic programming language, Goto++ : http://www.gotopp.org/index.html.en This is a real programming language, with lots of funny features, most of them being absolutely useless but it has been made by a guy who has a really great sense of humor ! Christian.
- Always use
-
xperroni wrote:
to point to a valid instance
I don't see that as a big deal.
PIEBALDconsult wrote:
I don't see that as a big deal.
Then surely you're "smarter than the average programmer" (me included), for memory management errors –specially "dangling pointers" – are pretty much the single largest cause of software defects. It's no wonder most modern languages strive to at least guarantee object references to be either valid or null.
-
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