Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #54232 > unrolled thread

"Is C Still Relevant in the 21st Century?"

Back to article view | Back to comp.lang.c

Contents

  "Is C Still Relevant in the 21st Century?" Lynn McGuire <lmc@winsim.com> - 2014-12-10 18:17 -0600
    Re: "Is C Still Relevant in the 21st Century?" G G <gdotone@gmail.com> - 2014-12-10 22:55 -0800
      Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-11 09:01 +0000
        Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 02:41 -0800
          Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 11:08 +0000
            Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-16 13:06 +0000
              Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 13:14 +0000
              Re: "Is C Still Relevant in the 21st Century?" Keith Thompson <kst-u@mib.org> - 2014-12-16 07:29 -0800
                Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-16 16:23 +0000
            Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 17:23 -0800
              Re: "Is C Still Relevant in the 21st Century?" Keith Thompson <kst-u@mib.org> - 2014-12-16 18:06 -0800
                Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:35 -0800
                  Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 16:01 +0000
                    Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:30 -0800
                  Re: "Is C Still Relevant in the 21st Century?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-20 18:45 +0000
                    Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:58 -0800
      Re: "Is C Still Relevant in the 21st Century?" Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-12-12 11:15 +0100
    Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-11 04:11 -0800
      Re: "Is C Still Relevant in the 21st Century?" "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-11 17:36 +0100
        Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-11 08:44 -0800
          Re: "Is C Still Relevant in the 21st Century?" "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-11 17:53 +0100
            Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-11 09:57 -0800
        Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-11 15:21 -0800
          Re: "Is C Still Relevant in the 21st Century?" "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-12 11:14 +0100
    Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-11 05:06 -0800
      Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-11 05:48 -0800
        Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-11 06:17 -0800
      Re: "Is C Still Relevant in the 21st Century?" JohnF <john@please.see.sig.for.email.com> - 2014-12-13 10:22 +0000
        Re: "Is C Still Relevant in the 21st Century?" BartC <bc@freeuk.com> - 2014-12-13 10:34 +0000
          Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-13 14:04 +0000
            Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-13 07:42 -0800
              Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-13 20:52 +0000
                Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 00:23 -0800
                  Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-14 12:07 +0000
                Re: "Is C Still Relevant in the 21st Century?" BartC <bc@freeuk.com> - 2014-12-14 13:20 +0000
                  Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-14 22:43 +0000
                    Re: "Is C Still Relevant in the 21st Century?" BartC <bc@freeuk.com> - 2014-12-15 01:33 +0000
                      Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 02:39 +0000
                    Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 03:16 -0800
                      Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-15 17:24 +0000
                        Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-15 18:01 +0000
                          Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-15 14:25 -0800
                            Re: "Is C Still Relevant in the 21st Century?" Richard Damon <Richard@Damon-Family.org> - 2014-12-16 08:46 -0500
                              Re: "Is C Still Relevant in the 21st Century?" fir <profesor.fir@gmail.com> - 2014-12-16 05:59 -0800
                                Re: "Is C Still Relevant in the 21st Century?" Richard Damon <Richard@Damon-Family.org> - 2014-12-17 08:21 -0500
                                  Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:27 -0800
                              Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 14:29 +0000
                          Re: "Is C Still Relevant in the 21st Century?" Richard Damon <Richard@Damon-Family.org> - 2014-12-16 08:51 -0500
                            Re: "Is C Still Relevant in the 21st Century?" Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 14:30 +0000
                        Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-15 10:02 -0800
            Re: "Is C Still Relevant in the 21st Century?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-14 00:36 +0000
              Re: "Is C Still Relevant in the 21st Century?" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-14 01:22 +0000
                Re: "Is C Still Relevant in the 21st Century?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-14 07:35 +0000
                  Re: "Is C Still Relevant in the 21st Century?" Öö Tiib <ootiib@hot.ee> - 2014-12-14 04:39 -0800
                    Re: "Is C Still Relevant in the 21st Century?" James Kuyper <jameskuyper@verizon.net> - 2014-12-14 08:14 -0500
                    Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-14 08:02 -0800
              Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:52 -0800
          Re: "Is C Still Relevant in the 21st Century?" rick.c.hodgin@gmail.com - 2014-12-13 06:39 -0800
          Re: "Is C Still Relevant in the 21st Century?" Les Cargill <lcargill99@comcast.com> - 2014-12-13 15:57 -0600
            Re: "Is C Still Relevant in the 21st Century?" BGB <cr88192@hotmail.com> - 2014-12-15 09:51 -0600
              Re: "Is C Still Relevant in the 21st Century?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-12-15 20:30 +0000
                Re: "Is C Still Relevant in the 21st Century?" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-15 21:29 +0000
                Re: "Is C Still Relevant in the 21st Century?" BGB <cr88192@hotmail.com> - 2014-12-15 21:23 -0600
                  Re: "Is C Still Relevant in the 21st Century?" Kaz Kylheku <kaz@kylheku.com> - 2014-12-16 04:14 +0000
                    Re: "Is C Still Relevant in the 21st Century?" BGB <cr88192@hotmail.com> - 2014-12-16 09:11 -0600
                      Re: "Is C Still Relevant in the 21st Century?" Robert Wessel <robertwessel2@yahoo.com> - 2014-12-16 13:13 -0600
                        Re: "Is C Still Relevant in the 21st Century?" BartC <bc@freeuk.com> - 2014-12-16 19:27 +0000
                          Re: "Is C Still Relevant in the 21st Century?" BGB <cr88192@hotmail.com> - 2014-12-16 16:11 -0600
                            Re: "Is C Still Relevant in the 21st Century?" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-16 14:39 -0800
                              Re: "Is C Still Relevant in the 21st Century?" BGB <cr88192@hotmail.com> - 2014-12-16 18:25 -0600
        Re: "Is C Still Relevant in the 21st Century?" Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 05:13 -0800
    Re: "Is C Still Relevant in the 21st Century?" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-12-11 07:28 -0800
    Re: "Is C Still Relevant in the 21st Century?" Melzzzzz <mel@zzzzz.com> - 2014-12-11 17:29 +0100
    Re: "Is C Still Relevant in the 21st Century?" Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2014-12-11 17:59 +0000
      Re: "Is C Still Relevant in the 21st Century?" Melzzzzz <mel@zzzzz.com> - 2014-12-11 19:05 +0100
    Re: "Is C Still Relevant in the 21st Century?" Rosario193 <Rosario@invalid.invalid> - 2014-12-12 11:37 +0100
    Re: "Is C Still Relevant in the 21st Century?" John Bode <jfbode1029@gmail.com> - 2014-12-15 10:49 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#54276

