unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Marko Rauhamaa <marko@pacujo.net>
To: Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>
Cc: Carlos Pita <carlosjosepita@gmail.com>,
	David Thompson <dthompson2@worcester.edu>,
	"guile-user@gnu.org" <guile-user@gnu.org>
Subject: Re: A couple of questions about goops method parameters
Date: Sun, 07 Sep 2014 16:58:51 +0300	[thread overview]
Message-ID: <87ppf7edlw.fsf@elektro.pacujo.net> (raw)
In-Reply-To: <87ppf7eggu.fsf@taylan.uni.cx> (Taylan Ulrich Bayirli's message of "Sun, 07 Sep 2014 14:57:05 +0200")

Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> [...] However, since Scheme can do everything C can without static
>> type information, the principal justification for its existence is
>> performance. [...]
>
> I think that's a wrong way to look at it. Scheme has a type system
> too; a dynamic/run-time one.

You are changing the topic a bit.

> The "default" situation would be to have no type system at all, where
> you can add 5 to "foo" and use the result in a floating-point
> operation where it counts as 1.8142093e-316.

It's perfectly fine to avoid errors by generalizing semantics so I
wouldn't mind if you did what you propose. However, the dynamic type
system is necessary for the simple fact that you will need to define
runtime semantics.

As a less convoluted example you could take classic λ calculus or the
abstract set theory, whose entities could really be considered typeless
(no integers, no strings, no files etc).

> That's confusing if you do it by accident, so we use type systems to
> prevent us from it, which is the principal justification for their
> existence.

No, the primary objective is not to prevent errors but to have
well-defined semantics. Scheme, Python, C or Java would function
perfectly well without any type error checking, static or dynamic. The
results could be undefined or a burning computer, that doesn't matter.
What matters is that you know what a well-defined program is supposed to
do.

> The choice between a static and a dynamic one is then influenced by
> their performance characteristics, the time at which they can tell you
> your mistake (compile time vs. run time), how readable they make the
> code (some say manifest types make code clearer), etc.

Yes, early static error checking is a happy side effect of a static type
system.

However, in my extensive practical experience, a static type system,

 * makes writing a program a huge chore,

 * invites lazy shortcuts and accidental mistakes,

 * often makes the logic of the program very hard to follow.

Moreover, coming up with the correct type annotation can become a
frustrating metaphysical exercise. For example, C++ calls for template
acrobatics and C's const keyword is impossible to get right (and nobody
even tries anymore).

I'm seriously saying Python or Scheme programs make it much easier to
write and maintain very complex software systems than C, C++ or Java
even though they don't catch early type or call signature violations.
IOW, you sacrifice a little bit of quality and gain a lot.

The only remaining consideration is performance. There still remains an
ever dwindling niche where dynamic programming languages just aren't
performant enough.

> Sorry for being pedantic. :)

No harm done.


Marko



  reply	other threads:[~2014-09-07 13:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03  2:05 A couple of questions about goops method parameters Carlos Pita
2014-09-03 15:49 ` Carlos Pita
2014-09-03 16:47   ` Marko Rauhamaa
2014-09-03 18:05     ` Carlos Pita
2014-09-03 16:20 ` Panicz Maciej Godek
2014-09-05  8:32 ` Nala Ginrut
2014-09-05 12:47   ` Carlos Pita
2014-09-05 19:03   ` Panicz Maciej Godek
2014-09-05 19:12     ` David Thompson
2014-09-05 19:35       ` Panicz Maciej Godek
2014-09-05 19:55         ` David Thompson
2014-09-05 20:10         ` Taylan Ulrich Bayirli/Kammer
2014-09-05 20:50           ` David Thompson
2014-09-07 10:33           ` Neil Jerram
2014-09-07 15:27             ` Taylan Ulrich Bayirli/Kammer
2014-09-05 20:10         ` Panicz Maciej Godek
2014-09-05 20:18           ` Taylan Ulrich Bayirli/Kammer
2014-09-05 20:37             ` Panicz Maciej Godek
2014-09-05 20:51               ` Marko Rauhamaa
2014-09-05 21:53                 ` Taylan Ulrich Bayirli/Kammer
2014-09-05 22:26                   ` Marko Rauhamaa
2014-09-05 20:44           ` Marko Rauhamaa
2014-09-05 21:08             ` Panicz Maciej Godek
2014-09-05 22:14               ` Marko Rauhamaa
2014-09-06  8:53                 ` Panicz Maciej Godek
2014-09-06 10:44                   ` Taylan Ulrich Bayirli/Kammer
2014-09-06 11:27                   ` Marko Rauhamaa
2014-09-06 11:54                     ` Taylan Ulrich Bayirli/Kammer
2014-09-06 23:46                     ` Panicz Maciej Godek
2014-09-07  0:20                       ` Marko Rauhamaa
2014-09-07 12:57                         ` Taylan Ulrich Bayirli/Kammer
2014-09-07 13:58                           ` Marko Rauhamaa [this message]
2014-09-07 16:46                             ` Taylan Ulrich Bayirli/Kammer
2014-09-07 19:49                               ` Marko Rauhamaa
2014-09-07 23:13                                 ` Taylan Ulrich Bayirli/Kammer
     [not found]           ` <CAPjoZoc7X7s+keog6avP62yvgJyQ3Ma_jomhw6xQq_rK9jnhVw@mail.gmail.com>
2014-09-06 16:57             ` Nala Ginrut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ppf7edlw.fsf@elektro.pacujo.net \
    --to=marko@pacujo.net \
    --cc=carlosjosepita@gmail.com \
    --cc=dthompson2@worcester.edu \
    --cc=guile-user@gnu.org \
    --cc=taylanbayirli@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).