Re: Programming language failings [was Re: strangest systems I've sent email from]

[Jerome H. Fine]

>Dave Wade wrote:


Fortran has an EQUIVALENCE statement, COBOL has redefines. Both allows the
subversion of types at the drop of a hat.


I can think of two examples which were not so much subversion of types
as they were a lack of language flexibility:

(a)  Very early in my FORTRAN experience, I needed to calculate
  values to solve a set of differential equations.  The calculations
  could all be done using ordinary REAL floating point variables.
  However, the precision required to retain sufficient accuracy
  over the range of the solution required the state variables to be
  held as DOUBLE  PRECISION variables.  The simple solution
  was to define the increments to be added to the state variables
  as both REAL  and  DOUBLE  PRECISION and to use the
   EQUIVALENCE statement for both.  The state variables were
   managed in the same manner.  When the increments were being
   calculated, the REAL variables were used.  When the increments
   were being added to the state variables, DOUBLE  PRECISION
   were used.  In order to determine that this was a reasonable
   method, at one point only DOUBLE  PRECISION variables
   were used to see if the overall results were different.  By using
   only REAL variables during the calculation of the increments,
   calculation times was substantially reduced without sacrificing
   any overall accuracy since the increments were always a factor
   of a million or more less than the state variables.  As just one
example, one state variable was a distance of about 20,000,000
feet and each increment was at the most less than one foot.  It
sufficient to calculate the increment with a REAL variable, then
switch to DOUBLE  PRECISION when the increment was
added to the state variable.  At the end of the solution, the state
variable was reduced to about 100,000 feet.  However, using
only REAL variables would have been inaccurate and using only
DOUBLE  PRECISION was a waste of CPU time.

(b)   At one point, the value within a variable for the number of days
   since 1910 exceeded 32767 when the Y2K situation was also close
   to becoming a problem.  However, the total number of days never
   exceeded 65535, so a 4 byte integer was never required.  BUT,
   the FORTRAN flavour which was being used did not support
   UNSIGNED  variables.  The only occasion when that became a
   problem was when the number of days had to be divided by 7
   in order to determine the day of the week.  Since that FORTRAN
   compiler thought the variable was SIGNED, before dividing by 7
   the  "SXT   R0"  instruction extended the high order bit in R1 
into R0

   just prior to the  "DIV  #7,R0"  instruction.  Rather than some very
   complicated manner of managing that single situation, the best 
solution

   seemed to be to change the  "SXT  R0"  instruction to the  "CLR  R0"
   instruction - which, in effect, changed the variable being used 
during

   the divide operation to UNSIGNED from SIGNED.  If that
   FORTRAN compiler had also supported UNSIGNED variables,
   the same sort of solution as was used in (a) might have been used.
   It was recognized that making such a change to the program being
   executed would force future updates through the same requirement,
   however, there were very few  "SXT  R0" being used and only ONE
   which was followed by the  "DIV  #7,R0"  instruction.

Probably the same sort of method could also be used with C when such
situations occur.  In general, although it might be considered a subversion,
a more appropriate point of view might be that the same data requires a
different protocol in the algorithm that is being used.

Jerome Fine

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Liam Proven]

On 29 April 2016 at 22:23, Eric Smith  wrote:
> More than 95% of my work is in C,
> because that's what my clients demand, so people are usually surprised
> to hear my opinion that C is a terrible choice for almost anything.


I am in an analogous boat. Most of my career has been based on
Windows, either supporting it, working on it, writing about it or
whatever. And yet, it is one of my least-favourite OSes.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Toby Thain]

On 2016-04-30 5:20 PM, Chuck Guzis wrote:

On 04/30/2016 02:07 PM, Mouse wrote:


Reading this really gives me the impression that it's time to fork
C. There seems to me to be a need for two different languages, which
I might slightly inaccurately call the one C used to be and the one
it has become (and is becoming).



I vividly recall back in the 80s trying to take what we learned about
aggressive optimization of Fortran (or FORTRAN, take your pick) and
apply it to C.   One of the tougher nuts was the issue of pointers.
While pointers are typed in C (including void), it's very difficult for
an automatic optimizer to figure out exactly what's being pointed to,
particularly when a pointer is passed as arguments or re-used.


