From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 231FB7F0F9 for ; Wed, 25 Nov 2015 14:23:17 +0100 (CET) IronPort-PHdr: 9a23:Jf8q4xd3Y8prC2juFEJG31k9lGMj4u6mDksu8pMizoh2WeGdxc+6ZB7h7PlgxGXEQZ/co6odzbGG7ua/CSddu96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDvvcKDKFgSzBOGIppMbzyO5T3LsccXhYYwYo0Q8TDu5kVyRuJN2GlzLkiSlRuvru25/Zpk7jgC86l5r50IeezAcq85Vb1VCig9eyBwvZWz9Er1dhaU/nYXTkkRlxNJBUCFsEC7Dd/NtX7Ysep7kBaaPNH3S78oXjLqu6VsSBnAgyAHOiQ09n3YkMVojKNQu1SqoFpiwNiHTpuSMa9fYKrbNfwdWW1fVcZQSzcJVoKiYKMOAucMe+FCoN+u9BM1sRKiCFz0V6vUwThSiyqzgPQ3 Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f47.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.47 as permitted sender) identity=mailfrom; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f47.google.com) identity=helo; client-ip=209.85.215.47; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkAADbtVVWmy/XVdFehA5vBq5YkVchhW4CgToHPBABAQEBAQEBARABAQEBAQYLCwkhLoItgggBAQMBEhEdAQEsBgUBBAsLBwQaHQICIhIBBQEKEgYTCAoQh3cDCggNn2GBMT4xildxhGMBBYZTA4R2AQEBAQEBBAEBAQEBAQEBARQGCoZKhH6ENVOCbYFEhhYMh3uIP4UoiA2BXEmWR4IlEiSBFxEngi8jgXsgNAGDYoFJAQEB X-IPAS-Result: A0BkAADbtVVWmy/XVdFehA5vBq5YkVchhW4CgToHPBABAQEBAQEBARABAQEBAQYLCwkhLoItgggBAQMBEhEdAQEsBgUBBAsLBwQaHQICIhIBBQEKEgYTCAoQh3cDCggNn2GBMT4xildxhGMBBYZTA4R2AQEBAQEBBAEBAQEBAQEBARQGCoZKhH6ENVOCbYFEhhYMh3uIP4UoiA2BXEmWR4IlEiSBFxEngi8jgXsgNAGDYoFJAQEB X-IronPort-AV: E=Sophos;i="5.20,342,1444687200"; d="scan'208";a="189056017" Received: from mail-lf0-f47.google.com ([209.85.215.47]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 25 Nov 2015 14:23:15 +0100 Received: by lffu14 with SMTP id u14so60265289lff.1 for ; Wed, 25 Nov 2015 05:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jx2VGV/van2288Ace/N0Edb7E9y2JXrGh0sbFQI5mAs=; b=ztL+Cmsa88yHrz7hl7bHhwu4fwRUtXf6FSJm+ltnlQPFYFl81kgsOiDVY/BQ6c5QO6 rNAZ8yeK7ugEruMZhH2B/urrLoPd3ZoLXLXaHscYYErqBLr5y4NtbT4Iz7xqn9LJ5bPK a+qOUqamTsrWzCnqcIGRG1rJ2CgMh+rsPMjbmxBnDc8tJWqgMegxvfAGfheTYpxbl8Gb RzyfFqlg9T2T0VuEXWUdeM4ROXhyIqJYUEEH+uk/9ZngSKW6lF4XgTd/qdgc1fcgMEIq VtlpDqG3OXRS6KvSecfaMsfbgCP+dfao/sUJ5CyiMlgApjKZGwosHvlRSJ7lINx+MYRU 7ehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jx2VGV/van2288Ace/N0Edb7E9y2JXrGh0sbFQI5mAs=; b=FX0HjXvWWh5YnUZB4wmmux4PmKBk7RR5SxXn7ubJawtkTgDcUUbLdjrlIoRbxqXX5g caB3GzO/rN+hNmhiyS+2tskWvIKO1fhqM8yN97uUbliSljZ04EaAx6wv8ERb2Nuciaod dx9HH0Ehb2HnEikAGFu/VN1JS4xzWxiBJmtpvgN2/tEBfmkTzn3WUm5JDuIRIAPQX35i ZCHxhyacLn75tASfpQ7LDw5AGspqKwxoxXhlIKsYCm5BkQM7o5qSTd4FUOstSYK8cpV6 8YvG2vgm0w1BKBNN+v4+ArC9Oe88qZNJC3BItc5U6Kzn4DBuT2QtKqmMMruEJmtlUPL6 hGPA== X-Gm-Message-State: ALoCoQnSCxk+acoM9CIi5qZq0SMdb2TAZ6pQKYnYLQSlINcE5jiWitCRgl91qjR4BPGoBFnOCpzM MIME-Version: 1.0 X-Received: by 10.112.42.41 with SMTP id k9mr13021344lbl.63.1448457794788; Wed, 25 Nov 2015 05:23:14 -0800 (PST) Received: by 10.114.20.66 with HTTP; Wed, 25 Nov 2015 05:23:14 -0800 (PST) In-Reply-To: <5655AE66.6000307@coherentgraphics.co.uk> References: <5655AE66.6000307@coherentgraphics.co.uk> Date: Wed, 25 Nov 2015 08:23:14 -0500 Message-ID: From: Ivan Gotovchits To: John Whitington Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a113367fc54b9ae05255d5cc0 Subject: Re: [Caml-list] Do you use a debugger with OCaml? If not, why not? --001a113367fc54b9ae05255d5cc0 Content-Type: text/plain; charset=UTF-8 The use of a debugger usually indicates that a programmer lost a control of its own program and has no idea whats going on. If a programmer doesn't own a program, and tries to understand existing program, written by someone else, then it means to me, that the program is written so poorly, that it is too hard to recover its semantics by reading its source code representation. OCaml, as well as any other functional programming language, encourages to compose big programs from small and understandable pieces. Due to unique properties of functional programming paradigm this composition is usually linear (lack of mutable state and side-effects). Also, OCaml has a reach type system, that allows a programmer to specify his assumptions and program invariants, so that any violation will be caught on compile time. So, if properly applied, OCaml allows one to write big programs without need for debugging at all. Of course, it is possible to write Fortran 77 in OCaml, in that case you will soon find yourself in the debugger prompt. Sometimes, though, especially when you heavily interact with outside world, like user interface, networking, etc, you find yourself on a loose ground, since your assumptions cannot be defined in terms of OCaml typesystem (no dependent typing, no linear typing). In that case you need to study the dynamics of a program. Usually, in this cases the debugger is not useful, since the program interacts in real-time with some external agent, that is not going to wait for you. My personal approach to debugging is to start from static analysis of the code and try to limit the search space. I also try to extract all possible assumptions that was made by a programmer. Once I have a list of possible suspects, I instrument the code and insert some tests. Sometimes the instrumentation is just a printf, sometime it is just an assert. Quite often, this is just `assert false`. I continue this operation, until only one suspect is left. In most use cases, the initial stage of reading code, will already leave me with only one or two suspects, as if the code is written properly it is usually easy to find a proof (an alibi) for most cases. Of course this require some programming discipline: 1. limit the use of mutual state 2. limit the use of exceptions in favor of returning variant types (option, result, or_error) This two rules ensures linearity, due to the lack of side effects. And usually, this is side effects, that we're trying to debug with a debugger or printfing. On Wed, Nov 25, 2015 at 7:49 AM, John Whitington < john@coherentgraphics.co.uk> wrote: > Hi, > > Like, I suspect, many people, my method has always been to insert Printfs, > and stare at code until I find the problem. In fact, the ocaml.org page > on ocamldebug says: > > "In fact, for complex programs, it is likely the case that the programmer > will use explicit printing to find the bugs, since this methodology allows > the reduction of the trace material: only useful data are printed and > special purpose formats are more suited to get the relevant information, > than what can be output automatically by the generic pretty-printer used by > the trace mechanism." > > So, I ask: What do you use for debugging small and large OCaml programs? > If not a debugger, why not? What problems prevent it? How does your > debugging process differ when writing OCaml compared with other languages > you use? > > John > > -- > John Whitington > Director, Coherent Graphics Ltd > http://www.coherentpdf.com/ > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a113367fc54b9ae05255d5cc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The use of a debugger usually indicates that a programmer = lost a control of its own program and has no idea whats going on.=C2=A0If a programmer doesn't own a program, and tries to understand existin= g program, written by someone else, then it means to me,=C2=A0
th= at the program is written so poorly, that it is too hard to recover its sem= antics by reading its source code representation.

<= div>OCaml, as well as any other functional programming language, encourages= to compose big programs from small and understandable=C2=A0
piec= es. Due to unique properties of functional programming paradigm this compos= ition is usually linear (lack of mutable state and side-effects). Also,=C2= =A0
OCaml has a reach type system, that allows a programmer to sp= ecify his assumptions and program invariants, so that any violation
will be caught on compile time.=C2=A0

So, if pr= operly applied, OCaml allows one to write big programs without need for deb= ugging at all. Of course, it is possible to write Fortran 77 in=C2=A0
=
OCaml, in that case you will soon find yourself in the debugger prompt= .=C2=A0

Sometimes, though, especially when you hea= vily interact with outside world, like user interface, networking, etc, you= find yourself on a loose ground,
since your assumptions cannot b= e defined in terms of OCaml typesystem (no dependent typing, no linear typi= ng). In that case you need to study=C2=A0
the dynamics of a progr= am. Usually, in this cases the debugger is not useful, since the program in= teracts in real-time with some external agent, that is=C2=A0
not = going to wait for you.=C2=A0

My personal approach = to debugging is to start from static analysis of the code and try to limit = the search space. I also try to extract all possible assumptions
= that was made by a programmer. Once I have a list of possible suspects, I i= nstrument the code and insert some tests. Sometimes the instrumentation is = just=C2=A0
a printf, sometime it is just an assert. Quite often, = this is just `assert false`. I continue this operation, until only one susp= ect is left. In most use cases, the=C2=A0
initial stage of readin= g code, will already leave me with only one or two suspects, as if the code= is written properly it is usually easy to find a proof (an alibi) for
most cases. Of course this require some programming discipline:
=

1. limit the use of mutual state
2. limit the= use of exceptions in favor of returning variant types (option, result, or_= error)

This two rules ensures linearity, due to th= e lack of side effects. And usually, this is side effects, that we're t= rying to debug with a debugger or printfing. =C2=A0


On Wed, Nov 25= , 2015 at 7:49 AM, John Whitington <john@coherentgraphics.co.uk<= /a>> wrote:
Hi,

Like, I suspect, many people, my method has always been to insert Printfs, = and stare at code until I find the problem. In fact, the ocaml.org page on ocaml= debug says:

"In fact, for complex programs, it is likely the case that the program= mer will use explicit printing to find the bugs, since this methodology all= ows the reduction of the trace material: only useful data are printed and s= pecial purpose formats are more suited to get the relevant information, tha= n what can be output automatically by the generic pretty-printer used by th= e trace mechanism."

So, I ask: What do you use for debugging small and large OCaml programs? If= not a debugger, why not? What problems prevent it? How does your debugging= process differ when writing OCaml compared with other languages you use?
John

--
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/


--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a113367fc54b9ae05255d5cc0--