fir wrote on day 2014‒12‒11:
>W dniu czwartek, 11 grudnia 2014 17:36:57 UTC+1 użytkownik ocq (an evil corporate man) napisał:
>> fir wrote on day 2014‒12‒11:
>> >module prog;
>> >links windows, math, stdio;
>> who would care about what he is using if there is anyway and he would
>> must declare he is using it for compiler? it՚s relict of times when
>> names of symbol could be the same, and when… what… does header files
>> represent some compatibility if used as whole files? rather not.
>
>not understood you
I think so. because probably I haven՚t give a solution you could copy &
past into your project. :-> then the best is: to not understand what
you mean and I really want to have. :->

>here windows, math, obj are modle (lib) names, not symbols
>could use it like 
just like Python programming language but there are no C libraries. C
libraries also aren՚t of C property… :-)

>headers should do not exist, whole declatations should be embodied in modules where now only symbol names are embodied
and more…

[toc] | [prev] | [next] | [standalone]

#54286

W dniu czwartek, 11 grudnia 2014 17:53:25 UTC+1 użytkownik ocq (an evil corporate man) napisał:
> fir wrote on day 2014‒12‒11:
> >W dniu czwartek, 11 grudnia 2014 17:36:57 UTC+1 użytkownik ocq (an evil corporate man) napisał:
> >> fir wrote on day 2014‒12‒11:
> >> >module prog;
> >> >links windows, math, stdio;
> >> who would care about what he is using if there is anyway and he would
> >> must declare he is using it for compiler? it՚s relict of times when
> >> names of symbol could be the same, and when… what… does header files
> >> represent some compatibility if used as whole files? rather not.
> >
> >not understood you
> I think so. because probably I haven՚t give a solution you could copy &
> past into your project. :-> then the best is: to not understand what
> you mean and I really want to have. :->
> 

you could repeat slightly different way  with more words, then i could answer, not see any problem with this - just dont understood what you mean

> >here windows, math, obj are modle (lib) names, not symbols
> >could use it like 
> just like Python programming language but there are no C libraries. C
> libraries also aren՚t of C property… :-)
> 
> >headers should do not exist, whole declatations should be embodied in modules where now only symbol names are embodied
> and more…

[toc] | [prev] | [next] | [standalone]

#54319

On Thursday, December 11, 2014 4:36:57 PM UTC, ocq (an evil corporate man) wrote:
> fir wrote on day 2014‒12‒11:
> >module prog;
> >links windows, math, stdio;
> who would care about what he is using if there is anyway and he would
> must declare he is using it for compiler? it՚s relict of times when
> names of symbol could be the same, and when… what… does header files
> represent some compatibility if used as whole files? rather not.
>
The linker doesn't have a concept of hierarchy.

Let's say we've got a grammar checker. Obviously it's going to call
some low-level string functions, like to duplicate a string.
We might also have a spell checker that suggests words on the basis 
of the misspelling, and surrounding words. That's also going to
call similar low-level string functions.
When we write word processor, we're going to want to link both
the grammar checker and the spell checker. Which will cause a clash 
is the low-level string functions use the obvious identifiers.

[toc] | [prev] | [next] | [standalone]

#54344

