You don't seem to be acquainted with the state-of-the-art in IDEs and
debuggers. Try developing C# in Visual Studio, for example, and you will
quickly see that it automates a lot of this very tedious work that you are
currently doing by hand in SML.
This is not surprising because SML is a long way from having a
professional
development environment but you repeatedly talk about SML as if it is
ready
for prime time when, in reality, it is a long way from being usable for
the
majority of practical applications.
Vesa Karvonen wrote:
> Note that I'm not arguing that debuggers wouldn't be useful. My point
> is that it is typically more productive (in the long run) to avoid
> using debuggers and instead invest on types, tests, assertions,
> logging, etc... These are things that can (and usually do) make it
> easier to work with the program over time.
Types are orthogonal and the rest is simply Greenspunning a debugger.
> In my experience, typically the fastest way to find a good place to
start
> looking at the code is to use grep --- not a debugger.
Using grep is an awful way to study source code because it has absolutely
no
specialist knowledge of what meaning the text conveys. Compare using grep
to using Intellisense, for example.
> For example, if the program has a GUI, you just grep for labels you can
> see in the relevant widgets.
GUIs are the perfect example to showcase the enormous productivity
improvements offered by tools like Visual Studio. Coding something like a
GTK app in OCaml is incredibly tedious by comparison.
> A useful "static" technique for getting a "big picture" of a large
program
> is to print out a dependency graph.
Static analysis is of limited use. For example, it does not convey dead
code.
> If you are fixing a bug, then in most cases with SML, you should be
> getting an exception. With SML/MLton, you can easily get the exception
> history (stack trace) in such a case and that usually gets you very
close
> to the problem.
You are also highly likely to get segfaults due to broken bindings, GC
corruption etc. so you need conventional debugging capabilities as well.
>> what's in the data structures, etc.
>
> Static types make this significantly easier...
That is a limitation of SML rather than a generic argument in favor of not
using a debugger.
>> or go through a million compile-and-trace cycles adding and removing
>> print statements.
>
> But that would be silly. Instead of adding and removing print
> statements, you should create (or just use --- it probably already
> exists for your language) a simple logging facility (roughly a page of
> code) that lets you add concise logging statements to your code and
> leave them there without harm.
Your compiler should autogenerate all of that for you in a Debug build.
> Does the legacy code you are maintaining come with a useful test
> suite? Does it make good use of a logging facility? Is it written in
> a safe statically typed language?
The vast majority of real software, if it were ever written in SML, would
inevitably require library bindings to interface with the outside world so
it is not "safe".
> It is easy to use legacy code as an excuse. It is that badly written
code
> that nobody wants to touch or even to look at. Justifying the use of
> wasteful programming practices using "legacy code" as an argument is a
> mistake.
> ...
> If you can't make sense out of code without a debugger, the
> problem is with the code. Fix the code or find another job if you are
not
> allowed to fix it.
You will never build anything useful with that attitude. In reality,
interoperability is hugely im****tant and very poorly sup****ted by all SML
implementations and OCaml compared to mainstream tools (even free,
single-implementation ones like Python).
> In my experience, ...
> ...
> Debuggers aren't magical. A debugger cannot tell you what the code is
> supposed to do. At most they can show you what the program does at
> run-time. I say "at most", because there are programs that can be
> difficult to run productively under a debugger
> (e.g. concurrent/parallel programs, interactive real-time programs
> (e.g. games)) --- especially unless you already *exactly* know where
> to put the breakpoint (if you don't put the breakpoint at the right
> place, you'll only make it next to impossible to run the program).
Actually those are all easy in the right environment, e.g. F#.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
|
