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

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

Advantages of C

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

Contents

  Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:02 +0200
    Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 16:16 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:13 +0200
      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:56 +0530
    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 08:17 -0700
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:38 +0200
    Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 16:48 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 17:58 +0200
        Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 17:27 +0100
          Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 15:19 -0400
          Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 21:49 +0100
            Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-18 22:06 +0100
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:11 +0100
                Re: Advantages of C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 01:31 +0100
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:29 +0100
                  Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 21:58 -0400
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:30 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 02:06 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:39 -0700
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:29 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:39 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:19 +0100
          Re: Advantages of C luser droog <luser.droog@gmail.com> - 2016-07-18 21:16 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:48 -0700
        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:21 +1200
          Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:43 +0000
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 18:05 +0200
        Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 21:45 +0200
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 21:16 +0100
            Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:00 +0530
              Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-19 11:00 +0100
                Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:08 +0530
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 23:32 +0200
            Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:54 -0700
              Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:54 +0100
                Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 20:02 -0700
                  Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:26 +0530
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 01:43 -0700
                      Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 10:33 +0530
                        Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 01:07 -0700
                          Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 12:53 +0530
                  Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:33 +0100
                    Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:04 -0700
                      Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:35 +0100
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-19 19:21 +0100
            Re: Advantages of C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-20 12:05 +0200
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 16:51 -0700
            Re: Advantages of C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:24 +0000
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 02:33 -0700
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:36 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:00 +0200
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:46 +0100
            Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 19:49 +0100
              Re: Advantages of C supercat@casperkitty.com - 2016-07-20 12:02 -0700
                Re: Advantages of C Keith Thompson <kst-u@mib.org> - 2016-07-20 12:32 -0700
                  Re: Advantages of C supercat@casperkitty.com - 2016-07-20 13:18 -0700
                Re: Advantages of C Gareth Owen <gwowen@gmail.com> - 2016-07-20 20:37 +0100
              Re: Advantages of C jadill33@gmail.com - 2016-07-20 13:06 -0700
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-20 23:07 +0200
                Re: Advantages of C jadill33@gmail.com - 2016-07-21 09:48 -0700
                  Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 10:14 +0200
                    Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 20:25 +1200
                      Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 02:17 -0700
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:56 +1200
                      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 11:28 +0200
                        Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-22 23:49 +1200
                    Re: Advantages of C jadill33@gmail.com - 2016-07-22 06:46 -0700
          Re: Advantages of C BartC <bc@freeuk.com> - 2016-07-18 23:13 +0100
            Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 01:45 +0100
      Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-18 19:18 +0200
        Re: Advantages of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-18 22:47 +0100
          Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 00:07 +0200
            Re: Advantages of C Melzzzzz <mel@zzzzz.com> - 2016-07-19 00:18 +0200
              Re: Advantages of C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 01:36 +0200
            Re: Advantages of C Ian Collins <ian-news@hotmail.com> - 2016-07-19 10:28 +1200
              Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:34 -0400
            Re: Advantages of C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-18 20:33 -0400
              Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 19:30 -0700
          Re: Advantages of C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 17:01 -0700
    Re: Advantages of C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:51 +0530
      Re: Advantages of C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 09:01 -0700

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

#90584

On Tuesday, July 19, 2016 at 3:29:11 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > On Tuesday, July 19, 2016 at 2:06:44 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> 
> >> > Not really.
> >> > Obviously C won't run in a web browser, but that's because of poor
> >> > design decisions by the people who built the browser, not because
> >> > of C.
> >> 
> >> Why is that obvious to you?  It seems obvious to me that it would be
> >> very simple to run C in a browser, and, as it happens, a bad idea
> >> precisely because of the design of C.
> >> 
> > It's not hard to take a C interpreter and add it to your own browser.
> > The difficulty is in making sure your users have the interpreter
> > installed in their browsers.
> 
> How is that any different from any other client-side scripting language?
> Anyway, I still don't see why it's obvious to you that C won't run in a
> web browser.  You now seem to be saying that it's not hard.
> 
Javascript will be installed on your user's browser.
So you add a javascript "Hello world" to your web page, user clicks on it, and,
with only a modicum of luck, "hello world" appears on this screen.

Now we can add a C interpreter, with a bit of effort we can probably package 
it up as a plug-in or add-on to Chrome. So user clicks. A message appears
saying "to view this webpage you need to install the C interpreter plug-in.
Click here".  The a licence screen pops up holding Google harmless for any
malfunctions. Then there's a login screen that demands his Google 
password. By this time user has got bored, so he navigates away.

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