Malcolm McLean wrote on day 2014‒12‒11:
>On Thursday, December 11, 2014 4:36:57 PM UTC, ocq (an evil corporate man) wrote:
>> fir wrote on day 2014‒12‒11:
>> >module prog;
>> >links windows, math, stdio;
>> who would care about what he is using if there is anyway and he would
>> must declare he is using it for compiler? it՚s relict of times when
>> names of symbol could be the same, and when… what… does header files
>> represent some compatibility if used as whole files? rather not.
>>
>The linker doesn't have a concept of hierarchy.
>
>Let's say we've got a grammar checker. Obviously it's going to call
>some low-level string functions, like to duplicate a string.
>We might also have a spell checker that suggests words on the basis 
>of the misspelling, and surrounding words. That's also going to
>call similar low-level string functions.
>When we write word processor, we're going to want to link both
>the grammar checker and the spell checker. Which will cause a clash 
>is the low-level string functions use the obvious identifiers.
I՚m not sure I know what you wrote exactly about, almost sure.
I think you present example when threre are first: two projects of
·libraries·, and next: project of —I could say— application
(executable) which is to use the libraries, link to. however the
libraries already have (or probably) the same names of symbols inside
export tables or inside import tables of some other libraries which
symbols they import in own projects. maybe export tables, second is
handled by dynamic linker.
then including header files has nothing to do with this problem. if a
one could think that the functionality of informing compiler about
libraries to link (compiler commandline arguments) does something with
the problem, then still not. because the problem is the application has
to use these two libraries and there must be anyway replacement of
names which was created without some concept of namespaces. the last
(replacement) is solution is available in compilers since many years.
so… :-) the problem is…? :-]

[toc] | [prev] | [next] | [standalone]

#54245

On Thursday, December 11, 2014 12:17:38 AM UTC, Lynn McGuire wrote:
> "Is C Still Relevant in the 21st Century?"
>     http://news.dice.com/2014/12/08/c-still-relevant-21st-century/
> 
> "Many programming languages have come and gone since Dennis Ritchie devised C in 
> 1972, and yet C has not only survived three major revisions, but continues to thrive. 
> Large chunks of Windows were written in C, along with most of Linux."
> 
Virtually every job advert mentions a language, and it's rarely C, except for embedded
programming.
Apple has developed Objective C and Microsoft C sharp. Other companies use C++
systems. However normally the extended code isn't doing very much, it's just gift-
wrapping underlying C functions. 

[toc] | [prev] | [next] | [standalone]

#54248

W dniu czwartek, 11 grudnia 2014 14:06:34 UTC+1 użytkownik Malcolm McLean napisał:
> On Thursday, December 11, 2014 12:17:38 AM UTC, Lynn McGuire wrote:
> > "Is C Still Relevant in the 21st Century?"
> >     http://news.dice.com/2014/12/08/c-still-relevant-21st-century/
> > 
> > "Many programming languages have come and gone since Dennis Ritchie devised C in 
> > 1972, and yet C has not only survived three major revisions, but continues to thrive. 
> > Large chunks of Windows were written in C, along with most of Linux."
> > 
> Virtually every job advert mentions a language, and it's rarely C, except for embedded
> programming.
> Apple has developed Objective C and Microsoft C sharp. Other companies use C++
> systems. However normally the extended code isn't doing very much, it's just gift-
> wrapping underlying C functions.

thats right - more clearly to say JAVA, C#, OBJ-C are just C  (and they take the best part from it), I once a go was doing some test and ported some c code int java version - what showed - the functions are -> just the same text <- 






// main.java 

import java.util.*; 

public class main 
{ 

static int mandelbrot_n(  double cRe,  double cIm,  int max_iter ) 
{ 


  double re = 0; 
  double im = 0; 

   for(int n=0; n<=max_iter; n++) 
   { 

     if( re * re + im * im > 4.0 ) return n; 

     double re_n = re * re - im * im + cRe; 
     double im_n = 2 * re * im       + cIm; 

     re = re_n; 
     im = im_n; 

   } 

   return 0; 

} 


static double mandelbrot_test(int CLIENT_X, int CLIENT_Y, double ox, double oy, double lx, int max_iter) 
{ 
   double suma = 0; 

   double ly = lx * CLIENT_Y / CLIENT_X; 

   double dx = lx / CLIENT_X; 
   double dy = ly / CLIENT_Y; 

   double ax = ox - lx * 0.5 + dx * 0.5; 
   double ay = oy - ly * 0.5 + dy * 0.5; 


   for( int j=0 ; j<CLIENT_Y; j++ ) 
   { 
     double    c_im = ay + j * dy; 

    for( int i=0 ; i<CLIENT_X;  i++ ) 
    { 
       double    c_re = ax + i * dx; 

      int n = mandelbrot_n(c_re, c_im, max_iter); 

      suma+=n; 

     // SetPixelInDibInt(i ,j, palette[n]); 

    } 
   } 

   return suma; 

} 