Indeed. John Regehr writes more on this in this recent post:
http://blog.regehr.org/archives/1307

--Toby




C++, to be sure, is much better in this respect.

--Chuck

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chuck Guzis]

On 04/30/2016 04:31 PM, Sean Conner wrote:

> I believe that's what the C99 keyword "restrict" is meant to address.

Closing the barn door after the horses have run off.  It's not in C++
and *must* be included by the programmer.  I suspect if you take 100 C99
programs, 99 of them will not include "restrict".

Because of legacy C code, "restrict" could not be assumed by default.

Sigh.

--Chuck

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Guy Sotomayor Jr]

> On Apr 30, 2016, at 6:39 AM, Diane Bruce  wrote:
> 
> On Fri, Apr 29, 2016 at 03:55:35PM -0700, Chuck Guzis wrote:
>> Those who claim that there's not much difference between C and assembly
>> language have never run into a true CISC machine--or perhaps they rely
>> only on libraries someone else has written.
> 
> Now wait a minute here. C is a very old language. When it was first written
> as a recursive descent compiler, compiler technology was very primitive.
> K style code with primitive compilers pretty much resulted in high level
> assembler. Look at the keyword 'register' and the rationale given for it.
> 
>> 
>> Writing a true global optimizing compiler that generates code as good as
>> assembly is a nearly impossible task.  When you are dealing with a
>> target machine with a large CISC set, it's really tough.
> 
> Now on that we furiously agree. One problem has been getting that through
> to people who insist that C is still a high level assembler and has
> not changed from the time when it was a hand crafted recursive descent
> LR to the modern compiler with all the lovely optimisations we can do.
> 

What does a recursive decent parser to do with code generation and
optimization?

All of the compilers I wrote (admittedly it’s been decades since I wrote one
from scratch) all had recursive decent parsers.  The output from that was a
“program tree” that the global optimizer walked to do transforms that were
the “global” optimizations.  The code generator took the output, generated
code for a synthetic machine.  That was then gone over by the target code
generator to do register allocation and code generation to the final ISA.  The
result of this flow generated pretty respectably optimized code.  The parser
was *very* removed from the code generation.  Frankly, I fail to see what
the implementation choice for the parser has on the quality (or lack thereof)
of the generated code.

> The best way of viewing it is to acknowledge that modern C is effectively
> a new language compared to old K C that had no prototypes. 

ANSI C is the “modern C” vs K C.  However, even ANSI C evolves
every few years to what is effectively a new variant of C that maintains
some backwards compatibility with older versions.

TTFN - Guy

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Sean Conner]

It was thus said that the Great Chuck Guzis once stated:
> On 04/30/2016 02:07 PM, Mouse wrote:
> 
> > Reading this really gives me the impression that it's time to fork
> > C. There seems to me to be a need for two different languages, which
> > I might slightly inaccurately call the one C used to be and the one
> > it has become (and is becoming).
> 
> 
> I vividly recall back in the 80s trying to take what we learned about
> aggressive optimization of Fortran (or FORTRAN, take your pick) and
> apply it to C.   One of the tougher nuts was the issue of pointers.
> While pointers are typed in C (including void), it's very difficult for
> an automatic optimizer to figure out exactly what's being pointed to,
> particularly when a pointer is passed as arguments or re-used.

  I believe that's what the C99 keyword "restrict" is meant to address.  

  -spc

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Sat, Apr 30, 2016 at 05:07:08PM -0400, Mouse wrote:
> > In support of this, Iâ??d encourage everyone who works with C to read Chris 
> > $
> 
> > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
> 
> Reading this really gives me the impression that it's time to fork C.
> There seems to me to be a need for two different languages, which I
> might slightly inaccurately call the one C used to be and the one it
> has become (and is becoming).

It has been effectively forked for a long time.
Same name. Look at Fortran II vs. more modern Fortran.
The pain of counting characters for the H command... ugh.

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chris Hanson]

On Apr 30, 2016, at 2:07 PM, Mouse  wrote:
> 
> Reading this really gives me the impression that it's time to fork C.
> There seems to me to be a need for two different languages, which I
> might slightly inaccurately call the one C used to be and the one it
> has become (and is becoming).
> 
> The first is the "high-level assembly" language, the one that's
> suitable for things like embedded programming in what C99 calls a
> standalone environment, kernel and low-level library implementations,
> and the like, where you want to do whatever's reasonable from the point
> of view of someone who knows the target machine architecture, even if
> it's formally undefined by the language.
> 
> The second is more the language the author of those posts is talking
> about, where the compiler is allowed to do surprising things for the
> sake of performance.