#90595

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

> On Tuesday, July 19, 2016 at 3:29:11 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > On Tuesday, July 19, 2016 at 2:06:44 AM UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >> 
>> >> > Not really.
>> >> > Obviously C won't run in a web browser, but that's because of poor
>> >> > design decisions by the people who built the browser, not because
>> >> > of C.
>> >> 
>> >> Why is that obvious to you?  It seems obvious to me that it would be
>> >> very simple to run C in a browser, and, as it happens, a bad idea
>> >> precisely because of the design of C.
>> >> 
>> > It's not hard to take a C interpreter and add it to your own browser.
>> > The difficulty is in making sure your users have the interpreter
>> > installed in their browsers.
>> 
>> How is that any different from any other client-side scripting language?
>> Anyway, I still don't see why it's obvious to you that C won't run in a
>> web browser.  You now seem to be saying that it's not hard.
>> 
> Javascript will be installed on your user's browser.

No it won't.  It is installed in some and not others.

> So you add a javascript "Hello world" to your web page, user clicks on it, and,
> with only a modicum of luck, "hello world" appears on this screen.
>
> Now we can add a C interpreter, with a bit of effort we can probably package 
> it up as a plug-in or add-on to Chrome. So user clicks. A message appears
> saying "to view this webpage you need to install the C interpreter plug-in.
> Click here".

Plugins have nothing to do with it (except, it seems, as another way of
proving yourself wrong).  You said "obviously C won't run in a web
browser".  This is simply false.  C can and will if the browser is
designed with that in mind.

<snip>
-- 
Ben.

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

#90567

On Monday, July 18, 2016 at 11:27:36 AM UTC-5, Richard Heathfield wrote:
> On 18/07/16 16:58, jacobnavia wrote:
> <snip>
> >
> > Obviously too, a group that discusses C is full of people that tell
> > people here that C is doomed, nobody should really develop anything
> > important in C, since the C++ language fills all needs that you could
> > ever have.
> 
> I think you overstate the case. There are at least two (and quite 
> possibly more than two) people in this group for whom C is their 
> development language of choice: you, and me.
> 
> Any more?
> 

I like C for "hardcore" programs. When I want to write something
with the sense that I have total power and no prescribed 
restrictions. Of course, "With great power comes great 
responsibility." C enacts this toll by requiring you to build
(or otherwise acquire (like using a library)) your abstractions
from the ground-level up.

But I also love PostScript. And by implementing postscript (and
other languages) in C, I can extend the sense of power into
Postscript- (or other-) -language programs. Lisp is the 
language to learn in order to unlock all of the literature on
language implementation that was written in a Lisp context.
My PostScript interpreter is essentially a Lisp interpreter
for PostScript. This is even more true for Olmec, my new
(incomplete) APL language (it implements defined functions
using Weisenbaum environments -- which I learned about from 
"Anatomy of Lisp").

And as an aside, I have some sympathy with the religiously-
motivated participants here. I consider the programming work
I do (which for these past 10 years has been entirely voluntary
and "amateur") to be part of my contribution to the Great Work.
I see a similarity of form and purpose between the Euclidean
system of axioms and theorems and the Pseudo-Dionysian Celestial
Hierarchy. Thus I take a very great comfort in the work performed
by the Standards Committees in that, for practical purposes,
I can build my software upon the C "firmament" and not worry
too much about the shifting of sands.

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

#90541

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
>> Your library
>> is unlikely to be become standard
>
> Yes. I spent thousands of dollars in a trip to the committee session
> in Portland where I was told that after the STL what I was trying to
> do was ridiculous.

I am very sorry to hear that.  I think the only practical way would be
for your library to become the de facto standard by being widely used.

<snip>
> Obviously too, a group that discusses C is full of people that tell
> people here that C is doomed, nobody should really develop anything
> important in C, since the C++ language fills all needs that you could
> ever have.

Who has said C is doomed?  There's no sign that that is true, so I would
have though I'd have said something had I seen anyone say such a thing.

As for C++, you don't help C's cause by refusing to accept what C++ is
good at.

-- 
Ben.

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

#90550

