I'm interested in what tools and methods are used for diagnosing flaws in large scale functional programs. What tools are useful? My current understanding is that 'printf' debugging (e.g. add logging and redeploy) is what is typically used.
If you've done debugging of a functional system what was different about it then debugging a system built with an OO or procedural language?
Sadly, printf debugging seems to be the state of practice for Standard ML, Objective Caml, and Haskell. There's a little bit of debugging at the interactive read-eval-print loop, but once your app hits 25,000 or 50,000 lines that's less useful.
If you're lucky enough to be using Haskell, there's an exception: QuickCheck is indispensible for testing and deubgging. QuickCheck can be used even on combinations of Haskell and C code, as demonstrated by experience with the Xmonad window manager.
It's worth noting that around 1990 Andrew Tolmach built a very nice time-travel debugger for Standard ML of New Jersey, but that it was not considered worth maintaining. It's also worth noting that at one point the OCaml debugger (also a time-travel debugger) worked only on bytecode, which was inconvneient, and refused to violate abstraction barriers, which made it useless. This was around release 3.07 or so; perhaps things have improved.
Also in the early 1990s, Henrik Nilsson built an interesting debugger for Haskell, but mostly what it did was prevent the debugger from accidentally changing the evaluation behavior of the program. This was interesting, but only to lavzy-evaluation weenies.
As someone who has built or worked on large applications in all three of these languages, I find the state of play depressing.
The main tools we use at work (a Haskell shop) are:
QuickCheck
HPC: visual Haskell program coverage tool (we developed this in house)
Logging/printf/trace
Sometimes, the GHCi debugger
My current job is to implement new features and support a large system implemented in ocaml and C#. Most of the "logic" is implemented in caml and the GUI and data access is in C#. The debugging techniques are pretty much as you describe lots of logging and assert to work out what's gone wrong.
Additionally we have a large number of unit tests, which are just caml scripts for testing the logic and help to spot any regression errors.
We also use continuous integration to check the build and run nightly test scripts, including some automated testing of the GUI though our "automation" style scripting interface.
I quite often use the C# debugger for debugging the C# portion of the application, the ocaml debugger does yet work under windows so we don't use it. Although we hope one day we may fix this but it isn't top of our priority list. I have occasionally used windbg to investigate managed and unmanaged memory problems, though this turned out to be caused by a third party component implemented in C#.
So overall, nothing out of the ordinary but it seems to work okay, we don't see too many production problems.
Thanks,
Rob
F# has Visual Studio integration, so you can attach the debugger to your program and set breakpoints, watches, etc, just like with any other .NET language.
However, I prefer to avoid debugging as much as possible, by writing short functions that I can unit-test individually.
A couple of years ago when I did this I had to use a combination of printf debugging and QuickCheck. These days I would also use the ghci built-in debugger.
The biggest headache was actually laziness causing space-time leaks. There still doesn't seem to be a good answer to these: just do lots of profiling and keep trying to figure it out.
OCaml and F# both have excellent debuggers. OCaml's is time reversible. F#'s has excellent IDE and multithreading support.
Related
I've spent the better part of my morning and afternoon playing around with GUI frameworks in Haskell, as I need some visualization and interaction capabilities and I'm not in love with writing my core functionality in Haskell then piping out to a front end written in another GUI; I'd prefer to do it all from one language. The better part of that better part has been spent compiling and patching source code, or Googling obscure compilation errors.
I've spent plenty of time reading SO questions, plenty of time on haskell.org, and plenty of time reading documentation. What I've encountered is a very large swath of outdated or poorly documented information. I can boil it down to these three things:
A glut of options built on top of Gtk+ bindings. I don't care for Gtk+ very much, mostly because I find it to be quite unpleasant to look at, especially on OS X. Griping about the UI looking out of place and/or just plain ugly might seem silly, but that's important to me. Especially if I want other people to utilize any of the programs that I create.
wxHaskell, which is stable and incredibly easy to install but many of the existing tutorials seem to be for wx-0.1x and the conventions for bridging the wxWidgets 2.9.x docs to wx-0.90.x are very very spotty and hard to grok, when they even exist.
qtHaskell, which seems to be mostly abandoned (correct me if I'm wrong), only compiles with newer versions of GHC after applying a year-old patch, and spits out a massive amount of warnings that indicate they will soon become compile errors in newer versions of GHC.
In effect, I'm looking for Haskell's answer to Java's Swing; a library that is robust, maintained, well documented, easy to get started with, makes an attempt to be native in look and feel, can keep up with GHC's development pace, and not at high risk for abandonment. This seems to be exactly zero GUI frameworks, but then it seems that most of the "official" resources/wikis/pages/docs related to GUI frameworks are woefully unmaintained so I decided to turn to the community to see if there was something I just wasn't finding. I'm not terribly worried about the framework being cross platform, just so long as it works on modern versions of OS X.
To reiterate, I'm not really looking for someone to send me a link to haskell.org or the WikiBook. I've been there, and I didn't like what I saw. Most of the information there is just so out of date that it only creates more work, not less.
I realize that my "demands" are a little extreme, especially for a language with a smaller community like Haskell, but I was hoping that someone out there could be of assistance to me. In the mean time, I intend to simply try and ride out wxHaskell or qtHaskell until I succeed or die.
I hope I'm not coming across as gruff or frazzled.
wxHaskell is good, yes, and my go-to GUI middle level library. I admit there's been a focus on updating the code before the docs in the new version.
For modern, functional-reactive-programming fun stuff on top of it I gor for reactive banana, which is actively maintained, and has the added benefit that Heinrich Apfelmus himself may well turn up here to answer your questions.
Threepenny-gui is the most recent contender in the space of Haskell GUI libraries.
Its main selling point is that it is very easy to install, because it uses the web browser as a display. It's also easy to get started with.
On the other hand, it doesn't even attempt to have a native look and feel – the UI is built solely on HTML. (This may change in the future, as we have the option of using XUL). Also, the API is still very much in flux, so be prepared that new major versions of the library are likely to break backwards compatibility. (On the other hand, this means that it's actively developed. :-))
(Disclosure: I'm the author / maintainer of the threepenny-gui package.)
I feel your pain; this answer is an attempt to provide some alternatives that may be good enough and perhaps help you with your search.
First, there is a language called Concurrent Clean. It is supposed to be similar to Haskell, has GUI support and is meant for writing real-world applications. It differs in some respects; for instance, its I/O is based on unique types rather than Monads, which as far as I'm concerned, is a good thing :). Here is a link:
http://wiki.clean.cs.ru.nl/Clean
Next, I dug around for a Haskell compiled to the JVM, in the hopes that it would piggy-back on the Java libraries, ala Clojure. No dice. What I did find was a SO thread discussing the lack and the challenges thereof:
Haskell on JVM?
From that thread however, two other options were brought up. One is Frege:
http://code.google.com/p/frege/
The other is CAL:
https://github.com/levans/Open-Quark
There's also work on functional reactive programming in Haskell. It's supposed to enable things like GUIs, although whether or not you'll actually get a GUI out of it is another matter:
http://www.haskell.org/haskellwiki/Functional_Reactive_Programming
It's sad. Here we have the JVM and .NET and yet zilch for Haskell. It's worse than that; .NET has shown an alarming tendency to ditch promising implementations. Whatever happened to IronScheme, IronLisp and IronHaskell? All dead as far as I can tell.
Not good :(
You may be familiar with
ReplayDirector, http://www.replaysolutions.com/products/replaydirector-for-java-ee
Chronon, http://www.chrononsystems.com/products/chronon-time-travelling-debugger
they both advertise themselves as 'Java DVRs' - are there any open-source implementations that offer similar (even a subset of their) features?
The only ones I know of are
WhyLine
Not open source yet, but may eventually be, free download though
Omniscient Debugger
Jive
Diver
TOD
Omniscient debuggers record the trace data to query afterwards. They are often also called reverse-, back-in-time, bidirectional- or time-travel-debuggers, but I prefer to reserve those terms for debuggers that allow actual reversing in a live program.
TOD is an open-source omniscient debugger for Java.
JIVE is another free omniscient debugger for Java, though not open-source.
The GNU debugger, gdb. It has two modes, one is process record and replay, the other is true reverse debugging. It is extremely slow, as it undoes single machine instruction at a time.
And for Python, the extended python debugger prototype, epdb, is also a true reverse debugger. Here is the thesis and here is the program and the code. I used epdb as a starting point to create a live reverse debugger as part of my MSc degree. The thesis covers the details of the implementation, as well as most of the historical approaches to reverse debugging. It is available online: Combining reverse debugging and live programming towards visual thinking in computer programming.
I'm looking at writing an application for my dissertation that runs on XP, Vista and 7. Would you say C# or C++ is the best language? Sorry I'm new to programming and wanted some expert opinion.
Thanks in advance.
Two guidelines:
Use C# (or even Visual Basic .NET) if you need something to work (mainly) only on Windows and if you don't care if your application takes a little while to start up or ends up being a few nanoseconds slower than its native counterpart. If you're new to programming, you might find Visual Basic .NET to be a lot more like English than C#, and there's no real reason to choose one over the other: they both end up being the same kind of executable with the same power and performance. (Furthermore, debugging is also easier with C#, so try that.)
Use a native language (like C or C++) if you need more speed/power, especially if you need to be sure that it's your code that's executing, not some translated version of it. If you're new to programming, this will be overwhelming (not to mention time-consuming and confusing), so I highly don't recommend it.
If you don't mind another option, though, also take a look at Java -- it's similar to C# in some ways but it's designed to be simpler in other ways, and also to be platform-independent.
I think the question you want to ask is 'What is the difference between C# and C++?' because there is no clear cut answer for the question of which is better.
As for writing an application to work on those three operating systems, both languages work well. Because you are a beginner in programming, I would use C# just because it is much easier to learn.
C# runs on top of the .NET Framework, which will clean up some of your mistakes especially if your new to programming. It's also easier to produce and output of your application. All that of a cost, C++ is much more faster more complex and requires experience before you can build something useful or high profile looking.
I am using a rather obsure, proprietary langauge called WIL/Winbatch that had an awful IDE (winbatch studio).
I would like to develop an alternative environment; however, without the ability to set breakpoints, step, and examine variables, there is really no point. How does one begin even researching how to implementing a debugger for a proprietary language? Is it even legal?
I guess I'm kind of locked in a mindset that the debugger portion must be able to examine the statements that are provided to it in WIL as they are executed, right? So somehow i have to trap the output of the interpreter? Or is it just a matter of reading locations in memory using whatever language?
Thanks in advance.
Having been there and successfully completed the task, here are the things to keep in mind:
Build it as a plug-in/extension to an IDE your team is already familiar with and likes. They'll thank you for providing an interface consistent with what they really know how to use, plus you can focus entirely on the features that make your language different from others.
You'll have to learn the debugging protocol for your language. In our case, we had source access to the runtime for the interpreted language. In other cases, you may find documentation for GDB local or remote debugging interface, a library you can link to for the language's debugging protocols, or maybe even figure out what the call stacks look like and wrap the Windows Debugging API to analyze it behind the scenes.
Don't build in excess of what the language provides. Adding debugging features takes a lot of time, and they have a rather annoying habit of needing to be significantly altered or completely rewritten as versions of the target language are updated.
Why are you tied so closely to this language? If it's not well supported, there are many others you can use. Anyway, to actually answer your question, the difficulty depends on whether it is a compiled or interpreted language and whether or not you have access to any source code (which it seems of course, that you don't). That said, this would be a very challenging project as you would have to reverse engineer the compiled code for it to have any meaning. Your time would be better spent learning another (better) language.
Perhaps if you can give us an idea of why you want to use this language we could give you some help?
Do you use source code analyzers? If so, which ones and for which language development?
Do you find them helpful in solving potential bugs in your code? Or are most of their warnings trivial?
After prolonged use, do you find your code quality to be higher than before?
I use a few static analysis tools in Java. FindBugs is the first line of defense, catching a lot of common errors and giving pretty useful feedback. It often spots the silly mistakes of tired programmers and doesn't place a high burden on the user.
PMD is good for a lot of other more niggly bugs, but requires a lot more configuration. You'll find that PMDs defaults are often over the top. There are too many rules that are probably beneficial on a tiny scale but ultimately don't help other programmers maintain your code. Some of the PMD rules often smack of premature optimisation.
Probably more useful is the CPD support in PMD. It attempts to find code that has been duplicated elsewhere, in order to make refactoring much easier. Run over an entire project, this really helps determine where the biggest priorities are for cleaning up code and stopping any DRY violations.
Checkstyle is also handy, making sure your coders conform to some coding style standard. it has a bit of overlap with PMD but is generally much more usable.
Finally, Cobertura is a great test coverage suite. Very handy for finding out where the unit tests are lacking, and where you should be prioritising the creation of new tests.
Oh, and I've also been testing out Jester. It seems to be pretty good for finding holes in tests, even where the code has some coverage. Not recommended yet, simply because I've not used it enough, but one to test out.
I run these tools both from within Eclipse and as part of an automated build suite.
For C, I use MEMWATCH. It's really easy to use and free.
I've used it to find many memory bugs in the past.
I used resharper and MS TS (basically FXCop) and both of them quite usefull especially in the following areas :
Identifying dead code
Wide Scope
Performance improvements (related with globalization etc.)
Recommendations are not always great but generally improved the quality of the code.
I'm a long term user of PC-Lint for C and C++ and find it very helpful. These tools are most useful when taking over a code base you are unfamilier with. Over time you hit a law of diminishing returns, where the number of new bugs you find tends to trail off.
I always still to a full project lint on a big release.
Edit: There is a nice list of relevent tools on Wikipedia here
I'm pretty happy with ReSharper. Not only does it give useful bits of information while coding (e.g. needless casts, apply readonly and so forth) but its refactoring features are excellent for rearranging the code very quickly.
It doesn't cover everything, so FxCop (or similar) is a decent addition to the toolbox. However, as Resharper gives immediate feedback, the turnaround time is really good. (I'm aware that FxCop can be run from VS, but its just not the same imo).
I find analyzers somewhat useful, i use the buildin to visual studio (ex. /analyze for c/c++ and the custom rules for .net), occasionally i use stylecop and codeitright for c# mostly for guidelines how things should be.
I don't think there is a perfect tool for everything, that finds every bug, but i think the tools help to find some bugs, not untraceable, but believe me you would spend a ton of time finding them.
Yes your code quality is SOMEWHAT better than before, but i also believe manual debugging is still needed alot. Source analyzers are not the ultimate cure they are a good medicine though. If there was a tool that you just execute it and find any kind of bugs and fixes it for you would cost millions.
Some programmers that i know swear that IBM Rational PurifyPlus is superb, but that is their opinion i just had 2-3 sessions with the tool.
But always remember one of the basic principles of programming logical errors are the hardest for find and fix, so long debugging hours are inevitable. A good code analyzer combined with unit testing may work miracles thought.
PS. i tend to produce far less errors in C# than in C++, someone may say i am wrong but although i use c++ more years than c# i find the "code it and i will take care of it" gc approach of C# far easier than c++ especially for projects you rush thing to finish at the time limit/deadline, which EVERY project is like this days...
I use StyleCop for C#. It's a great tool to keep consistent code style that leads to better code quality. Also ReSharper does some code analysis but it's pretty basic.