The author of those posts is the creator and lead developer of LLVM, clang, and 
Swift, and I think he would argue that the second case is also best served by 
the compiler in the first case, because you absolutely want the best 
performance and code size possible.

I'll note too that people are working in progressively more back ends for LLVM 
& clang for embedded uses.

  -- Chris

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chuck Guzis]

On 04/30/2016 02:07 PM, Mouse wrote:

> Reading this really gives me the impression that it's time to fork
> C. There seems to me to be a need for two different languages, which
> I might slightly inaccurately call the one C used to be and the one
> it has become (and is becoming).


I vividly recall back in the 80s trying to take what we learned about
aggressive optimization of Fortran (or FORTRAN, take your pick) and
apply it to C.   One of the tougher nuts was the issue of pointers.
While pointers are typed in C (including void), it's very difficult for
an automatic optimizer to figure out exactly what's being pointed to,
particularly when a pointer is passed as arguments or re-used.

C++, to be sure, is much better in this respect.

--Chuck

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Mouse]

> In support of this, Iâ??d encourage everyone who works with C to read Chris $

> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

Reading this really gives me the impression that it's time to fork C.
There seems to me to be a need for two different languages, which I
might slightly inaccurately call the one C used to be and the one it
has become (and is becoming).

The first is the "high-level assembly" language, the one that's
suitable for things like embedded programming in what C99 calls a
standalone environment, kernel and low-level library implementations,
and the like, where you want to do whatever's reasonable from the point
of view of someone who knows the target machine architecture, even if
it's formally undefined by the language.

The second is more the language the author of those posts is talking
about, where the compiler is allowed to do surprising things for the
sake of performance.

The zero_array example slightly bothers me, because the optimization
into a memset is valid only when floating-point zero is all-bits-zero;
while this is something the compiler can know, and is true on "all"
machines, the way it's written doesn't call it out as a
machine-dependent optimization, quite possibly leading people to write
the memset themselves in such cases, producing a different bug.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Sat, Apr 30, 2016 at 12:28:35PM -0700, Chris Hanson wrote:
> On Apr 30, 2016, at 11:43 AM, Diane Bruce  wrote:
> > 
> > We cannot use the same outdated ideas we used to use for 'C'
> > that we used 40 years ago today. Compilers have improved.
> > Know your tools. And that's all I have said. 
> 
> In support of this, I’d encourage everyone who works with C to read Chris 
> Lattner’s “What Every C Programmer Should Know About Undefined Behavior” 
> series from the LLVM blog:
> 
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

Yes, it's an excellent series. 

> 
> C has fairly well-defined semantics, they just aren’t necessarily what you 
> think they are, and optimizers are taking advantage of them (under the “as 
> if” rule) such that a developer’s idea of what assembly a specific section of 
> C code should generate is not all that accurate these days.
> 

Indeed.

>   -- Chris
> 
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chris Hanson]

On Apr 30, 2016, at 11:43 AM, Diane Bruce  wrote:
> 
> We cannot use the same outdated ideas we used to use for 'C'
> that we used 40 years ago today. Compilers have improved.
> Know your tools. And that's all I have said. 

In support of this, I’d encourage everyone who works with C to read Chris 
Lattner’s “What Every C Programmer Should Know About Undefined Behavior” series 
from the LLVM blog:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

C has fairly well-defined semantics, they just aren’t necessarily what you 
think they are, and optimizers are taking advantage of them (under the “as if” 
rule) such that a developer’s idea of what assembly a specific section of C 
code should generate is not all that accurate these days.

  -- Chris

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Sat, Apr 30, 2016 at 11:53:40AM -0600, Eric Smith wrote:
> On Sat, Apr 30, 2016 at 7:39 AM, Diane Bruce  wrote:
> > Now on that we furiously agree. One problem has been getting that through
> > to people who insist that C is still a high level assembler and has
> > not changed from the time when it was a hand crafted recursive descent
> > LR to the modern compiler with all the lovely optimisations we can do.
> 
> Sure, the compilers are way better than they were back then. That
> doesn't make the language itself any higher level. The semantic level