On Monday, July 18, 2016 at 10:47:52 PM UTC+1, Ben Bacarisse wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> 
> > Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
> >> Your library
> >> is unlikely to be become standard
> >
> > Yes. I spent thousands of dollars in a trip to the committee session
> > in Portland where I was told that after the STL what I was trying to
> > do was ridiculous.
> 
> I am very sorry to hear that.  I think the only practical way would be
> for your library to become the de facto standard by being widely used.
> 
One possibility is a sort of grassroots movement as hobby programmers,
then academics, then one man bands, and finally software companies
adopt the library, getting it through word of mouth. But that's hard
to achieve. There's a very nice Fourier transform library I use a lot,
but I can't recall converting anyone to it. I don't have a strong
motivation to proselytise for it. I use it when I need an FFT and
I'm not in a context where one is provided, which tends to be when
the code is essentially private to me.

The most likely way is through attracting a patron. One person with
a considerable degree of influence uses the library, and effectively
forces programmers who depend on him to also use it, either because
he employs them or because he is providing a programming environment
that they need. The standardisation committee is the most powerful 
patron of all, but too powerful - they know that that is their role,
and so any idea has to go through layers of bureaucracy and 
consideration before being accepted, and something like the C 
collections library just can't survive that process, until it
has a substantial user base.

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

#90546

On 07/19/16 03:58 AM, jacobnavia wrote:
> Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
>> Your library
>> is unlikely to be become standard
>
> Yes. I spent thousands of dollars in a trip to the committee session in
> Portland where I was told that after the STL what I was trying to do was
> ridiculous.

That comment was unjustified.  What you are trying to do is laudable, if 
a little quixotic.

I guess the opinion derives from the common view that you should pick 
the appropriate language for a task.  Which leads to: if you want 
generic containers and algorithms, pick a language with them built in.

> A committee member told me that in his shop, all code will be compiled
> as C++ anyway so what I proposed was besides the point.

You will never get past that.  It's analogous to trying to persuade 
someone to use 10 piece toolkit when they have access to a 50 piece kit.

> Not all people were like that of course, and I gathered merit for the
> best documentation proposal from one of the committee members. They all
> were impressed by the package, nobody thought that what I was trying to
> do was possible in C.
>
> Obviously in this group, the same people that told me to go to Portland
> told me I have merited my defeat.
>
> Granted, my proposal wasn't accepted and I do not have the money nor the
> will of pursuing that way.

If a frontal attack failed, you'll have to use the back door: get your 
library into a widely used distribution.  This won't be easy, but it is 
the only way to get something so large into a standard.

-- 
Ian

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

#90864

Ian Collins <ian-news@hotmail.com> wrote:

> On 07/19/16 03:58 AM, jacobnavia wrote:

> > A committee member told me that in his shop, all code will be compiled
> > as C++ anyway so what I proposed was besides the point.
> 
> You will never get past that.  It's analogous to trying to persuade 
> someone to use 10 piece toolkit when they have access to a 50 piece kit.

Or to convince someone who _wants_ to use a 10-piece toolkit (for
example because he's on the road and doesn't want to lug a whole chest
along) to use a different 50-piece kit than the other, already
standardised 50-piece kit he has at home.

> > Granted, my proposal wasn't accepted and I do not have the money nor the
> > will of pursuing that way.
> 
> If a frontal attack failed, you'll have to use the back door: get your 
> library into a widely used distribution.  This won't be easy, but it is 
> the only way to get something so large into a standard.

Not going to happen either. The problem jacob is facing is that the
people who still regularly use C tend to do so because it's sleek and
compact, and when they want something large and feature-full they might
as well use C++ instead. His library, thus, fills a much-needed gap.

Richard

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

#90513

Le 18/07/2016 à 17:48, Ben Bacarisse a écrit :
> You should probably pick up a book about Lisp before you start saying
> that the above has anything but the most superficial similarity to a
> Lisp form.

(Verb arguments-list)

"arguments-list" --> (Verb arguments) | scalar

add(a,divide(add(b,4),5)))

The only difference is that in C notation the parentheses is AFTER the 
verb like this:

Verb ( arguments-list)

That is exactly "lisp" notation but with parentheses moved.

And this is not superficial. Not at all.

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

#90534

jacobnavia <jacob@jacob.remcomp.fr> writes:

> That is exactly "lisp" notation but with parentheses moved.

Do yourself a favor, learn to program in lisp before trying to make a point
against it. (And that's true for all programming languages, and that's true
outside the CS world: you can't make a convincing point against something
if you don't understand it well enough that you are able to make convincing
points in favor; most choices are the result of trade-off which are driven
by the relative importance given to the various aspects).

