Reply by whit3rd April 20, 20172017-04-20
On Wednesday, April 19, 2017 at 8:38:18 AM UTC-7, rickman wrote:

> What people don't get about strong typing is that it isn't as much to > tell the compiler what the type is as to clarify it for the programmer. > Or maybe I should say it is to make the programmer consider the type so > they don't make typing mistakes.
Autotyping was a convenience. A good compiler would have an option to list the variables and their types, and proof-reading that listing was an important step in debugging. It wasn't part of the standard for FORTRAN, but it was very useful.
Reply by April 20, 20172017-04-20
On Wed, 19 Apr 2017 21:30:59 -0400, krw@notreal.com wrote:

>On Wed, 19 Apr 2017 16:19:38 +0300, upsidedown@downunder.com wrote: > >>On Tue, 18 Apr 2017 20:50:34 -0400, krw@notreal.com wrote: >> >>>On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net> >>>wrote: >>> >>>>On 04/17/2017 07:16 PM, Don Y wrote: >>>>> On 4/17/2017 6:21 PM, Bill Martin wrote: >>>>>> On 04/16/2017 07:51 AM, bitrex wrote: >>>>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>>>> >>>>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>>>> professionals, but firmware written by nincompoops. >>>>>>>>> >>>>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>>>> >>>>>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>>>>> there with EE degrees. >>>>>>> >>>>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>>>> patterns", "test-driven development", and "agile development." >>>>>>> >>>>>>> It's okay. It's really not that scary! You don't even have to be afraid >>>>>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>>>>> 1993 and nobody gets paid by number of classes derived from anymore. >>>>>> >>>>>> It's not so much "scared of", but the suspicion that the new emperor >>>>>> has no >>>>>> better clothes than the old emperor.. :-) >>>>> >>>>> The analogy *almost* fits. >>>>> >>>>> I think it *doesn't* fit when applied to things like OOP vs. procedural >>>>> approaches. There's a definite distinction in how you think about >>>>> problems (i.e., *solutions*) in the two approaches. And, while duality >>>>> lets you (theoretically) transform an approach from one solution >>>>> space to the other, it is impractical. >>>>> >>>>> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >>>>> methodologies that try to improve quality, reliability, efficiency, etc. >>>>> with a single idea that inevitably gets distilled to a terse mantra. Just >>>>> like "don't run with scissors", it ignores a whole set of details that >>>>> can (and do!) make a big difference in outcomes. >>>> >>>>Well, the new can be better than the old, but I still recall when Pascal >>>>was gonna save us from ourselves...that's really the sticking point, >>>>"save us from our selves". Doesn't work, our selves can be just as >>>>stupid in a constrained grammar as in assembly code... :-( And damned >>>>ingenious in finding new ways to "beat the system"! >>> >>>Pascal was intended to teach block structured coding. It wasn't >>>intended to be useful (note the crappy I/O). Of course given a >>>screwdriver, someone will insist on making a hammer of it. >> >>In the days Pascal was created, the mainstream programming languages >>(COBOL and FORTRAN) did not have any block IF statements and the loop >>control was very limited. The same applied of course to all assembly >>languages. >> >>Thus, the only tool to affect the program flow was the GOTO >>statements. One had to invent target labels for the GOTO targets. At >>least in one FORTRAN dialect, it was possible to use the label number >>of a FORMAT statement as a target GOTO statement or to terminate the >>DO-loop :-). Lack of proper control structures made it hard to write >>easy to read programs. In Fortran IV I used GOTOs only for jumping >>forwards and DO-loops to return backwards. >> >>Unfortunately, the anti-GOTO lobby (Wirth, Dijkstra etc.) declared war >>against GOTOs, while IMHO a better approach would have been to state >>that the better control structures would reduce the need for inventing >>labels and branching over the "else" parts. >> >>The anti-COTO lobby claimed that programs using GOTOs create >>"spagetti-code". In my career, I have only seen one bad spagetti-code >>in an old COBOL programs, in all other cases, people tried to keep the >>program flow more or less simple, even if the only control structure >>was th GOTO statement. > >How "old" was the COBOL program. Again, the point of Pascal was to >teach structured programming. It wasn't intended to be a useful >language.
It was a tailor made production control system for a large metal factory, originally written in the 1970's for an IBM mainframe using CICS transaction processing.
Reply by Clifford Heath April 19, 20172017-04-19
On 20/04/17 11:30, krw@notreal.com wrote:
> On Wed, 19 Apr 2017 16:19:38 +0300, upsidedown@downunder.com wrote: > >> On Tue, 18 Apr 2017 20:50:34 -0400, krw@notreal.com wrote: >> >>> On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net> >>> wrote: >>> >>>> On 04/17/2017 07:16 PM, Don Y wrote: >>>>> On 4/17/2017 6:21 PM, Bill Martin wrote: >>>>>> On 04/16/2017 07:51 AM, bitrex wrote: >>>>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>>>> >>>>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>>>> professionals, but firmware written by nincompoops. >>>>>>>>> >>>>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>>>> >>>>>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>>>>> there with EE degrees. >>>>>>> >>>>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>>>> patterns", "test-driven development", and "agile development." >>>>>>> >>>>>>> It's okay. It's really not that scary! You don't even have to be afraid >>>>>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>>>>> 1993 and nobody gets paid by number of classes derived from anymore. >>>>>> >>>>>> It's not so much "scared of", but the suspicion that the new emperor >>>>>> has no >>>>>> better clothes than the old emperor.. :-) >>>>> >>>>> The analogy *almost* fits. >>>>> >>>>> I think it *doesn't* fit when applied to things like OOP vs. procedural >>>>> approaches. There's a definite distinction in how you think about >>>>> problems (i.e., *solutions*) in the two approaches. And, while duality >>>>> lets you (theoretically) transform an approach from one solution >>>>> space to the other, it is impractical. >>>>> >>>>> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >>>>> methodologies that try to improve quality, reliability, efficiency, etc. >>>>> with a single idea that inevitably gets distilled to a terse mantra. Just >>>>> like "don't run with scissors", it ignores a whole set of details that >>>>> can (and do!) make a big difference in outcomes. >>>> >>>> Well, the new can be better than the old, but I still recall when Pascal >>>> was gonna save us from ourselves...that's really the sticking point, >>>> "save us from our selves". Doesn't work, our selves can be just as >>>> stupid in a constrained grammar as in assembly code... :-( And damned >>>> ingenious in finding new ways to "beat the system"! >>> >>> Pascal was intended to teach block structured coding. It wasn't >>> intended to be useful (note the crappy I/O). Of course given a >>> screwdriver, someone will insist on making a hammer of it. >> >> In the days Pascal was created, the mainstream programming languages >> (COBOL and FORTRAN) did not have any block IF statements and the loop >> control was very limited. The same applied of course to all assembly >> languages. >> >> Thus, the only tool to affect the program flow was the GOTO >> statements. One had to invent target labels for the GOTO targets. At >> least in one FORTRAN dialect, it was possible to use the label number >> of a FORMAT statement as a target GOTO statement or to terminate the >> DO-loop :-). Lack of proper control structures made it hard to write >> easy to read programs. In Fortran IV I used GOTOs only for jumping >> forwards and DO-loops to return backwards. >> >> Unfortunately, the anti-GOTO lobby (Wirth, Dijkstra etc.) declared war >> against GOTOs, while IMHO a better approach would have been to state >> that the better control structures would reduce the need for inventing >> labels and branching over the "else" parts. >> >> The anti-COTO lobby claimed that programs using GOTOs create >> "spagetti-code". In my career, I have only seen one bad spagetti-code >> in an old COBOL programs, in all other cases, people tried to keep the >> program flow more or less simple, even if the only control structure >> was th GOTO statement. > > How "old" was the COBOL program. Again, the point of Pascal was to > teach structured programming. It wasn't intended to be a useful > language.
It didn't stop people from trying. HP used a version called MODCAL to write entire operating systems (early versions of HP-UX on the HP500 series). Clifford Heath.
Reply by April 19, 20172017-04-19
On Wed, 19 Apr 2017 16:19:38 +0300, upsidedown@downunder.com wrote:

>On Tue, 18 Apr 2017 20:50:34 -0400, krw@notreal.com wrote: > >>On Mon, 17 Apr 2017 19:47:52 -0700, Bill Martin <wwm@wwmartin.net> >>wrote: >> >>>On 04/17/2017 07:16 PM, Don Y wrote: >>>> On 4/17/2017 6:21 PM, Bill Martin wrote: >>>>> On 04/16/2017 07:51 AM, bitrex wrote: >>>>>> On 04/16/2017 10:25 AM, Tim Wescott wrote: >>>>>>> On Sun, 16 Apr 2017 09:17:36 -0400, bitrex wrote: >>>>>>> >>>>>>>> On 04/16/2017 09:13 AM, bitrex wrote: >>>>>>>>> The graveyard of audio production equipment is littered with the >>>>>>>>> corpses of products that had rock-solid hardware designed by >>>>>>>>> professionals, but firmware written by nincompoops. >>>>>>>> >>>>>>>> To be clear, what I mean by that is they let EEs write the software. >>>>>>> >>>>>>> HEY! There's a lot of profoundly good embedded software engineers out >>>>>>> there with EE degrees. >>>>>> >>>>>> They sometimes seem scared of newfangled stuff like OOP, "design >>>>>> patterns", "test-driven development", and "agile development." >>>>>> >>>>>> It's okay. It's really not that scary! You don't even have to be afraid >>>>>> of all that "inheritance" and endless class hierarchy stuff, it's not >>>>>> 1993 and nobody gets paid by number of classes derived from anymore. >>>>> >>>>> It's not so much "scared of", but the suspicion that the new emperor >>>>> has no >>>>> better clothes than the old emperor.. :-) >>>> >>>> The analogy *almost* fits. >>>> >>>> I think it *doesn't* fit when applied to things like OOP vs. procedural >>>> approaches. There's a definite distinction in how you think about >>>> problems (i.e., *solutions*) in the two approaches. And, while duality >>>> lets you (theoretically) transform an approach from one solution >>>> space to the other, it is impractical. >>>> >>>> OTOH, I *do* think the analogy is appropriate when it comes to the "how to" >>>> methodologies that try to improve quality, reliability, efficiency, etc. >>>> with a single idea that inevitably gets distilled to a terse mantra. Just >>>> like "don't run with scissors", it ignores a whole set of details that >>>> can (and do!) make a big difference in outcomes. >>> >>>Well, the new can be better than the old, but I still recall when Pascal >>>was gonna save us from ourselves...that's really the sticking point, >>>"save us from our selves". Doesn't work, our selves can be just as >>>stupid in a constrained grammar as in assembly code... :-( And damned >>>ingenious in finding new ways to "beat the system"! >> >>Pascal was intended to teach block structured coding. It wasn't >>intended to be useful (note the crappy I/O). Of course given a >>screwdriver, someone will insist on making a hammer of it. > >In the days Pascal was created, the mainstream programming languages >(COBOL and FORTRAN) did not have any block IF statements and the loop >control was very limited. The same applied of course to all assembly >languages. > >Thus, the only tool to affect the program flow was the GOTO >statements. One had to invent target labels for the GOTO targets. At >least in one FORTRAN dialect, it was possible to use the label number >of a FORMAT statement as a target GOTO statement or to terminate the >DO-loop :-). Lack of proper control structures made it hard to write >easy to read programs. In Fortran IV I used GOTOs only for jumping >forwards and DO-loops to return backwards. > >Unfortunately, the anti-GOTO lobby (Wirth, Dijkstra etc.) declared war >against GOTOs, while IMHO a better approach would have been to state >that the better control structures would reduce the need for inventing >labels and branching over the "else" parts. > >The anti-COTO lobby claimed that programs using GOTOs create >"spagetti-code". In my career, I have only seen one bad spagetti-code >in an old COBOL programs, in all other cases, people tried to keep the >program flow more or less simple, even if the only control structure >was th GOTO statement.
How "old" was the COBOL program. Again, the point of Pascal was to teach structured programming. It wasn't intended to be a useful language.
Reply by Tim Wescott April 19, 20172017-04-19
On Wed, 19 Apr 2017 17:42:09 +0100, Martin Brown wrote:

> On 19/04/2017 17:27, Tim Wescott wrote: >> On Wed, 19 Apr 2017 11:56:56 -0400, bitrex wrote: >> >>> On 04/19/2017 11:38 AM, rickman wrote: >>> >>>>> the "auto" automatic type deduction keyword available in C++11 >>>>> onwards helps cut down on the verbosity a lot; I use it wherever >>>>> possible, in C++14 it's even available for use to automatically >>>>> deduce function return types. >>>> >>>> What people don't get about strong typing is that it isn't as much to >>>> tell the compiler what the type is as to clarify it for the >>>> programmer. >>>> Or maybe I should say it is to make the programmer consider the type >>>> so they don't make typing mistakes. >>>> >>>> >>> It can't stop active malice (or extreme stupidity.) >> >> No computer language will do that. My one paid experience with Ada > > Z & VDM come close but they are languages for specification of a problem > rather than a compilable solution. > >> involved finding bugs in someone else's code. The reason that I found >> the bug was because they didn't look, and the reason they didn't look >> is because they refused to believe that the bug could be in an Ada- >> programmed box that was talking to a C-programmed box. > > If you want extreme safety critical reliability cost no object you end > up on a SPARK subset of Ada of the sort that Praxis made popular and is > almost as fast as C when compiled these days. > > https://en.wikipedia.org/wiki/SPARK_(programming_language) > > Trouble is the learning curve is quite steep. ISTR a lot of effort in > the original work went into proving that the compiler subset did what it > was supposed to against all fence post boundary conditions. > > Even so you can't prevent people allowing fly by wire jets to retract > their landing gear or eject pilots whilst still on the ground.
Yup. Things like Ada or SPARK may make it easier to write safety- critical software, but there's no power like the Power of Idiocy. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by Tom Gardner April 19, 20172017-04-19
On 19/04/17 16:56, bitrex wrote:
> Even with "auto" scattered everywhere instead of a function that returns const > std::vector<MyClass<std::string..... etc> it's still all strongly-typed.
Ignoring that you can cast a horse into a camel, the /variables/ are strongly typed, but the data isn't. In other languages the data is strongly typed but the variables aren't. Horses/camels for courses.
Reply by Don Y April 19, 20172017-04-19
On 4/19/2017 9:42 AM, Martin Brown wrote:
> On 19/04/2017 17:27, Tim Wescott wrote: >> On Wed, 19 Apr 2017 11:56:56 -0400, bitrex wrote: >> >>> On 04/19/2017 11:38 AM, rickman wrote: >>> >>>>> the "auto" automatic type deduction keyword available in C++11 onwards >>>>> helps cut down on the verbosity a lot; I use it wherever possible, in >>>>> C++14 it's even available for use to automatically deduce function >>>>> return types. >>>> >>>> What people don't get about strong typing is that it isn't as much to >>>> tell the compiler what the type is as to clarify it for the programmer. >>>> Or maybe I should say it is to make the programmer consider the type so >>>> they don't make typing mistakes. >>> >>> It can't stop active malice (or extreme stupidity.) >> >> No computer language will do that. My one paid experience with Ada > > Z & VDM come close but they are languages for specification of a problem rather > than a compilable solution. > >> involved finding bugs in someone else's code. The reason that I found >> the bug was because they didn't look, and the reason they didn't look is >> because they refused to believe that the bug could be in an Ada- >> programmed box that was talking to a C-programmed box. > > If you want extreme safety critical reliability cost no object you end up on a > SPARK subset of Ada of the sort that Praxis made popular and is almost as fast > as C when compiled these days. > > https://en.wikipedia.org/wiki/SPARK_(programming_language) > > Trouble is the learning curve is quite steep. ISTR a lot of effort in the > original work went into proving that the compiler subset did what it was > supposed to against all fence post boundary conditions. > > Even so you can't prevent people allowing fly by wire jets to retract their > landing gear or eject pilots whilst still on the ground.
You can ALWAYS convert ANY type to any OTHER type. Or, implicitly treat one as another: char multiply(long multiplier, float *multiplicand) aardvark_t divide(banana_t dividend, automobile_t divisor) etc. What strongly typed languages do is make it "less easy" to do this without "conscious thought". If a developer can silence a compiler error/warning just by throwing in a cast operator (a handful of keystrokes), then he is probably more likely to resort to that "fix" instead of trying to understand WHY what he has done up to that point *is* throwing an error. Even worse, if he can add a pragma or compiler switch and blanket avoid all such warnings! Its a tough balancing act as a language designer; you want to make a language that is *useful* and allows "real work" to be done -- and efficiently! And, you want to discourage harmful practices that can result in poorer quality code. Yet, at the same time, don't want to force people to take extraordinary measures to work around the "protections" you've placed in the language as those "extraordinary measures" then become riskier to code correctly and maintain. Wanna write an OS in COBOL?
Reply by Martin Brown April 19, 20172017-04-19
On 19/04/2017 17:27, Tim Wescott wrote:
> On Wed, 19 Apr 2017 11:56:56 -0400, bitrex wrote: > >> On 04/19/2017 11:38 AM, rickman wrote: >> >>>> the "auto" automatic type deduction keyword available in C++11 onwards >>>> helps cut down on the verbosity a lot; I use it wherever possible, in >>>> C++14 it's even available for use to automatically deduce function >>>> return types. >>> >>> What people don't get about strong typing is that it isn't as much to >>> tell the compiler what the type is as to clarify it for the programmer. >>> Or maybe I should say it is to make the programmer consider the type so >>> they don't make typing mistakes. >>> >>> >> It can't stop active malice (or extreme stupidity.) > > No computer language will do that. My one paid experience with Ada
Z & VDM come close but they are languages for specification of a problem rather than a compilable solution.
> involved finding bugs in someone else's code. The reason that I found > the bug was because they didn't look, and the reason they didn't look is > because they refused to believe that the bug could be in an Ada- > programmed box that was talking to a C-programmed box.
If you want extreme safety critical reliability cost no object you end up on a SPARK subset of Ada of the sort that Praxis made popular and is almost as fast as C when compiled these days. https://en.wikipedia.org/wiki/SPARK_(programming_language) Trouble is the learning curve is quite steep. ISTR a lot of effort in the original work went into proving that the compiler subset did what it was supposed to against all fence post boundary conditions. Even so you can't prevent people allowing fly by wire jets to retract their landing gear or eject pilots whilst still on the ground. -- Regards, Martin Brown
Reply by Tim Wescott April 19, 20172017-04-19
On Wed, 19 Apr 2017 11:56:56 -0400, bitrex wrote:

> On 04/19/2017 11:38 AM, rickman wrote: > >>> the "auto" automatic type deduction keyword available in C++11 onwards >>> helps cut down on the verbosity a lot; I use it wherever possible, in >>> C++14 it's even available for use to automatically deduce function >>> return types. >> >> What people don't get about strong typing is that it isn't as much to >> tell the compiler what the type is as to clarify it for the programmer. >> Or maybe I should say it is to make the programmer consider the type so >> they don't make typing mistakes. >> >> > It can't stop active malice (or extreme stupidity.)
No computer language will do that. My one paid experience with Ada involved finding bugs in someone else's code. The reason that I found the bug was because they didn't look, and the reason they didn't look is because they refused to believe that the bug could be in an Ada- programmed box that was talking to a C-programmed box. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by bitrex April 19, 20172017-04-19
On 04/19/2017 11:38 AM, rickman wrote:

>> the "auto" automatic type deduction keyword available in C++11 onwards >> helps cut down on the verbosity a lot; I use it wherever possible, in >> C++14 it's even available for use to automatically deduce function >> return types. > > What people don't get about strong typing is that it isn't as much to > tell the compiler what the type is as to clarify it for the programmer. > Or maybe I should say it is to make the programmer consider the type so > they don't make typing mistakes. >
It can't stop active malice (or extreme stupidity.) With C++ if you're determined you can often find a way to cast things to get something to take a value or type that it shouldn't. Even with "auto" scattered everywhere instead of a function that returns const std::vector<MyClass<std::string..... etc> it's still all strongly-typed. You might not be able to tell immediately what type the function is returning; you might not even know precisely at compile-time if the return signature depends on a template parameter. But the compiler will definitely let you know and fail with an error if you try to stick the output of that function to the input of something where it doesn't belong. The Volt locks the gearshift whenever it senses that it's plugged in and prevents you from shifting out of park. That's saved me from "everyday stupidity" several times!