To be clear, I never said it did make it any higher level.

> of the language and the level of abstraction it provides have barely
> changed, so the language itself is still a mostly portable substitute

We have for all but specialized applications taken the procrustean approach
and our processors mostly have started to fit the language. 
I remember being related a story from when I was working for
CDC Canada of a Unix port that was done for one of the Cybers. They
essentially emulated a PDP-11 then ported unix on top of that. *shudder*

Oddly, C is not a good fit for the Transputer.

> for assembly language. As Chuck points out, it isn't a good substitute
> for any particular CISC assembly language, but then those aren't
> portable at all.

Also to be clear, I also agreed with that statement.

Are we talking at cross purposes or what? My point is simple.
We cannot use the same outdated ideas we used to use for 'C'
that we used 40 years ago today. Compilers have improved.
Know your tools. And that's all I have said. 

> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Eric Smith]

On Sat, Apr 30, 2016 at 7:39 AM, Diane Bruce  wrote:
> Now on that we furiously agree. One problem has been getting that through
> to people who insist that C is still a high level assembler and has
> not changed from the time when it was a hand crafted recursive descent
> LR to the modern compiler with all the lovely optimisations we can do.

Sure, the compilers are way better than they were back then. That
doesn't make the language itself any higher level. The semantic level
of the language and the level of abstraction it provides have barely
changed, so the language itself is still a mostly portable substitute
for assembly language. As Chuck points out, it isn't a good substitute
for any particular CISC assembly language, but then those aren't
portable at all.

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Peter Cetinski]

> On Apr 30, 2016, at 9:39 AM, Diane Bruce  wrote:
> 
> Now wait a minute here. C is a very old language. When it was first written
> as a recursive descent compiler, compiler technology was very primitive.
> K style code with primitive compilers pretty much resulted in high level
> assembler. Look at the keyword 'register' and the rationale given for it.
> 
> Now on that we furiously agree. One problem has been getting that through
> to people who insist that C is still a high level assembler and has
> not changed from the time when it was a hand crafted recursive descent
> LR to the modern compiler with all the lovely optimisations we can do.
> 
> Diane
> -- 
> - d...@freebsd.org d...@db.net http://www.db.net/~db

A good example from my area of vintage computing enthusiasm is the Misosys C 
Compiler for the TRS-80.  It will compile pure K C into intermediate assembly 
language files that you would then feed into the Misosys MRAS assembly language 
development system just as if you were developing the assembly from scratch.  
Of course, the entire process is deathly slow on original hardware and the 
level of optimization is no where near what you could achieve with hand-written 
assembly, both of which are critical concerns on 2 Mhz Z80 systems for any 
non-trivial applications.

https://archive.org/details/MC_C-Language_Compiler_1985_sys_PDF

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Fri, Apr 29, 2016 at 03:55:35PM -0700, Chuck Guzis wrote:
> Those who claim that there's not much difference between C and assembly
> language have never run into a true CISC machine--or perhaps they rely
> only on libraries someone else has written.

Now wait a minute here. C is a very old language. When it was first written
as a recursive descent compiler, compiler technology was very primitive.
K style code with primitive compilers pretty much resulted in high level
assembler. Look at the keyword 'register' and the rationale given for it.

> 
> Writing a true global optimizing compiler that generates code as good as
> assembly is a nearly impossible task.  When you are dealing with a
> target machine with a large CISC set, it's really tough.

Now on that we furiously agree. One problem has been getting that through
to people who insist that C is still a high level assembler and has
not changed from the time when it was a hand crafted recursive descent
LR to the modern compiler with all the lovely optimisations we can do.

The best way of viewing it is to acknowledge that modern C is effectively
a new language compared to old K C that had no prototypes. 


> 
> Speaking from experience, again.

ditto.

> 
> 
> --Chuck
> 
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