The interest of lisp has nothing to do with the notation -- the sexp one
was first destinated to be an temporary one, but it fills its purpose well
enough that it has never been displaced although there were several
variants which used infix and a position of parenthesis that you'd find
more familiar.

Yours,

-- 
Jean-Marc

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

#90535

On 18/07/2016 20:45, Jean-Marc Bourguet wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>> That is exactly "lisp" notation but with parentheses moved.
>
> Do yourself a favor, learn to program in lisp before trying to make a point
> against it. (And that's true for all programming languages, and that's true
> outside the CS world: you can't make a convincing point against something
> if you don't understand it well enough that you are able to make convincing
> points in favor; most choices are the result of trade-off which are driven
> by the relative importance given to the various aspects).
>
> The interest of lisp has nothing to do with the notation -- the sexp one
> was first destinated to be an temporary one, but it fills its purpose well
> enough that it has never been displaced although there were several
> variants which used infix and a position of parenthesis that you'd find
> more familiar.

The syntax of Lisp is the first thing that hits you. And what probably 
puts most people off. So why persist with it?

You're right in that s-expressions themselves aren't a big deal. And 
they could be used in any well-structured language including C:

  (function fib static ((int n)) int ... ; whatever
    (if (< n 2)
      (   (return n)
      )
      (   (return (+ (fib (- n 1)) (fib (- n 2))))
      )
    )
  )

But, for some mysterious reason, the C designers reluctantly made a 
different choice!

Yes, Lisp has some interesting possibilities if you're interested in 
esoteric aspects of programming. But most real-life programming is routine.

-- 
Bartc

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

#90568

On 07/19/2016 01:46 AM, BartC wrote:
> The syntax of Lisp is the first thing that hits you. And what probably
> puts most people off. So why persist with it?

  Might there not be a reason for a thing to exist?  Perhaps it has been
  found be very useful?
  
> You're right in that s-expressions themselves aren't a big deal. And
> they could be used in any well-structured language including C:
> 
>  (function fib static ((int n)) int ... ; whatever
>    (if (< n 2)
>      (   (return n)
>      )
>      (   (return (+ (fib (- n 1)) (fib (- n 2))))
>      )
>    )
>  )

  What horrible code!  It is as if you wrote this awful mess in C:

int fib(int n)
{if (n < 2)
{return n
;}
else
{return fib(n - 1) + fib(n - 2)
;}}

  For the record, this is how the commonly seen trivial Fibonacci
  function might be written:

(defun fib (n)
  (if (> 2 n)
      n
      (+ (fib (- n 1)) (fib (- n 2)))))

  A change in syntax changes quite a lot.

> But, for some mysterious reason, the C designers reluctantly made a
> different choice!

  We have already been over this.  Lisp made one choice.  C made
  another.  Just like everything else, Lisp has merits and demerits, and
  so does C.
  
> Yes, Lisp has some interesting possibilities if you're interested in
> esoteric aspects of programming. But most real-life programming is
> routine.

  Yes, I am sure that the commercial Lisp vendors are simply pouring
  money into and making money off of toy endeavors.
  
-- 
Udyant Wig

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

#90572

On 19/07/2016 06:30, Udyant Wig wrote:
> On 07/19/2016 01:46 AM, BartC wrote:
>> The syntax of Lisp is the first thing that hits you. And what probably
>> puts most people off. So why persist with it?
>
>   Might there not be a reason for a thing to exist?  Perhaps it has been
>   found be very useful?
>
>> You're right in that s-expressions themselves aren't a big deal. And
>> they could be used in any well-structured language including C:
>>
>>  (function fib static ((int n)) int ... ; whatever
>>    (if (< n 2)
>>      (   (return n)
>>      )
>>      (   (return (+ (fib (- n 1)) (fib (- n 2))))
>>      )
>>    )
>>  )
>
>   What horrible code!  It is as if you wrote this awful mess in C:
>
> int fib(int n)
> {if (n < 2)
> {return n
> ;}
> else
> {return fib(n - 1) + fib(n - 2)
> ;}}

It *was* meant to be C as it might appear written using Lisp-like 
syntax. (The body was generated by a modified back-end of a compiler, 
the first line by hand. The compiler emulates a style where branches of 
an 'if' for example always use {,}.)