 public static void main(String args[]) 
 { 
  
  double start_time = System.currentTimeMillis(); 

  double suma = mandelbrot_test(1000, 1000, -.5, 0., 3.0, 1000 ); 

  double finish_time = System.currentTimeMillis(); 

  System.out.println("+++ fir compilator test +++" ); 
  System.out.println("java: " + suma); 
  System.out.println("time: " + (finish_time-start_time)/1000); 


 } 


// main.c 

#include <stdio.h> 
#include <time.h> 

static int mandelbrot_n(  double cRe,  double cIm,  int max_iter ) 
{ 


  double re = 0; 
  double im = 0; 

   for(int n=0; n<=max_iter; n++) 
   { 

     if( re * re + im * im > 4.0 ) return n; 

     double re_n = re * re - im * im + cRe; 
     double im_n = 2 * re * im       + cIm; 

     re = re_n; 
     im = im_n; 

   } 

   return 0; 

} 


static double mandelbrot_test(int CLIENT_X, int CLIENT_Y, double ox, double oy, double lx, int max_iter) 
{ 
   double suma = 0; 

   double ly = lx * CLIENT_Y / CLIENT_X; 

   double dx = lx / CLIENT_X; 
   double dy = ly / CLIENT_Y; 

   double ax = ox - lx * 0.5 + dx * 0.5; 
   double ay = oy - ly * 0.5 + dy * 0.5; 


   for( int j=0 ; j<CLIENT_Y; j++ ) 
   { 
     double    c_im = ay + j * dy; 

    for( int i=0 ; i<CLIENT_X;  i++ ) 
    { 
       double    c_re = ax + i * dx; 

      int n = mandelbrot_n(c_re, c_im, max_iter); 

      suma+=n; 

     // SetPixelInDibInt(i ,j, palette[n]); 

    } 
   } 

   return suma; 

} 


int main() 
 { 
 time_t start_time = clock(); 

  double suma = mandelbrot_test(1000, 1000, -.5, 0., 3.0, 1000 
  ); 
 time_t finish_time = clock(); 

  printf("\n+++ fir compilator test +++"); 
  printf("\nc: %lf",suma); 
  printf("\ntime: %lf",  (double) (finish_time-start_time)/CLOCKS_PER_SEC); 



  return 0; 

 } 

[toc] | [prev] | [next] | [standalone]

#54250

W dniu czwartek, 11 grudnia 2014 14:49:05 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 11 grudnia 2014 14:06:34 UTC+1 użytkownik Malcolm McLean napisał:
> > systems. However normally the extended code isn't doing very much, it's just gift-
> > wrapping underlying C functions.
> 
> thats right - more clearly to say JAVA, C#, OBJ-C are just C  (and they take the best part from it), I once a go was doing some test and ported some c code int java version - what showed - the functions are -> just the same text <- 
> 
[some notice on c2 so probably not interesting in c theme can skip reading]

 as to this wrapper parts (where c is a core in language) i probably am (in my work on C2) mainly mostly working on core c itself (though its a bit hard to say what is wrapper part what is core when giving additions) But sometimes felt also a weak interestment into this wrapper part thus renaming the other part D2
9so form two yerars or so i name this projects C2 & D2 - core c improved and core c improved + some newe wrapper parts made)

PS
one important revolution in c core (C2) i was start thinking is some thing i call "distinguished space rule" 
right now c do not distinguishes spaces
and this makes ++++ same as + + + and ++ + and + ++ 
changing this would make an avaliable probably very pleasant 'syntax explosion' when you could code much more syntax in short expression - not worked to much on it yet but i find it probably and potentially very important novelty
[end of c2 stub]

[toc] | [prev] | [next] | [standalone]

#54459

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Thursday, December 11, 2014 12:17:38 AM UTC, Lynn McGuire wrote:
>> "Is C Still Relevant in the 21st Century?"
>>     http://news.dice.com/2014/12/08/c-still-relevant-21st-century/
>> "Many programming languages have come and gone since
>> Dennis Ritchie devised C in 1972, and yet C has not only
>> survived three major revisions, but continues to thrive. 
>> Large chunks of Windows were written in C, along with most of Linux."
>> 
> Virtually every job advert mentions a language, and it's rarely C,
> except for embedded programming. Apple has developed Objective C
> and Microsoft C sharp. Other companies use C++ systems. However
> normally the extended code isn't doing very much, it's just gift-
> wrapping underlying C functions. 

Object oriented languages (or extensions to C) don't interest me
as much as functional languages with type systems, designed to
exploit the Curry-Howard isomorphism. See, e.g., the Conclusions
section of http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf
(and note that it was written in 2000).
   Nothing I've ever programmed comes anywhere close to utilizing
these kinds of techniques. But I can't help wondering if I'm like
a Pony Express rider coming across his first railroad.
If stuff like that is what the 21st century is about, then
procedural languages like C probably won't be very relevant anymore.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#54461

On 13/12/2014 10:22, JohnF wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

>> Virtually every job advert mentions a language, and it's rarely C,
>> except for embedded programming. Apple has developed Objective C
>> and Microsoft C sharp. Other companies use C++ systems. However
>> normally the extended code isn't doing very much, it's just gift-
>> wrapping underlying C functions.
>
> Object oriented languages (or extensions to C) don't interest me
> as much as functional languages with type systems, designed to
> exploit the Curry-Howard isomorphism. See, e.g., the Conclusions
> section of http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf
> (and note that it was written in 2000).

>     Nothing I've ever programmed comes anywhere close to utilizing
> these kinds of techniques. But I can't help wondering if I'm like
> a Pony Express rider coming across his first railroad.
> If stuff like that is what the 21st century is about, then
> procedural languages like C probably won't be very relevant anymore.