RE: Programming language failings [was Re: strangest systems I've sent email from]

[Dave Wade]

Fortran has an EQUIVALENCE statement, COBOL has redefines. Both allows the
subversion of types at the drop of a hat. 

Dave

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mouse
> Sent: 30 April 2016 02:56
> To: cctalk@classiccmp.org
> Subject: Re: Programming language failings [was Re: strangest systems I've
> sent email from]
> 
> >> The main thing C has that most other languages don't is *unsafe* data
> >> typing - the ability to subvert the type system at the drop of a
> >> cast, and the programming tradition to do this a lot.
> > {Sighs.}  You really seem to have it out for C.
> 
> I didn't write that the double-quoted text, but it seems to me that you
are
> reading a pejorative attitude into it that I'm not sure belongs there.
That _is_
> one of the bigger things C has - and, like many language features, it's a
double-
> edged sword.  It makes possible a lot of things, many useful, many
dangerous,
> and in some cases, even, both at once.
> 
> It is possible to come fairly close to type-safe C.  But even in the most
type-safe
> of my programs, I sometimes find a need to break the type safety for one
> reason or another - and C lets me do that without extreme gyrations.  (I
> remember the FORTRAN I used in my larval phase, back in the 1980s under
> VMS; IIRC doing the equivalent of following a pointer was rather difficult
> without the use of a helper routine and a language extension.)
> 
> /~\ The ASCII   Mouse
> \ / Ribbon Campaign
>  X  Against HTML  mo...@rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Josh Dersch]

On 4/29/16 6:02 PM, Ian S. King wrote:

I would actually argue that C++, Java and C# are not object-oriented
languages.  They are languages with syntax that supports object-oriented
programming - note that the original C++ was a preprocessor for a C
compiler.


I'll disagree with this on behalf of C# and Java.  (C++ I agree with; 
the OO portions of C++ are very weak.  Then there are the 
metaprogramming facilities which make me wish maybe Strostrup had played 
with Lisp a bit more...)


C# and Java provide real objects, and real reflective capabilities. 
They're built on top of a stack-oriented virtual machine runtime (and 
JIT compilation) that was explicitly designed to support objects as 
first-class entities.  With reflection, one can find out at runtime what 
methods and fields an object exposes, iterate over them, invoke methods, 
and use that metadata programmatically for all manner of useful things.  
Further, C# and Java's objects provide real encapsulation and real 
run-time safety -- private data is really private, you can't poke at 
random memory (*).  They're not as pure of an OO language as Smalltalk 
is and they're not nearly as flexible, but few languages are :).


- Josh

(*) well, you can in C# (unsure about Java) but you have to explicitly 
state that you're doing something unsafe when you do it. It's handy to 
have available but is rarely needed.

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Mouse]

>> The main thing C has that most other languages don't is *unsafe*
>> data typing - the ability to subvert the type system at the drop of
>> a cast, and the programming tradition to do this a lot.
> {Sighs.}  You really seem to have it out for C.

I didn't write that the double-quoted text, but it seems to me that you
are reading a pejorative attitude into it that I'm not sure belongs
there.  That _is_ one of the bigger things C has - and, like many
language features, it's a double-edged sword.  It makes possible a lot
of things, many useful, many dangerous, and in some cases, even, both
at once.

It is possible to come fairly close to type-safe C.  But even in the
most type-safe of my programs, I sometimes find a need to break the
type safety for one reason or another - and C lets me do that without
extreme gyrations.  (I remember the FORTRAN I used in my larval phase,
back in the 1980s under VMS; IIRC doing the equivalent of following a
pointer was rather difficult without the use of a helper routine and a
language extension.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Christian Gauger-Cosgrove]

On 29 April 2016 at 15:43, Chuck Guzis  wrote:
> I don't know what people do now.
>
The answer, apparently:

Step 1: Install package manager of choice.
Step 2: Create a blank project using the package manager and Framework
X (which is the "in" thing this week).
Step 3: Slap together two lines of code which are:
theThing.do();
theThing.show();
Step 4: Pray to every deity in existence no one changes anything in
the TWENTY-EIGHT THOUSAND dependencies of your blank file.
Step 4b: Shoot yourself in the head when someone "unpublishes" their
shitty eleven line implementation of the left pad function/algorithm
which promptly breaks your everything. No you didn't use it, but it's
somewhere inside your 28000 (yes, really, twenty-eight thousand,
that's not a typo) dependencies needed to work your blank
jspm/npm-based app template.
Step 5: Shoot yourself in the head again because "Dude! Like,
Framework X is s uncool right now. Everyone's using Framework Y!"
or Framework X completely changes everything in the way it functions.
Because Reasons™.


Seriously, here's a blog post about the relatively recent fact that
one person managed to break some of the "big name" JavaScript
frameworks/apps/whatever-the-shit-they're-called-now:

"Functions are not packages," the author states, and I agree fully.
This is considered a "package" in the JavaScript world of the npm
package manager:
return toString.call(arr) == '[object Array]';
Yes, one line. The "isArray" package, on which seventy-two (72) other
packages depend.

Best thing is there's people in the comments defending this kind of
insanity as "hiding complexity." If you can't write something as
simple as a left padding function yourself because it's too complex,
why in the name of all things holy should I let you even go near any
kind of software development?



Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Ian S. King]

I would actually argue that C++, Java and C# are not object-oriented
languages.  They are languages with syntax that supports object-oriented
programming - note that the original C++ was a preprocessor for a C
compiler.

Smalltalk, Simula, and more recently languages like Ruby are
object-oriented languages.

You can write object-oriented code in any language, if you construct your
code to express the abstractions of OO.  It's easier, of course, in a
language that has syntactic sugar like 'classes' or 'interfaces'.

And IMHO C was designed for writing operating systems and tools, and that's
where it shines.  It's still highly relevant for embedded systems, for
instance.  Again IMHO, the quality of C compilers is such that the relative
benefits/costs of C vs. assembler usually lean toward using C, because it
does support higher-level abstractions (especially helpful on RISC
architectures) and it can be written to be more transparent - bringing us
back to the original point of how you use the tools.  -- Ian

On Fri, Apr 29, 2016 at 1:37 PM, Raymond Wiker  wrote:

>
> > On 29 Apr 2016, at 22:31 , Diane Bruce  wrote:
> >
> > On Fri, Apr 29, 2016 at 02:23:55PM -0600, Eric Smith wrote:
> >> On Fri, Apr 29, 2016 at 12:59 PM, Ian S. King  wrote:
> >>> C is a lot like that saw - it doesn't have a lot of guards on it, and
> you
> >>> can do stupid things.
> >>
> >> The problem is that C doesn't just allow you to do stupid things, it's
> >> actively encouraged. C doesn't just let you aim at your foot, it
> >> defaults to aiming at your foot.
> >>
> >> C is not bad as a fairly portable assembly language, but it is NOT a
> >> high-level language.
> >
> > Yes it is known as a high level assembler.
>
> Taking this a bit further:
>
> C++ is an object-oriented, high-level assembler.
> Java is an object-oriented, high-level assembler with support wheels.
> C# is an object-oriented, high-level assembler with support wheels that
> are not interchangeable with those of Java.
>
> At least C is a useful language for coding the lowest level of Lisp
> implementations :-)
>
>
>


-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chuck Guzis]

Those who claim that there's not much difference between C and assembly
language have never run into a true CISC machine--or perhaps they rely
only on libraries someone else has written.

Writing a true global optimizing compiler that generates code as good as
assembly is a nearly impossible task.  When you are dealing with a
target machine with a large CISC set, it's really tough.

Speaking from experience, again.


--Chuck

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Mouse]

>> I like C for the most part, what you see is what you get.
> Apparently you've never been burned by the way it handles bit fields.

Not that I wrote the double-quoted line above, but...no, I don't think
I have.  Certainly not recently enough to remember it.  But then, I
don't assume more about bit-fields than the language promises.

A lot of people seem to assume that "the way it works for me on my dev
box" is what the language promises.  This is a recipe for nasty
surprises in almost any system/language/etc.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Fri, Apr 29, 2016 at 01:36:29PM -0700, Al Kossow wrote:
> 
> 
> On 4/29/16 1:34 PM, ben wrote:
> 
> >> The problem is that C doesn't just allow you to do stupid things, it's
> >> actively encouraged. C doesn't just let you aim at your foot, it
> >> defaults to aiming at your foot.
> >>
> > I like C for the most part, what you see is what you get.
> 
> Apparently you've never been burned by the way it handles bit fields.

bit fields is another part of C that should be removed ;)

It seemed like a good idea when we started ;)

> 
> 
> 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Fred Cisin]