The tidiness is not relevant; it just shows programming languages can 
easily use such syntax, or even XML which is probably worse. But they 
would not be sensible choices /for a human coder/.

I haven't looked at Lisp code for a while, but looking at one sample now 
I can see it's not just the s-expressions that are the problem, with 
their lack of special symbols to break up the code; it's also the 
sprawling style due to spelling things out in words all the time:

  (declare (type fixnum max-depth min-depth))
   (loop for d of-type fixnum from min-depth by 2 upto max-depth do
        (loop with iterations of-type fixnum = (ash 1 (+ max-depth
             min-depth (- d)))
           for i of-type fixnum from 1 upto iterations

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=sbcl&id=2

I think that's two nested loops there, not three. I'm reminded of some 
Italian autostrada, years ago, which was so badly marked that I couldn't 
tell if it was two lanes or three!

But this example also seems to copy the annoying C trait of mixing in 
declarations amongst the code, increasing clutter. I'm not sure the 
declarations are even necessary in the Lisp.

-- 
Bartc

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

#90636

On 07/19/2016 03:30 PM, BartC wrote:
> It *was* meant to be C as it might appear written using Lisp-like
> syntax. (The body was generated by a modified back-end of a compiler,
> the first line by hand. The compiler emulates a style where branches
> of an 'if' for example always use {,}.)

  Ah.  Mea culpa, then.
  
> The tidiness is not relevant; it just shows programming languages can
> easily use such syntax, or even XML which is probably worse. But they
> would not be sensible choices /for a human coder/.

  Perhaps this is at bottom a matter of preference once again.  (Except
  XML.)

> I haven't looked at Lisp code for a while, but looking at one sample
> now I can see it's not just the s-expressions that are the problem,
> with their lack of special symbols to break up the code; it's also the
> sprawling style due to spelling things out in words all the time:
> 
>  (declare (type fixnum max-depth min-depth))
>   (loop for d of-type fixnum from min-depth by 2 upto max-depth do
>        (loop with iterations of-type fixnum = (ash 1 (+ max-depth
>             min-depth (- d)))
>           for i of-type fixnum from 1 upto iterations
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=sbcl&id=2
>
> I think that's two nested loops there, not three.

  You think correctly.

  I visited the link and checked if the code there was as butchered as
  the piece you had quoted.  It wasn't.  The layout was better and
  easier to follow.  Please try not to wrap quoted code.

  One of the advantages of s-expressions is that they have more
  structure than simply lines and characters.  So, s-expressions can
  span multiple lines and still be just one expression.  With good
  editing environments, the programmer moves into sexps, out of them,
  forward and backward by sexps, up levels, down levels, etc.
  
> [elided]
>
> But this example also seems to copy the annoying C trait of mixing in
> declarations amongst the code, increasing clutter. I'm not sure the
> declarations are even necessary in the Lisp.

  No, the declarations are not necessary in Lisp unlike C.  They can be
  added later to help the compiler once the program is working
  correctly.

-- 
Udyant Wig

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

#90538

Le 18/07/2016 à 21:45, Jean-Marc Bourguet a écrit :
> Do yourself a favor, learn to program in lisp before trying to make a point
> against it.

Yes, I think a clarification is needed.

I am the author of the Common Lisp Plus (CL+) lisp interpreter that I 
developed between 1985 and 1993. Starting with Betz's free lisp 
interpreter I developed a full implementation of Common Lisp, complete 
with setf special forms, bignums, and a compiler that translated the 
lisp virtual machine code (byte code) into straight C.

I even managed (using Borland's overlays) to put all that into a program 
that fitted within the MSDOS 640 K limit

Yes, I still do not get the parentheses right at the end, and 
translating the lisp notation into C or viceversa is still an art that 
eludes me sometimes, see the error in that formula translation.


But I would not consider me an ignorant in those matters. I implemented 
closures, the lexical scope (Betz's interpreter was dynamically scoped), 
many special functions required by that enormous language. I should 
still have the documentation somewhere in some backup disk.

But I wrote all that in C. And after some years, C, with its clarity and 
simplicity became my language of choice. So, in 1995 I downloaded the 
first version of lcc from the net, and started another adventure, one 
that allowed me to pay the bills and develop a satisfying small system.

Please do not make assumptions about people here. You can get everything 
wrong.

And please read other people's arguments.

LISP:

'(' VERB argument-list ')'

where "arguments list" can be itself a lisp form or scalars.

C

VERB '(' argument list ')'

---------

Lisp
(+ 2 3)
C
add(2,3)

This is not a superficial similarity. It is a fact: the notations are 
equivalent: a "VERB" is applied to an argument list. All languages have 
(in different forms) the same basis.

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

#90552

On Monday, July 18, 2016 at 10:32:27 PM UTC+1, jacobnavia wrote:
> 
> I am the author of the Common Lisp Plus (CL+) lisp interpreter that I 
> developed between 1985 and 1993. Starting with Betz's free lisp 
> interpreter I developed a full implementation of Common Lisp, complete 
> with setf special forms, bignums, and a compiler that translated the 
> lisp virtual machine code (byte code) into straight C.
> 
Typical.
As I said, it's the only language which is easier to write the
interpreter for than to write the simplest non-trivial program
in. 

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

#90560

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

> On Monday, July 18, 2016 at 10:32:27 PM UTC+1, jacobnavia wrote:
>> 
>> I am the author of the Common Lisp Plus (CL+) lisp interpreter that I 
>> developed between 1985 and 1993. Starting with Betz's free lisp 
>> interpreter I developed a full implementation of Common Lisp, complete 
>> with setf special forms, bignums, and a compiler that translated the 
>> lisp virtual machine code (byte code) into straight C.
>> 
> Typical.
> As I said, it's the only language which is easier to write the
> interpreter for than to write the simplest non-trivial program
> in.

Is there any actual evidence (such as watching me write a simple
non-trivial program in Lisp) that could convince you that you are wrong?

I note you've pulled a sneaky switch -- it's now a "non-trivial program"
where before it was a "basic function in Lisp".  Can I assume that
you've decided that at least that piece of polemic is untenable?

-- 
Ben.

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

#90566

On Tuesday, July 19, 2016 at 1:55:05 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > On Monday, July 18, 2016 at 10:32:27 PM UTC+1, jacobnavia wrote:
> >> 
> >> I am the author of the Common Lisp Plus (CL+) lisp interpreter that I 
> >> developed between 1985 and 1993. Starting with Betz's free lisp 
> >> interpreter I developed a full implementation of Common Lisp, complete 
> >> with setf special forms, bignums, and a compiler that translated the 
> >> lisp virtual machine code (byte code) into straight C.
> >> 
> > Typical.
> > As I said, it's the only language which is easier to write the
> > interpreter for than to write the simplest non-trivial program
> > in.
> 
> Is there any actual evidence (such as watching me write a simple
> non-trivial program in Lisp) that could convince you that you are wrong?
> 
> I note you've pulled a sneaky switch -- it's now a "non-trivial program"
> where before it was a "basic function in Lisp".  Can I assume that
> you've decided that at least that piece of polemic is untenable?
> 

Here are two Lisp functions written by Paul Graham

Here's "not"
(defun not. (x)
  (cond (x '())
        ('t 't)))

Ok, we can just about make that one out. If x evaluates to true,
return the empty list. Else if true evaluates to true, return
true.
It's hard to think of a simpler function, however.


And here's "eval".

(defun eval. (e a)
  (cond
    ((atom e) (assoc. e a))
    ((atom (car e))
     (cond
       ((eq (car e) 'quote) (cadr e))
       ((eq (car e) 'atom)  (atom   (eval. (cadr e) a)))
       ((eq (car e) 'eq)    (eq     (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'car)   (car    (eval. (cadr e) a)))
       ((eq (car e) 'cdr)   (cdr    (eval. (cadr e) a)))
       ((eq (car e) 'cons)  (cons   (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'cond)  (evcon. (cdr e) a))
       ('t (eval. (cons (assoc. (car e) a)
                        (cdr e))
                  a))))
    ((eq (caar e) 'label)
     (eval. (cons (caddar e) (cdr e))
            (cons (list. (cadar e) (car e)) a)))
    ((eq (caar e) 'lambda)
     (eval. (caddar e)
            (append. (pair. (cadar e) (evlis. (cdr e) a))
                     a)))))

Now are you seriously telling me that you can give that to
an average person and expect any type of comprehension about
what it is doing? Considering that it is effectively the Lisp
interpreter in self-speak, it's a remarkably concise piece
of code. But it's just not something that is suitable for
human beings. It's too deeply nested, it doesn't create local
names to auto-document, the flow control is hierarchical
rather than linear making it hard to dry run. 

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

#90569

On 07/19/2016 08:32 AM, Malcolm McLean wrote:
> On Tuesday, July 19, 2016 at 1:55:05 AM UTC+1, Ben Bacarisse wrote:
>> I note you've pulled a sneaky switch -- it's now a "non-trivial
>> program" where before it was a "basic function in Lisp".  Can I
>> assume that you've decided that at least that piece of polemic is
>> untenable?
> 
> Here are two Lisp functions written by Paul Graham
> 
> Here's "not"
> (defun not. (x)
>   (cond (x '())
>         ('t 't)))
> 
> Ok, we can just about make that one out. If x evaluates to true,
> return the empty list. Else if true evaluates to true, return true.
> It's hard to think of a simpler function, however.
> 
> And here's "eval".
> 
> (defun eval. (e a)
>   (cond
>     ((atom e) (assoc. e a))
>     ((atom (car e))
>      (cond
>        ((eq (car e) 'quote) (cadr e))
>        ((eq (car e) 'atom)  (atom   (eval. (cadr e) a)))
>        ((eq (car e) 'eq)    (eq     (eval. (cadr e) a)
>                                     (eval. (caddr e) a)))
>        ((eq (car e) 'car)   (car    (eval. (cadr e) a)))
>        ((eq (car e) 'cdr)   (cdr    (eval. (cadr e) a)))
>        ((eq (car e) 'cons)  (cons   (eval. (cadr e) a)
>                                     (eval. (caddr e) a)))
>        ((eq (car e) 'cond)  (evcon. (cdr e) a))
>        ('t (eval. (cons (assoc. (car e) a)
>                         (cdr e))
>                   a))))
>     ((eq (caar e) 'label)
>      (eval. (cons (caddar e) (cdr e))
>             (cons (list. (cadar e) (car e)) a)))
>     ((eq (caar e) 'lambda)
>      (eval. (caddar e)
>             (append. (pair. (cadar e) (evlis. (cdr e) a))
>                      a)))))
> 
> Now are you seriously telling me that you can give that to an average
> person and expect any type of comprehension about what it is doing?

  Would you also give a random part of a core C library to an "average
  person" and expect any type of comprehension about what it is doing?

  Why would you give it to an "average person" in the first place?

> Considering that it is effectively the Lisp interpreter in self-speak,
> it's a remarkably concise piece of code. But it's just not something
> that is suitable for human beings.

  Is it then meant for superhumans?  I hope you do not mean it is meant
  for subhumans.

> It's too deeply nested, it doesn't create local names to
> auto-document, the flow control is hierarchical rather than linear
> making it hard to dry run.

  It is how _one_ Lisp programmer wrote code meant for instruction.  His
  point, as I understand it, was to only use the primitives of a Lisp to
  build up the core of a small Lisp system; it was pedagogical in
  nature.  Just as K&R did not incorporate error handling in their
  seminal book so that they could focus on teaching the concepts.  But
  they surely knew the value of error handling in real code.
  
-- 
Udyant Wig

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

#90571

On Tuesday, July 19, 2016 at 6:57:08 AM UTC+1, Udyant Wig wrote:
> On 07/19/2016 08:32 AM, Malcolm McLean wrote:

> > Considering that it is effectively the Lisp interpreter in self-speak,
> > it's a remarkably concise piece of code. But it's just not something
> > that is suitable for human beings.
> 
>   Is it then meant for superhumans?  I hope you do not mean it is meant
>   for subhumans.
> 
It's easy to write the interpreter for Lisp.
In the 1950s, when programs were entered on punched cards into computers
with tiny memories, and there were few professional programmers,
that was a very important, reasonable design goal.
But the language gives the interpreter, not the human programmer, the
ideal environment to work in. 

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

#90637

On 07/19/2016 02:13 PM, Malcolm McLean wrote:
> It's easy to write the interpreter for Lisp.

  You have repeated this.

> In the 1950s, when programs were entered on punched cards into
> computers with tiny memories, and there were few professional
> programmers, that was a very important, reasonable design goal.

  Do you have a source for this claim?

  There already was a Lisp compiler in 1962.
  
> But the language gives the interpreter, not the human programmer, the
> ideal environment to work in.

  You made no mentions about ideals earlier.  Why bring it up now?

  You repeat that it is not an (ideal) environment for the human
  programmer.  But you do not establish this in any way.

-- 
Udyant Wig

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

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

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

csiph-web