From: Panicz Maciej Godek <godek.maciek@gmail.com>
To: Marko Rauhamaa <marko@pacujo.net>
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, 7 Sep 2014 01:46:07 +0200 [thread overview]
Message-ID: <CAMFYt2YZWMTsNTUiV6WmREfNKU_W-DE73V5DF=QavT+bQnm85A@mail.gmail.com> (raw)
In-Reply-To: <878ulxgfa4.fsf@elektro.pacujo.net>
2014-09-06 13:27 GMT+02:00 Marko Rauhamaa <marko@pacujo.net>:
> Panicz Maciej Godek <godek.maciek@gmail.com>:
>
>> However, I'd rather say that the lack of any type system in Guile is
>> an inconvinience, because static type checking allows to avoid a huge
>> class of software errors, and a good type system (like the one in
>> Haskell) actually enhances language's expressiveness.
>
> We already have a satisfactory selection of languages with static type
> annotation. The primary upside of static types is much faster code. The
> downside is boilerplate and clutter that make it a huge chore to write
> and maintain the code.
Taylan already wrote a few remarks on that statement. Obviously, when
you're talking about statically typed languages, you mean C, Pascal,
and its derivatives. However, you're mistaken. Haskell or ML are also
statically typed, but because of type inference, they do not introduce
any boilerplate nor clutter.
The fact that C compiler performs static type checking has nothing to
do with its performance. It's only about detecting type errors. So for
example if you have code like:
short f();
long g() {
return f();
}
the compiler will generate an error. An alternative would be to
compile according to specification and let the user worry about the
problems caused by type mismatch (and I think that this is what the
early C compilers were doing)
> In my experience, high-level programming
> languages allow you to accomplish more challenging feats with better
> quality and productivity than statically typed languages.
In addition to Taylan's remark, my experience is that in large
programs it's very easy to make a type error, and it may take some
time for that bug to manifest, and because of that latency such bugs
become more confusing and harder to trace. Furthermore, having type
signatures often make complex programs easier to read.
next prev parent reply other threads:[~2014-09-06 23:46 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 [this message]
2014-09-07 0:20 ` Marko Rauhamaa
2014-09-07 12:57 ` Taylan Ulrich Bayirli/Kammer
2014-09-07 13:58 ` Marko Rauhamaa
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='CAMFYt2YZWMTsNTUiV6WmREfNKU_W-DE73V5DF=QavT+bQnm85A@mail.gmail.com' \
--to=godek.maciek@gmail.com \
--cc=carlosjosepita@gmail.com \
--cc=dthompson2@worcester.edu \
--cc=guile-user@gnu.org \
--cc=marko@pacujo.net \
/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).