On Fri, 29 Apr 2016, Eric Smith wrote:

The problem is that C doesn't just allow you to do stupid things, it's
actively encouraged. C doesn't just let you aim at your foot, it
defaults to aiming at your foot.


I like the title that Holub chose for his book:
"Enough Rope To Shoot Yourself In The Foot"

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Raymond Wiker]

> On 29 Apr 2016, at 22:31 , Diane Bruce  wrote:
> 
> On Fri, Apr 29, 2016 at 02:23:55PM -0600, Eric Smith wrote:
>> On Fri, Apr 29, 2016 at 12:59 PM, Ian S. King  wrote:
>>> C is a lot like that saw - it doesn't have a lot of guards on it, and you
>>> can do stupid things.
>> 
>> The problem is that C doesn't just allow you to do stupid things, it's
>> actively encouraged. C doesn't just let you aim at your foot, it
>> defaults to aiming at your foot.
>> 
>> C is not bad as a fairly portable assembly language, but it is NOT a
>> high-level language.
> 
> Yes it is known as a high level assembler.

Taking this a bit further:

C++ is an object-oriented, high-level assembler.
Java is an object-oriented, high-level assembler with support wheels.
C# is an object-oriented, high-level assembler with support wheels that are not 
interchangeable with those of Java.

At least C is a useful language for coding the lowest level of Lisp 
implementations :-)

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Al Kossow]

On 4/29/16 1:34 PM, ben wrote:

>> The problem is that C doesn't just allow you to do stupid things, it's
>> actively encouraged. C doesn't just let you aim at your foot, it
>> defaults to aiming at your foot.
>>
> I like C for the most part, what you see is what you get.

Apparently you've never been burned by the way it handles bit fields.

Re: Programming language failings [was Re: strangest systems I've sent email from]

[ben]

On 4/29/2016 2:23 PM, Eric Smith wrote:

On Fri, Apr 29, 2016 at 12:59 PM, Ian S. King  wrote:

C is a lot like that saw - it doesn't have a lot of guards on it, and you
can do stupid things.


The problem is that C doesn't just allow you to do stupid things, it's
actively encouraged. C doesn't just let you aim at your foot, it
defaults to aiming at your foot.


I like C for the most part, what you see is what you get.
With other stuff, it is too abstract. What does it do?
Ben.

For humor see this link, but only if you have shoes on.

http://www.thealmightyguru.com/Humor/Docs/ShootYourselfInTheFoot.html

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Diane Bruce]

On Fri, Apr 29, 2016 at 02:23:55PM -0600, Eric Smith wrote:
> On Fri, Apr 29, 2016 at 12:59 PM, Ian S. King  wrote:
> > C is a lot like that saw - it doesn't have a lot of guards on it, and you
> > can do stupid things.
> 
> The problem is that C doesn't just allow you to do stupid things, it's
> actively encouraged. C doesn't just let you aim at your foot, it
> defaults to aiming at your foot.
> 
> C is not bad as a fairly portable assembly language, but it is NOT a
> high-level language.

Yes it is known as a high level assembler.


-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Eric Smith]

On Fri, Apr 29, 2016 at 12:59 PM, Ian S. King  wrote:
> C is a lot like that saw - it doesn't have a lot of guards on it, and you
> can do stupid things.

The problem is that C doesn't just allow you to do stupid things, it's
actively encouraged. C doesn't just let you aim at your foot, it
defaults to aiming at your foot.

C is not bad as a fairly portable assembly language, but it is NOT a
high-level language.

> But you can do very powerful things that are
> difficult or impossible in, say, Python, which is also a very good and
> useful tool.

I've programmed in C professionally for 27 years, mostly doing OS
kernel, device driver, and network stack work. Aside from the
difference in runtime performance, I am hard-pressed to think of any
specific function I've ever written in C that couldn't be expressed
just as easily or even more so in Python.  Obviously you can't write
kernel, driver, or network stack code for most kernels in Python, but
that's not due to any failings of the expressiveness of Python.