They'll be relevant for a while longer since fewer can understand those 
more complicated languages (that paper was complete gobbledygook to me, 
and I can't be the only one. But also I'm against the kind of elitism 
that wants only mathematicians to be allowed to program.).

In terms of encouraging people to take up coding (especially children), 
procedural methods are simple and intuitive. But probably not in the 
form of C with its too many technical details to worry about and its 
many limitations.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#54464

BartC <bc@freeuk.com> writes:

> On 13/12/2014 10:22, JohnF wrote:
<snip>
>> ... See, e.g., the Conclusions
>> section of http://homepages.inf.ed.ac.uk/wadler/papers/frege/frege.pdf
>> (and note that it was written in 2000).
>
>>     Nothing I've ever programmed comes anywhere close to utilizing
>> these kinds of techniques. But I can't help wondering if I'm like
>> a Pony Express rider coming across his first railroad.
>> If stuff like that is what the 21st century is about, then
>> procedural languages like C probably won't be very relevant anymore.
>
> They'll be relevant for a while longer since fewer can understand
> those more complicated languages (that paper was complete gobbledygook
> to me, and I can't be the only one. But also I'm against the kind of
> elitism that wants only mathematicians to be allowed to program.).

How do you feel about the kind that wants only some programmers to be
allowed to use mathematics?

I'm being rhetorical of course.  I am sure you are fair about it, but
here is a big streak of anti-intellectualism in some programming circles
that tries to deny that mathematical thinking is central to programming.
(And this does not mean there isn't a big streak of elitism in some
programming circles that claims you have no place writing a while loop
if you don't know what a Y combinator is, but the nature of the business
is such that the latter seems to me to be smaller and less influential
than the former.)

> In terms of encouraging people to take up coding (especially
> children), procedural methods are simple and intuitive.

It may be a good way in (though I would like to see alternatives tried)
but it's clear from experience that this form of intuition very quickly
stops being enough.  Bugs abound in even the simplest code and many
people have no handle at all on how to write anything but the simplest
correct parallel or concurrent programs.

I say "this form of intuition" because I think there are other modes of
thought that might be exploited to make programming in other styles seem
natural.  For example, decoupling an algorithm from an exact sequence
of actions can make some programs very simple:

  sort one = one
  sort list = merge (sort odd-members-of list) (sort even-members-of list)
  where merge a,... b,... = if a < b then a, merge ... b,...
                            otherwise     b, merge a,... ...

(using an invented notation that leaves the details out).

Much fun can be had getting a class to do a parallel sort of a pack of
cards using this method.  To be honest, it usually ends up in chaos (use
just one suit and you have a better chance of success) because people
lose track of who gave them what piles of cards and who should be given
the results, but the effect is often sound -- it becomes clear that it
would work, with enough practise.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#54466

On Saturday, December 13, 2014 2:04:28 PM UTC, Ben Bacarisse wrote:
>
> I'm being rhetorical of course.  I am sure you are fair about it, but
> here is a big streak of anti-intellectualism in some programming circles
> that tries to deny that mathematical thinking is central to programming.
> (And this does not mean there isn't a big streak of elitism in some
> programming circles that claims you have no place writing a while loop
> if you don't know what a Y combinator is, but the nature of the business
> is such that the latter seems to me to be smaller and less influential
> than the former.)
> 
It really depends what the program is doing.

Underlying routines to do drawing, collision detection, physics, or, 
if that floats your boat, database access and statistical tests, can
be quite mathematical. On the other hand, a lot of code puts
up widgets, responds to text input and mouse clicks, and calls
functions to create, retrieve, update or delete records. You can
think of that as a mathematical operation on a program's internal
state if you choose, but good luck in trying to develop a method
the really can guarantee that the system will behave as wanted, as
well as responding to ad hoc requests for new features.

[toc] | [prev] | [next] | [standalone]

#54471

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Saturday, December 13, 2014 2:04:28 PM UTC, Ben Bacarisse wrote:
>>
>> I'm being rhetorical of course.  I am sure you are fair about it, but
>> here is a big streak of anti-intellectualism in some programming circles
>> that tries to deny that mathematical thinking is central to programming.
>> (And this does not mean there isn't a big streak of elitism in some
>> programming circles that claims you have no place writing a while loop
>> if you don't know what a Y combinator is, but the nature of the business
>> is such that the latter seems to me to be smaller and less influential
>> than the former.)
>> 
> It really depends what the program is doing.
>
> Underlying routines to do drawing, collision detection, physics, or, 
> if that floats your boat, database access and statistical tests, can
> be quite mathematical.

That's not what I'm talking about.

> On the other hand, a lot of code puts
> up widgets, responds to text input and mouse clicks, and calls
> functions to create, retrieve, update or delete records. You can
> think of that as a mathematical operation on a program's internal
> state if you choose, but good luck in trying to develop a method
> the really can guarantee that the system will behave as wanted, as
> well as responding to ad hoc requests for new features.

