Re: [Haskell-cafe] Is Haskell a 5GL?
On 30/09/2006, at 6:15 AM, Nicolas Frisby wrote: Software engineering is as of yet misnamed. A professional engineer's design work should never include figuring out why the first attempt exploded/collapsed/failed--professionals in mature engineering fields only debug catastrophes. That is only the case when engineers are performing pure development. When they are involved in research, engineers first attempts routinely explode/collapse/fail. Building a house, bridge, refinery, family car, etc, stopped being research a long time ago. However F1 racing cars, and interplanetary autonomous vehicles are. Software Engineering is so new a discipline that we still don't know how to render any but the most trivial of problems 'pure design'. My intended takeaway is that design in software engineering does not yet compare to design in the mature engineering fields. In my engineering-centric opinion, the goal of computer science is to enrich the design principles of software engineering so that it does compare. I couldn't agree more. So I'm going to quote the passage from Robert Dockins that you objected to. On 29/09/06, Robert Dockins [EMAIL PROTECTED] wrote: In a similar way, if a someone refuses or is unable to learn the mathematical foundations of computation, I don't think I really want him programming any systems that I'm going to be relying on. He don't need to be an expert in category theory, but if programmers aren't learning the skills they need to understand the basics and mathematical notation of PL theory, then something is very, very wrong. (Not to beat you over the head with my point, but what I'm saying is that programmers really ought to know this stuff and the fact that most do not is a terrible state of affairs). Of course we will have hobbyist programmers, in much the same way we have home handymen or backyard mechanics. However anyone claiming to be a professional programmer has to deal with everything they do not being pure design, but containing a non-trivial element of research. For that reason I have to agree with Robert. I too am very concerned at the number of programmers writing code that I rely on who don't have a basic understanding of the mathematical foundations of what they do. Andrae -- Andrae Muys [EMAIL PROTECTED] Principal Mulgara Consultant Netymon Pty Ltd ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: how do you debug programs?
On 06/09/2006, at 8:22 PM, Neil Mitchell wrote:It's been my experience that debugging is a serious weakness ofHaskell - where even the poor mans printf debugging changes thesemantics! And everyone comes up with arguments why there is no needto debug a functional language - that sounds more like excuses aboutwhy we can't build a good lazy debugger :)[Sorry for the slight rant, but I've used Visual Studio C++ so I knowwhat a good debugger looks like, and how indispensable they are]I simply can't let this pass without comment. It's irrelevant if you're using a functional or imperative language, debuggers are invariably a waste of time. The only reason to use a debugger is because you need to inspect the contents of a processes address-space; so either you're using it as a disassembler, or you're using it to examine the consequences of heap/stack corruption. Consequently, if you're using Java, C#, Scheme, Haskell, Erlang, Smalltalk, or any one of a myriad of languages that don't permit direct memory access, there's no reason for you to be using a debugger.Jon understates it by implying this is a Functional/Haskell specific quality - it's not. Debuggers stopped being useful the day we finally delegated pointer handling to the compiler/vm author and got on with writing code that actually solves real problems.It's just that historically functional programmers have tended to already be experienced programmers who realise this. Why would they waste their time building a tool that no-one needs?It's a truism to say if your code doesn't work it's because you don't understand it; clearly if you did understand it, you wouldn't have included the bug that's causing you difficulty.Therefore either1) The code is poorly structured and you need to restructure it to better represent your understanding of the problemor2) Your understanding of the problem is flawed, so you need to sit back and reexamine your thinking on this problem in light of the counter-example you have found (the bug).Spending your time tracing through individual lines of code is counter-productive in both cases.Andrae MuysP.S. It is worth noting that I am here talking about the sort of debugger raised in the original post. I am not talking about using a separate tool to extract a stracktrace from a core file in a C/C++ program or equivalent - I'm talking about runtime debugging with variable watches, breakpoints, and line-by-line stepping. -- Andrae Muys[EMAIL PROTECTED]Principal Kowari ConsultantNetymon Pty Ltd ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