I'm occasionally asked what my favorite programming language is, and I
don't have a good answer, other than that in general I prefer
languages with type safety and memory safety. I like Java somewhat,
and I like Ada even more (recent versions have fixed most of the
deficiencies of the original Ada '83 standard).  I like Modula 3
(which is much different than Modula 2), but have never had much
opportunity to use it.  I'd like to learn Haskell, and perhaps OCaml,
but don't have the time to invest. More than 95% of my work is in C,
because that's what my clients demand, so people are usually surprised
to hear my opinion that C is a terrible choice for almost anything.

> Don't blame the tools - blame an educational system that doesn't teach
> software engineering practice, but just teaches tools.  "Hey, hold my beer
> and watch this!"  -- Ian

I agree, except that I don't believe there is actually such a thing as
"Software Engineering" yet, even though I've held jobs with the title
"Software Engineer".

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Paul Koning]

> On Apr 29, 2016, at 4:03 PM, Al Kossow  wrote:
> 
> 
> 
> On 4/29/16 12:43 PM, Chuck Guzis wrote:
> 
>> I don't know what people do now.
>> 
> 
> Find libraries that other people have written, glue something together, and
> move on to the next project/job.
> 
> Then scream if you try to rebuild it later and the new version of the 
> libraries
> didn't maintain backwards compatibility and the guy who glued it togther is 
> gone.

Yes, backward compatibility is that a lot of people have never even heard of, 
let alone care about.  Sigh.  Networking people tend to be better at this 
(though even there you can find failures).

paul

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Al Kossow]

On 4/29/16 12:43 PM, Chuck Guzis wrote:

> I don't know what people do now.
> 

Find libraries that other people have written, glue something together, and
move on to the next project/job.

Then scream if you try to rebuild it later and the new version of the libraries
didn't maintain backwards compatibility and the guy who glued it togther is 
gone.

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Chuck Guzis]

On 04/29/2016 11:59 AM, Ian S. King wrote:
> 
> Don't blame the tools - blame an educational system that doesn't
> teach software engineering practice, but just teaches tools.  "Hey,
> hold my beer and watch this!"  -- Ian

Maybe--I can't say.   At a very early stage in my career, I was exposed
to "coding standards" as well as "code review".  I took great pride in
that few reviewers had any quibbles with my code.  Those coding
standards extended to the type of commentary required as well as the
convention for naming routines, variables and labels.  It was
anticipated that commentary for a routine could be automatically
extracted and be close to what was expected for an internal maintenance
document.   Do it enough and it becomes a habit for life.

This is from when assembly was the language of the day.

I've run across old programs that I found myself marveling at for the
clarity and discipline of coding, only to find that it was some program
that I'd forgotten that I'd written did 30 years before.

But all that was in the day of punched cards and printed listings and
red pencils.

I don't know what people do now.

--Chuck

Re: Programming language failings [was Re: strangest systems I've sent email from]

[Ian S. King]

On Fri, Apr 29, 2016 at 11:22 AM, Mouse  wrote:

> > My gripe with C is essentially the same as my grumbles with APL--it's
> > far too easy to write obscure code and not document it.
>
> "There is not now, nor will there ever be, a language in which it's the
> least bit difficult to write bad code."  Not quite true, of course;
> there are languages in which it's remarkably difficult to write _any_
> code.  But it _is_ true that there is not, nor (I believe) will there
> ever be, any language in which it's substantially more difficult to
> write bad code than good code.  (Of course, some languages make
> _certain kinds_ of bad code more difficult)
>
> > Why it appeals to this particular foible of human nature has always
> > been a mystery to me.
>
> I doubt it's C that appeals particularly.  I've done my share of
> writing obscure code and not documenting it (I like to think I've
> learnt better, at least somewhat, by now), and C is relevant only in
> that it happens to be the language I most commonly work in.  I find the
> same tendency showing up in other languages, anything from sh to DSLs.
>
> I have an end-cut saw that I've told my Spousal Unit she should not use.
It's not a bad or defective tool - in fact, it's a very useful and powerful
tool.  But IMHO she lacks the 'situational awareness' to safely deal with
an unprotected blade going back and forth several thousand times a minute.

C is a lot like that saw - it doesn't have a lot of guards on it, and you
can do stupid things.  But you can do very powerful things that are
difficult or impossible in, say, Python, which is also a very good and
useful tool.

Don't blame the tools - blame an educational system that doesn't teach
software engineering practice, but just teaches tools.  "Hey, hold my beer
and watch this!"  -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."