My claim that mathematical thinking is central to programming does not
rest on people programming in obviously mathematical domain, and it is
not based in the (false) idea that mathematical thinking is rigid and
formal.  Almost no mathematicians do formal proofs, and the relatively
rigorous proofs one sees in papers are an artefact of the review
process.  Most theorems are proved first with sketches and diagrams and
in outline.  Even the assumptions that a proof relies on -- so often
stated up front -- are often not known until the end.  Part of the
informal reasoning process separates out what can be concluded and what
is needed to conclude it.  This part of the process is often as valuable
as the conclusion itself (it certainly is when thinking about programs).

Every function you write is a theorem, even if a very informal one.
Every loop you write is two little theorems (does it establish some
desired state of affairs, and does it terminate?).  Verifying them,
informally, can take just a few seconds, but thinking in this way is
actually useful day-to-day.

I don't want to over-state this, because it is almost trivial, but so
little mathematical thought seems to be applied to programs that I am
sure that even a little more would go a long way.

And of course this has an impact on programming languages and styles.
It's harder to reason about programs in C, or badly structures programs
in any language, than it is to reason about well-written Haskell
programs (to take an extreme example).

I do take your point (thought not exatky as you put it) that there is
much tedious boiler-plate code that needs almost no thought at all.
However, that's not really the part of the task we call programming that
matters is it?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#54487

On Saturday, December 13, 2014 8:52:35 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> I don't want to over-state this, because it is almost trivial, but so
> little mathematical thought seems to be applied to programs that I am
> sure that even a little more would go a long way.
> 
> And of course this has an impact on programming languages and styles.
> It's harder to reason about programs in C, or badly structures programs
> in any language, than it is to reason about well-written Haskell
> programs (to take an extreme example).
> 
> I do take your point (thought not exatky as you put it) that there is
> much tedious boiler-plate code that needs almost no thought at all.
> However, that's not really the part of the task we call programming that
> matters is it?
>
The irony is that the bugs are in the "boiler plate" or as I prefer to
call it "glue code".
Underlying mathematical functions are often hard to write. But they're
easy to define in terms of bits in / bits out. Sometimes you get
inherent problems with degeneracies. Mostly, however, they are written,
tested, and work.
Glue code manages lots of relationships.The basic problem is that
you provide several views onto the data, the user expects to be
able to manipulate the data in those views, and for all the views
to remain consistent, even if the data is put in intermediate 
illegal states whilst editing. A simple example is a colour,
which the user wants to manipulate in either rgb or hsv space.
However hue goes degenerate when the colour gets close to black 
or white. My own code keeps the underlying representation in r g b,
and a separate hue and "hue locked" flag. However that's asking for
trouble, "hue locked" is bound to get inconsistent if anyone else
tired to modify the colour chooser.

[toc] | [prev] | [next] | [standalone]

#54489

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Saturday, December 13, 2014 8:52:35 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> I don't want to over-state this, because it is almost trivial, but so
>> little mathematical thought seems to be applied to programs that I am
>> sure that even a little more would go a long way.
>> 
>> And of course this has an impact on programming languages and styles.
>> It's harder to reason about programs in C, or badly structures programs
>> in any language, than it is to reason about well-written Haskell
>> programs (to take an extreme example).
>> 
>> I do take your point (thought not exatky as you put it) that there is
>> much tedious boiler-plate code that needs almost no thought at all.
>> However, that's not really the part of the task we call programming that
>> matters is it?
>>
> The irony is that the bugs are in the "boiler plate" or as I prefer to
> call it "glue code".

OK.  Then more mathematical though is needed even when writing the glue
code.  Maybe you are right and there is no place where it can be
disregarded, but in my experience there are always dull bits where I can
"switch off".  However, if I've introduced bug by doing so, my solution
would be to apply the same reasoning to these parts as I do to the rest.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#54495

On 13/12/2014 20:52, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

>> On the other hand, a lot of code puts
>> up widgets, responds to text input and mouse clicks, and calls
>> functions to create, retrieve, update or delete records. You can
>> think of that as a mathematical operation on a program's internal
>> state if you choose, but good luck in trying to develop a method
>> the really can guarantee that the system will behave as wanted, as
>> well as responding to ad hoc requests for new features.

> I do take your point (thought not exatky as you put it) that there is
> much tedious boiler-plate code that needs almost no thought at all.
> However, that's not really the part of the task we call programming that
> matters is it?

It forms a big chunk of it though. Think about writing a word processor, 
where most of it is concerned with user interfaces, displays, file 
formats and implementing 1001 different commands.

It's more about routine engineering rather than neat little mathematical 
functions.

I was involved in computer graphics applications, at a time also when it 
was necessary to program almost /everything/, as the OS did nothing 
except provide file services. In my case that included implementing 
languages too, and using a lot of ingenuity for making everything work 
within limited memory and on slow machines.

Maybe this kind of thing can all be considered tedious, routine coding 
that no-one should be involved in now and that you don't think is really 
'programming'. But I think there's a huge requirement for it still, 
perhaps in different areas (web programming for example, which /I/ think 
looks tedious and boring! And then there is apps development for 
tablets...). It could be however that this is where the skills shortage 
might be.

