From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: A couple of questions about goops method parameters Date: Sun, 07 Sep 2014 16:58:51 +0300 Message-ID: <87ppf7edlw.fsf@elektro.pacujo.net> References: <1409905923.9245.5.camel@Renee-desktop.suse> <871trpridm.fsf@izanagi.i-did-not-set--mail-host-address--so-tickle-me> <871trpkdbf.fsf@elektro.pacujo.net> <87bnqtiukx.fsf@elektro.pacujo.net> <878ulxgfa4.fsf@elektro.pacujo.net> <87egvoffh7.fsf@elektro.pacujo.net> <87ppf7eggu.fsf@taylan.uni.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410098361 7512 80.91.229.3 (7 Sep 2014 13:59:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Sep 2014 13:59:21 +0000 (UTC) Cc: Carlos Pita , David Thompson , "guile-user@gnu.org" To: Taylan Ulrich Bayirli/Kammer Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Sep 07 15:59:14 2014 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQczq-00034s-9I for guile-user@m.gmane.org; Sun, 07 Sep 2014 15:59:14 +0200 Original-Received: from localhost ([::1]:38294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQczp-0006L4-KS for guile-user@m.gmane.org; Sun, 07 Sep 2014 09:59:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQczc-0006Kw-UI for guile-user@gnu.org; Sun, 07 Sep 2014 09:59:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQczX-0001eI-Vx for guile-user@gnu.org; Sun, 07 Sep 2014 09:59:00 -0400 Original-Received: from pacujo.net ([83.150.83.132]:44055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQczX-0001dE-NB for guile-user@gnu.org; Sun, 07 Sep 2014 09:58:55 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Sun, 7 Sep 2014 16:58:51 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Sun, 7 Sep 2014 16:58:51 +0300 In-Reply-To: <87ppf7eggu.fsf@taylan.uni.cx> (Taylan Ulrich Bayirli's message of "Sun, 07 Sep 2014 14:57:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 83.150.83.132 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11483 Archived-At: Taylan Ulrich Bayirli/Kammer : > Marko Rauhamaa 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 =CE=BB 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