I also think that dynamic languages (in the informal style of Python, 
Ruby, Lua or even Javascript) are going to be more accessible than ones 
like Haskell or Ocaml, even though I quite admire those. Anything 
however is preferable to Lisp (IMO), no matter how powerful it's 
supposed to be.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#54512

BartC <bc@freeuk.com> writes:

> On 13/12/2014 20:52, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>>> On the other hand, a lot of code puts
>>> up widgets, responds to text input and mouse clicks, and calls
>>> functions to create, retrieve, update or delete records. You can
>>> think of that as a mathematical operation on a program's internal
>>> state if you choose, but good luck in trying to develop a method
>>> the really can guarantee that the system will behave as wanted, as
>>> well as responding to ad hoc requests for new features.
>
>> I do take your point (thought not exatky as you put it) that there is
>> much tedious boiler-plate code that needs almost no thought at all.
>> However, that's not really the part of the task we call programming that
>> matters is it?
>
> It forms a big chunk of it though. Think about writing a word
> processor, where most of it is concerned with user interfaces,
> displays, file formats and implementing 1001 different commands.
>
> It's more about routine engineering rather than neat little
> mathematical functions.

I think you've fallen for Malcolm McLean's interpretation of what I
mean.  I am talking about applying mathematical thinking to almost every
function -- even the ones that don't do anything "mathematical".  I put
that in quotes because it is my contention that programming *is*
mathematical, even when it doesn't look like it.  A function that moves
the editor's internal position to the end of the current line is a piece
of mathematics that can (and should) be reasoned about -- even if only
for a few seconds.

I don't think my point hinges on the proportion of code that is genuine
boiler-plate.  Boiler pate is code that needs almost no thought at all,
and if you are fortunate enough that 99% of some program is like that,
all it means is that yo are writing, in effect, a small program.  What
matters is to reason about those parts that need it, and that is almost
all code that not entirely routine.

I suspect this is a less contentious idea than it first seems.  I bet
that even people who seem dead against the mathematisation of
programming do this sort of reasoning a lot of the time.

> I was involved in computer graphics applications, at a time also when
> it was necessary to program almost /everything/, as the OS did nothing
> except provide file services. In my case that included implementing
> languages too, and using a lot of ingenuity for making everything work
> within limited memory and on slow machines.
>
> Maybe this kind of thing can all be considered tedious, routine coding
> that no-one should be involved in now and that you don't think is
> really 'programming'. But I think there's a huge requirement for it
> still, perhaps in different areas (web programming for example, which
> /I/ think looks tedious and boring! And then there is apps development
> for tablets...). It could be however that this is where the skills
> shortage might be.

A lot of this is "mathematical" in the sense that I mean.  The large
number of broken web sites and buggy apps suggests to me that something
is wrong in that area too.

> I also think that dynamic languages (in the informal style of Python,
> Ruby, Lua or even Javascript) are going to be more accessible than
> ones like Haskell or Ocaml, even though I quite admire those. Anything
> however is preferable to Lisp (IMO), no matter how powerful it's
> supposed to be.

That's another argument.  I think I agree (about the accessibility) but
I am not sure that that's a good thing.  Dynamic typing (which seems to
be what you mean by dynamic) does not stop you having type errors -- too
often it just means that they happen when I'm running the code rather
than when the compiler is looking at it.  I find a strong type system to
be very helpful, but it does take more time to learn.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#54524

On 14/12/2014 22:43, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> It forms a big chunk of it though. Think about writing a word
>> processor, where most of it is concerned with user interfaces,
>> displays, file formats and implementing 1001 different commands.
>>
>> It's more about routine engineering rather than neat little
>> mathematical functions.
>
> I think you've fallen for Malcolm McLean's interpretation of what I
> mean.

No, I tried hard not to! I understand that working with mathemetical 
content is little to do with using a mathematical style of programming.

> I am talking about applying mathematical thinking to almost every
> function -- even the ones that don't do anything "mathematical".  I put
> that in quotes because it is my contention that programming *is*
> mathematical, even when it doesn't look like it.  A function that moves
> the editor's internal position to the end of the current line is a piece
> of mathematics that can (and should) be reasoned about -- even if only
> for a few seconds.

Maybe. Fortunately such simple tasks can be done with pretty much any 
language, with any mathematical reasoning done in the programmer's head.

> I don't think my point hinges on the proportion of code that is genuine
> boiler-plate.  Boiler pate is code that needs almost no thought at all,
> and if you are fortunate enough that 99% of some program is like that,
> all it means is that yo are writing, in effect, a small program.

With a largish application, there's a bit more to it than even the 
actual coding. The overall design for example. Working out exactly how 
to do it. Choosing the languages, perhaps even having to design one or 
two as part of the application (so that users can extend the application 
themselves). In fact like any kind of project, whether programming 
related or not.

Tell someone who's been doing any kind of job for a while that they 
should have been been using a mathematically-minded approach all along, 
they might be sceptical too!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#54526

BartC <bc@freeuk.com> writes:

> On 14/12/2014 22:43, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> It forms a big chunk of it though. Think about writing a word
>>> processor, where most of it is concerned with user interfaces,
>>> displays, file formats and implementing 1001 different commands.
>>>
>>> It's more about routine engineering rather than neat little
>>> mathematical functions.
>>
>> I think you've fallen for Malcolm McLean's interpretation of what I
>> mean.
>
> No, I tried hard not to! I understand that working with mathemetical
> content is little to do with using a mathematical style of
> programming.

OK.  Your reference to "neat little mathematical functions" made me
think otherwise.

>> I am talking about applying mathematical thinking to almost every
>> function -- even the ones that don't do anything "mathematical".  I put
>> that in quotes because it is my contention that programming *is*
>> mathematical, even when it doesn't look like it.  A function that moves
>> the editor's internal position to the end of the current line is a piece
>> of mathematics that can (and should) be reasoned about -- even if only
>> for a few seconds.
>
> Maybe. Fortunately such simple tasks can be done with pretty much any
> language, with any mathematical reasoning done in the programmer's
> head.

Yes, where else would it be done?  I suspect there been some crossing of
wires here...

>> I don't think my point hinges on the proportion of code that is genuine
>> boiler-plate.  Boiler pate is code that needs almost no thought at all,
>> and if you are fortunate enough that 99% of some program is like that,
>> all it means is that yo are writing, in effect, a small program.
>
> With a largish application, there's a bit more to it than even the
> actual coding. The overall design for example. Working out exactly how
> to do it. Choosing the languages, perhaps even having to design one or
> two as part of the application (so that users can extend the
> application themselves). In fact like any kind of project, whether
> programming related or not.

Sure.  I don't want to get tied up with what exactly is programming or
coding or design etc.  What people-like-us-do (whatever you call it) is
a complex, multifaceted activity.  My point is that one part of it --
the details of how an abstract language of loops and variable and
functions and so on is used to achieve some effect or other -- is a
mathematical activity, and therefore mathematical methods can be applied
to it (if only informally most of the time).  And I go a bit further and
say that they should be applied more often than I think they are
(thought I admit to being rather out of touch these days so it all may
be much better than I remember it being).

> Tell someone who's been doing any kind of job for a while that they
> should have been been using a mathematically-minded approach all
> along, they might be sceptical too!

I'm sure.  Being sceptical is a good starting position to adopt.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#54544

On Sunday, December 14, 2014 10:43:49 PM UTC, Ben Bacarisse wrote:
>
> I think you've fallen for Malcolm McLean's interpretation of what I
> mean.  I am talking about applying mathematical thinking to almost every
> function -- even the ones that don't do anything "mathematical".  I put
> that in quotes because it is my contention that programming *is*
> mathematical, even when it doesn't look like it.  A function that moves
> the editor's internal position to the end of the current line is a piece
> of mathematics that can (and should) be reasoned about -- even if only
> for a few seconds.
> 
There are two sorts of mathematical difficulty.

The first is of the form

medial axis = union set of origin of maximal inscribed circles of
input shape.
input shape = union of set of points on lines which cross set of cubics an even number of times.
cubics : Bezier or Catmull Rom equation curve. 

How are you going to tackle that?

The other sort is

calculate (1234 + 4567890^(0.1^0.2) - 123/6 * (3*5 +6/2 + 0.001))

This sort  of mathematical difficulty a computer can zip through, if 
set up correctly, but a human is quickly going to get overwhelmed, even 
if armed with a calculator.
 
If the system effectively puts the burden of chugging through sort
2 mathematical difficulty on the human programmer, it's useless.
However if it helps the programmer formalise type 1 mathematical
difficulty and express it in computer terms, it's potentially
very  useful.

[toc] | [prev] | [next] | [standalone]

#54573

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, December 14, 2014 10:43:49 PM UTC, Ben Bacarisse wrote:
>>
>> I think you've fallen for Malcolm McLean's interpretation of what I
>> mean.  I am talking about applying mathematical thinking to almost every
>> function -- even the ones that don't do anything "mathematical".  I put
>> that in quotes because it is my contention that programming *is*
>> mathematical, even when it doesn't look like it.  A function that moves
>> the editor's internal position to the end of the current line is a piece
>> of mathematics that can (and should) be reasoned about -- even if only
>> for a few seconds.
>> 
> There are two sorts of mathematical difficulty.

Only two?  OK, if you say so...

> The first is of the form
>
> medial axis = union set of origin of maximal inscribed circles of
> input shape.
> input shape = union of set of points on lines which cross set of
> cubics an even number of times.
> cubics : Bezier or Catmull Rom equation curve. 
>
> How are you going to tackle that?
>
> The other sort is
>
> calculate (1234 + 4567890^(0.1^0.2) - 123/6 * (3*5 +6/2 + 0.001))
>
> This sort  of mathematical difficulty a computer can zip through, if 
> set up correctly, but a human is quickly going to get overwhelmed, even 
> if armed with a calculator.
>  
> If the system effectively puts the burden of chugging through sort
> 2 mathematical difficulty on the human programmer, it's useless.
> However if it helps the programmer formalise type 1 mathematical
> difficulty and express it in computer terms, it's potentially
> very  useful.

What system?  Does this have anything to do with what I am talking
about?  Should I have another go at explaining what I mean?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web