Comparison of debuggers

[sans-hubris]

I want to get an idea of what kind of debuggers people like, and yes, this includes the one in MSVC++. I'll be surprised if anyone mentions gdb without a frontend.

My personal favorite is gdb with the gui frontend, DDD (http://www.gnu.org/software/ddd/). The only thing that I would fault it for would be its general UI. It's not all that intuitive and so the features that make it unique and extremely helpful aren't immediately obvious. You end up having to dig through a little documentation to figure it out. It could definitely use some cleaning up. I should mention that I haven't seen it crash in a long time I'm using version 3.3.

After that, I have to admit that MSVC++'s debugger isn't that bad. I don't like doing Windows development, but this is one tool that does its job quite well.

[nex]

I usually use gdb with no front end.

just to go ahead and get that out of the way.

[jamessan]

Same here with the use of gdb w/out a front-end.

[GnuVince]

The debugger I liked most was dbg400 on the AS/400 platform. It was quite easy to use. But I must admit that I'm a bigger fan of copying a function in a top-level loop and trying to figure it out.

[jemfinch]

I've really never found debuggers very useful. If I have problems with a function, first I just read the function over, reviewing what it does in my head; if that doesn't work, I'll probably add some print statements and/or break the function up into smaller, easier-to-understand pieces.

I think in most cases, using a debugger is trying to fix the symptom of the problem rather than the problem itself. Code should be easy enough to read that a debugger isn't necessary. When code becomes too complex to figure out simply by reading, it should be recoded more understandably and/or broken down into smaller bits.

I guess I'm a bit on Linus Torvald's side when it comes to debuggers. Ugh. I don't like that.

(Comments: My code isn't so good that I don't have to debug it regularly, I just use methods other than a debugger; also, I don't use low-level languages like C, where a debugger might be slightly more useful, but I would imagine that if people wrote C like it was a higher-level language, they wouldn't need a debugger as often.)

Jeremy

[Strike]

Side note: DDD apparently has hooks for pdb (the Python debugger) as well. Of course, I've never used the Python debugger ...

[liquience]

typically i'll just use gdb when coding on a unix system without a frontend... but i've been known to use ddd from time to time as well.

on windows side i have to go with msvc++.. i actually like that debugger quite a bit.

[stuka]

The only debugger I've used on Linux/Unix systems is gdb w/o a frontend (unless lots of printf's qualify as a debugger! ;) ). I really do like the VC++ debugger. Now if only I could get the built-in editor to work like vim....;)

[Strike]

Originally posted by Stuka
The only debugger I've used on Linux/Unix systems is gdb w/o a frontend (unless lots of printf's qualify as a debugger! ;) ). I really do like the VC++ debugger. Now if only I could get the built-in editor to work like vim....;)
Why get it to work like vim when you can get it to be vim. Just google around for the OLE VisVim stuff and hope you can find the old instructions for doing it.

[kmj]

At work, I use The Debugger for MSVC++ in Visual Studio. It tends to work fine and seems to have all the features I need.

Btw, I have visvim. It's not hard to set up, but doesn't integrate with the debugger, as far as I know.

edit: Also, the visvim integration tends to make Visual Studio flaky in NT. I hear it's better in 2K, though.

[stuka]

Strike: I don't really like the way that gvim integrates with VC++ - it doesn't feel very integrated (and I've never liked the font, etc. that gvim uses in Windows).

kmj: Visual Studio on NT needs help being flaky? ;)

[kmj]

well, it's usually not too bad for me when I use it on it's own.. It crashes quite often when I have visvim turned on..

[Strike]

Originally posted by Stuka
(and I've never liked the font, etc. that gvim uses in Windows).
Edit your _gvimrc then :)

<attempt at staying on topic>
Debugger foo is really cool, it pwnz all other debuggers!
</lame attempt>

[stuka]

dammit, that's too much like work - and it still doesn't solve the whole 'integration' thing (I know, that would require MS intervention, or some such...which WON'T happen, I'm sure)

[phubuh]

I love the debugger built into the (amazingly fantastically fantastic) Java IDE IDEA (http://www.intellij.com).

[file13]

i would say GVD (GNAT Visual Debugger) for Ada (which is a gdb gnat front end) is my favorite...but i've never needed a debugger in Ada since most errors are caught at compile time and the rest at runtime.... ;)

http://libre.act-europe.fr/gvd/

so i guess i'll have to say any Lisp implementations' "debugger":


ECL (Embeddable Common-Lisp) 0.7
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help. Top level.
> eat shit!
The variable EAT is unbound.
Top level.
>> The variable SHIT! is unbound.
Top level.
>>> ?

Break commands:
:q(uit) Return to some previous break level.
:pop Pop to previous break level.
:c(ontinue) Continue execution.
:b(acktrace) Print backtrace.
:f(unction) Show current function.
:p(revious) Go to previous function.
:n(ext) Go to next function.
:g(o) Go to next function.
:fs Search forward for function.
:bs Search backward for function.
:v(ariables) Show local variables, functions, blocks, and tags.
:hide Hide function.
:unhide Unhide function.
:hp Hide package.
:unhp Unhide package.
:unhide-all Unhide all variables and packages.
:bds Show binding stack.
:m(essage) Show error message.
:hs Help stack.

Top level commands:
:cf Compile file.
:exit or ^D Exit Lisp.
:ld Load file.
:step Single step form.
:tr(ace) Trace function.
:untr(ace) Untrace function.

Help commands:
:apropos Apropos.
:doc(ument) Document.
:h(elp) or ? Help. Type ":help help" for more information.
>>>


i love instant feedback..... ;)

[jemfinch]

Originally posted by file13
most errors are caught at compile time and the rest at runtime.... ;)


Ya sure? :-P

Jeremy

[file13]

Originally posted by jemfinch
Ya sure? :-P

Jeremy

yup!


procedure Bullshit is

type Holy_Languages is (Ada, Lisp, Ml);
type Unholy_Languages is (C, C_Plus_Plus, Java);

Holy : Holy_Languages;
Unholy : Unholy_Languages;

begin
Holy := Lisp;
Unholy := C;
Holy := Unholy;
end Bullshit;


-----XEmacs: bullshit.adb (Ada Font)----All------------------------------------------------------------------------------
cd /home/file13/tmp/
gnatmake bullshit
gnatgcc -c bullshit.adb
bullshit.adb:15:12: expected type "Holy_Languages" defined at line 6
bullshit.adb:15:12: found type "Unholy_Languages" defined at line 7
gnatmake: "bullshit.adb" compilation error

Compilation exited abnormally with code 4 at Tue Nov 19 15:40:21


kinda like Ocaml with useful error messages!


with Ada.Text_IO;
with Ada.Integer_Text_IO;

procedure Bullshit is
use Ada.Text_IO;
use Ada.Integer_Text_IO;
X : Integer;
begin
Put_Line ("Enter an integer: ");
Get (X);
Put_Line ("Wow, a" & Integer'Image (X));
end Bullshit;



[file13@anatta tmp]$ ./bullshit
Enter a integer:
2
Wow, a 2
[file13@anatta tmp]$ ./bullshit
Enter a integer:
fuck you!!!

raised ADA.IO_EXCEPTIONS.DATA_ERROR : a-tiinio.adb:91 instantiated at a-inteio.ads:20
[file13@anatta tmp]$


and we need for good measure:


with Ada.Text_IO;
with Ada.Integer_Text_IO;

procedure Bullshit is
use Ada.Text_IO;
use Ada.Integer_Text_IO;
X : Integer;
begin
Put_Line ("Enter an integer: ");
Get (X);
Put_Line ("Wow, a" & Integer'Image (X));
exception
when Data_Error =>
Put_Line ("Hey asshole, enter a number!");
end Bullshit;



[file13@anatta tmp]$ ./bullshit
Enter an integer:
piss off
Hey asshole, enter a number!
[file13@anatta tmp]$


:P back at ya! ;)

my languages dick is bigger then yours!.... :D

[sans-hubris]

Yeah, Ada is one of those funny languages that is extremely dependant on the correct type. One person that I met that really liked Ada said that 80% of all software bugs would disappear if everyone used Ada. Ada doesn't really need much of a debugger really. I'm not sure about that, but its strong typing is a good reason to check it out. Also, many real-time applications make use of Ada to help cut down on bugs.

[file13]

yeah strong typing does alleviate many errors that would get by in many popular languages--ML is like Ada in this respect. but beyond just strong type checking, built in realtime, and threads, the Ada compilation system and package scheme is so nice. Ada pretty much makes you do it a certain way so the compilation system can do it's magic. sure Ada can be boring and sometimes annoying. i personally consider it a non-frills language--no fancy tricks like Lisp. but anytime i've gone with Ada it's always been a reletavily painless development process.

but back to the topic, even though Ada does not have a predefined GC, it still does not relay on dynamic memory and pointers as much as C/C++ which tremendously cuts down on the need for a debugger. hell, even when you use Ada pointers--called access types--again, they are types which can't normally be coerced into wild casts and abused like in C/C++. Ada will let you, but you basically have to use Unchecked_Conversion which is a big sign that says, "yes i really want to point the gun at my foot and pull the trigger."

so i have to side with Jimfinch in that debuggers become less important the high level the language. the most unfotunate thing about C++ is it's fragile C compatability. it tries to be a safe language but fails simply because of C.

[stuka]

Originally posted by file13
the most unfotunate thing about C++ is it's fragile C compatability. it tries to be a safe language but fails simply because of C.
Actually, C++ doesn't try to be a safe language. It offers facilities for programmers to program safely, but also allows programmers to behave in a dangerous fashion if they choose. Proper use of static_cast, reinterpret_cast, and dynamic_cast provide safety like the Unchecked_Conversion capability, so anyone who wants to program in a safe fashion is more than capable of doing so. I personally don't consider it a language flaw when programmers don't use the language properly - that's like blaming a chainsaw for cutting your fingers off if you use it to trim your nails.

[bwkaz]

Blaming a chainsaw for cutting off your fingers when you use it to trim your nails, IMHO, would be more like blaming C++ for screwing up when you could have just gone with a very simple script instead. Like blaming it for trashing memory when you were writing a program to recursively list directories -- find works wonders for something simple like that. In other words, I think your analogy also has an element of overkill in it.

IMHO, an analogy like "blaming the gun when you shoot yourself in the foot", or "blaming (computers/the Internet) for the activities of crackers" would be a bit better...

But of course, that's all semantics anyway, and the analogy is otherwise completely valid. ;)

[file13]

C/C++ are guns without safety's. what if you we're carying your Ruger and slipped on a rock and shot your finger off because there wasen't a safety. sure you can blame yourself, but if the gun was designed better you wouldn't have that probelm unless you turned the safety off. that's the fundementaly problem of C++, it's poorly designed and implemented. with C/C++ you don't have a safety; you just have to be really careful.

first note, Ada's unchecked_conversion is NOT the same as C++'s new cast's.


#include <iostream>
using namespace std;

int main(void) {
void *x;
int y = 666;
x = &y;
cout << "This is dangerous: x = "
<< *(int*)(x) << endl;
}


Ada has no such thing and therefore no such problems. in fact C++ shouldn't need a void pointer at all since templates (which BTW came from Ada) largely solve the need to use void pointers in libs--in C it's fairly common to use void pointers for abstract data types that need to be generic. but it does because it wants to be compatable with C. and yes C++ does try to be a safer C which is why it is picker then C when it comes to types and it also borrowed exceptions from Ada which i think most hackers would agree are for safety. constructors were designed so people wouln't forget to initialze stuff--a seaftey issue. ditto for destructors. the list goes on and on. C++ only draws the line on safety when the possibility of slowing down code would get in the way--thus no run time checks.

also, yes i do blame C/C++ for insecurity. we simply would NOT have as many software holes if C/C++ were not the dominate languages. you would still have security holes based on things like race conditions, but the biggest most dangerous holes, buffer overflows simply do not exists in languages not written on top of high level assembler.

fact: humans hack.
fact: humans make mistakes while hacking.

now, wouldn't you rather have a language that helps you minimize your inherent flaws then one that let's you blow your foot off?

the problem is most hackers think they are infallable. "it was the coders fault." sure it was, but if the language was designed to help the fallable human errors would be minimized. if the gun had a safety there would be fewer misfires.

don't get me wrong, there is a need fo a low-level language like C. but C++ is another story. it was a good idea that went terribly wrong.

i encourage you to learn a strongly staticlly typed language like Ocaml are Ada so you can see the difference. given, languages don't have to be staticly or strongly typed to be safe (Lisp is a good example of a safe dynamically typed language), but they are the most explicit on making sure that apples are not oranges and vice versa.


#include <iostream>
using namespace std;

int main(void) {
enum apple {Red, Green};
enum orange {Navel, Flordia};
apple a = Red;
orange o = Navel;
if(a == 0 && o == 0)
cout << "What happened to type checking!??" << endl;
}


try that in C++. then try to even compile this in Ada:


with Ada.Text_IO;

procedure Main is
use Ada.Text_IO;
type Apple is (Red, Green);
type Orange is (Navel, Flordia);
A : Apple := Red;
O : Orange := Navel;
begin
if A = 0 and then O = 0 then
Put_Line ("What happened to type checking!??");
end if;
end Main;


;)

[stuka]

Actually, you NEVER used C++'s new casts. (int*) is an old, unsafe, C cast. static_cast<int*>, dynamic_cast<int*>, and reinterpret_cast<int*> are the C++ casts. C++ has a void pointer because (until the new C99 standard at least) any valid C code would compile with a C++ compiler - which is actually a way to improve the safety of C, not to degrade the safety of C++. Buffer overflows don't occur in ANY well written code, no matter WHO wrote it. As far as I'm concerned, a buffer overflow that raises an uncaught exception in Java is just as bad an error as a buffer overflow in C/C++ that smashes the stack. Your enum example is also exploiting the fact that C++ is backward compatible to claim that it is unsafe - if a programmer is writing C++ code, they SHOULDN'T use that condition. Yes, they CAN, but just because I CAN whizz on the electric fence doesn't mean I SHOULD. Writing "safe" code in C++ is not that hard - it's purely laziness or ignorance that prevent it. Personally, I don't think a computer language should waste run-time resources on checking inputs - that's what the programmer is THERE for! If someone's not bright enough to check input, the program deserves to die. C++ is another story. it was a good idea that went terribly wrong.Now THAT just tears it - C++ is an impressive improvement over C in so many ways that it's not even funny. C++ could completely replace C, and noone would really miss it. Why? Because C code WOULD STILL COMPILE, AND BE SAFER. C++ also provides support for generic and OO programming, which make it SAFER than the same tasks in C. Anyone who values "safety" in a language, but claims that C is better than C++, confuses the CRAP outta me!

[jemfinch]

Originally posted by file13
yup!


You seem to have missed the irony, file13. All errors are caught at either runtime or compile time. There is no other "time" in which to catch them.



procedure Bullshit is

type Holy_Languages is (Ada, Lisp, Ml);
type Unholy_Languages is (C, C_Plus_Plus, Java);

Holy : Holy_Languages;
Unholy : Unholy_Languages;

begin
Holy := Lisp;
Unholy := C;
Holy := Unholy;
end Bullshit;


-----XEmacs: bullshit.adb (Ada Font)----All------------------------------------------------------------------------------
cd /home/file13/tmp/
gnatmake bullshit
gnatgcc -c bullshit.adb
bullshit.adb:15:12: expected type "Holy_Languages" defined at line 6
bullshit.adb:15:12: found type "Unholy_Languages" defined at line 7
gnatmake: "bullshit.adb" compilation error

Compilation exited abnormally with code 4 at Tue Nov 19 15:40:21


kinda like Ocaml with useful error messages!


And a whole lot more typing. You'd get the same useful type error messages in ML if you explicitly typed all your variables, but the beauty of ML is that you don't have to.



with Ada.Text_IO;
with Ada.Integer_Text_IO;

procedure Bullshit is
use Ada.Text_IO;
use Ada.Integer_Text_IO;
X : Integer;
begin
Put_Line ("Enter an integer: ");
Get (X);
Put_Line ("Wow, a" & Integer'Image (X));
end Bullshit;



[file13@anatta tmp]$ ./bullshit
Enter a integer:
2
Wow, a 2
[file13@anatta tmp]$ ./bullshit
Enter a integer:
fuck you!!!

raised ADA.IO_EXCEPTIONS.DATA_ERROR : a-tiinio.adb:91 instantiated at a-inteio.ads:20
[file13@anatta tmp]$



Is that supposed to be impressive? Is it supposed to be impressive that you can write a program that crashes because Ada lets you type-unsafely cast something input to an int?

Safety is having an Int.fromString function that returns an int option given a string; it either returns SOME int or NONE. Then the programmer takes cares of both cases and his program doesn't crash.

Again, should I be impressed that you can have runtime type errors in Ada?


and we need for good measure:


with Ada.Text_IO;
with Ada.Integer_Text_IO;

procedure Bullshit is
use Ada.Text_IO;
use Ada.Integer_Text_IO;
X : Integer;
begin
Put_Line ("Enter an integer: ");
Get (X);
Put_Line ("Wow, a" & Integer'Image (X));
exception
when Data_Error =>
Put_Line ("Hey asshole, enter a number!");
end Bullshit;



[file13@anatta tmp]$ ./bullshit
Enter an integer:
piss off
Hey asshole, enter a number!
[file13@anatta tmp]$



Such code is the reason I prefer SML to O'Caml. O'Caml also has an int_of_string function that raises an exception if the string isn't a valid representation of an integer. That's just one more place a program can fail with a runtime error. I much prefer SML's Int.fromString function which forces the programmer to handle the possiblity that the string isn't a valid representation of an integer, or it won't compile.


:P back at ya! ;)

:rolleyes:

Originally posted by sans-hubris:
its strong typing is a good reason to check it out..


Strict typing, not strong typing. Lisp, Scheme, Python, Ruby, etc. are all strongly typed, but they're not strictly typed. Strong typing is the opposite of weak typing (that is, weak typing allows you to easily and often circumvent the entire type system; strong typing doesn't). Dynamic typing (like Python, Lisp, Scheme, etc.) is the opposite of strict typing (like ML, Ada, Haskell, etc.)

Originally posted by file13:
my languages dick is bigger then yours!.... :D


Really? I can read Ancient Latin and Greek, in addition to being able to communicate fluently and with correct spelling and grammar in English.

Oh, you meant computer languages? Well, I doubt your assertion, but there isn't as easy a metric with which to measure that, now is there?

Jeremy

[file13]

Originally posted by Stuka
Actually, you NEVER used C++'s new casts. (int*) is an old, unsafe, C cast.

my point exactly. it's got all of C's flaws along for the ride....

[file13]

Originally posted by jemfinch
You seem to have missed the irony, file13. All errors are caught at either runtime or compile time. There is no other "time" in which to catch them.


DOH! i missed the humor. well i feel stupid now.... :beatup:


And a whole lot more typing. You'd get the same useful type error messages in ML if you explicitly typed all your variables, but the beauty of ML is that you don't have to.


hey, Perl is even less typing! Ocaml also gives you more options to write unreadable code. but i still perfer Lisp's dynamic typing if we're going there....


Is that supposed to be impressive? Is it supposed to be impressive that you can write a program that crashes because Ada lets you type-unsafely cast something input to an int?


this time you missed my humor.... ;)

and no, it's not unsafely casting. the error is caught in the input (Get), not the output. i simply did not feel like breaking out the Integer_Text_IO package so i used Integer'Image--it's equlivent to Ocaml's string_of_int. it's not a cast. a cast would look like this:


Put_Line ("Wow, a" & String (X));


but guess what? that won't compile do to it's strong typing....


Again, should I be impressed that you can have runtime type errors in Ada?


you're not a C/C++ hacker so no. but beyond that, it's the fact that you can catch them.


Such code is the reason I prefer SML to O'Caml. O'Caml also has an int_of_string function that raises an exception if the string isn't a valid representation of an integer. That's just one more place a program can fail with a runtime error. I much prefer SML's Int.fromString function which forces the programmer to handle the possiblity that the string isn't a valid representation of an integer, or it won't compile.


not sure what you're talking about in relation to the code. Ada's Integer'Image IS the same thing as Ocaml's string_of_int....


Really? I can read Ancient Latin and Greek, in addition to being able to communicate fluently and with correct spelling and grammar in English.


Podex Perfectus! :D

(i was in Eta Sigma Phi in college--dosen't that just piss you off?)


Oh, you meant computer languages? Well, I doubt your assertion, but there isn't as easy a metric with which to measure that, now is there?


we obviously don't have the same sense of humor...oh well, i still love you! ;)

[GnuVince]

jemfinch: the thing about O'Caml raising an exception, I'm not sure if I understand what you mean. What happens in SML if the user inputs something that is not a valid integer representation? Can you give code and compiler output?

[jemfinch]

GnuVince: int_of_string in O'Caml has the signature "string -> int" and raises an exception on failure. Int.fromString in SML has the signature "string -> int option" -- I'll let you figure out what exactly that means :)

Jeremy

[GnuVince]

I whipped this small sml_int_of_string function, Jeremy. Is it somewhat similar to what SML does?


let sml_int_of_string n =
try
Some (int_of_string n)
with _ -> None;;



And as a note related to the safety discussion, I think (or at least hope) that in the near future, more language will take example from ML, Ada, Haskell and other strictly typed language, where as many programming errors can be caught at compile time. From what I can understand, Jeremy says that the SML coder must handle cases when a user being prompted for an integer inputs something invalid. If he forgets, the compiler reminds him, while in O'Caml, the compiler will not warn you when you forget to check for exceptions. In this respect, I think that SML beats other languages I know hands down. But the language doesn't matter: if it helps bring programming to an even greater level of safety, it's all good for users and coders in the end.

[jemfinch]

Originally posted by GnuVince
I whipped this small sml_int_of_string function, Jeremy. Is it somewhat similar to what SML does?


let sml_int_of_string n =
try
Some (int_of_string n)
with _ -> None;;



Yeah, that's what it does. Except it's far more efficient to implement O'Caml's exception-raising int_of_string from something like SML's Int.fromString function than it is to implement SML's Int.fromString function with O'Caml's int_of_string function. Exceptions are expensive; Int Options aren't.


But the language doesn't matter: if it helps bring programming to an even greater level of safety, it's all good for users and coders in the end.

Not so fast; it's always a tradeoff. Carrying around opaque (that is, unmodifyable by the programmer) dynamic type tags for every value does make programming safer (even in languages that are statically typed); that's one of the reasons remote object protocols are so much easier/better/safer in languages like Erlang and Python and Java than they are in statically typed languages. And some things just aren't worth the safety; for instance, ML compilers could statically type the length of arrays, but they don't (unless you explicitly tell them to; search the internet for the way in which that's done for some interesting stuff about the Hindley-Milner typesystem) because that's no useful in most cases.

Safety is good; what you're talking about (with static typesystems) is compile time safety. That's what's debatable :)

Jeremy

[file13]

Originally posted by GnuVince
From what I can understand, Jeremy says that the SML coder must handle cases when a user being prompted for an integer inputs something invalid. If he forgets, the compiler reminds him, while in O'Caml, the compiler will not warn you when you forget to check for exceptions. In this respect, I think that SML beats other languages I know hands down.


i'm ignorant of SML, but just to let you know, Java forces you to catch exceptions at compile time:


import java.io.*;

class Tester {

public static void main(String[] args) {
BufferedReader stdin =
new BufferedReader(new InputStreamReader(System.in));
System.out.print("Enter name:");
String name = "";
name = stdin.readLine();
System.out.println("Hello " + name + "!");
}
}

--1-:---F1 Tester.java (Java Abbrev)--L14--All-------------------------------------------------------------------------
cd /home/file13/code/java/
javac Tester.java
Tester.java:10: unreported exception java.io.IOException; must be caught or declared to be thrown
name = stdin.readLine();
^
1 error

Compilation exited abnormally with code 1 at Thu Nov 21 09:01:59


you'd have to add the exception before it let's you:


import java.io.*;

class Tester {

public static void main(String[] args) {
BufferedReader stdin =
new BufferedReader(new InputStreamReader(System.in));
System.out.print("Enter name:");
String name = "";
try {
name = stdin.readLine();
}
catch (IOException e) {
System.out.println("Hello " + name + "!");
}
}
}


:)

[GnuVince]

Is this something we could suggest to ocaml-dev?

[stuka]

file13: not quite - if I claim my method throws that exception, I don't have to catch it (though I'm not sure if your main can throw exceptions legally - but I know it works in other functions).

[jemfinch]

And on another count of not-quiteness, file13, you don't have to do any declarations for RuntimeException (or exceptions deriving from it); so many (most?) Java programmers just derive all their exceptions from that.

GnuVince: It's not something that would be worth mentioning on Ocaml-dev. SML has been around longer than O'Caml, and option types even longer than that; in all honesty, it's probably another case where the O'Caml developers made their language different just to be different. As with most of the cases where O'Caml is different apparently only to be different from SML, it's a difference that makes the language worse, not better.

Jeremy

[file13]

Originally posted by Stuka
file13: not quite - if I claim my method throws that exception, I don't have to catch it (though I'm not sure if your main can throw exceptions legally - but I know it works in other functions).

true, you can do:


public static void main(String[] args) throws IOException {...


i guess i should have said "acknowledge" the fact that exceptions could arise. thanks for clairfying that.

[file13]

Originally posted by jemfinch
And on another count of not-quiteness, file13, you don't have to do any declarations for RuntimeException (or exceptions deriving from it); so many (most?) Java programmers just derive all their exceptions from that.


yeah, but the reason people do that is to avoid all the nagging for not catching OR declaring (:D) exceptions. it's a (bad) way around it, but it still does force them to acknowledge errors. i didn't say it was that great, i was just mentioning it to Vince that Java is a language that i'm aware of that has something similar to what it sounds like SML has; basically that it has the concept of forcing the hacker to do something with the possibility of the error. again i don't know SML so i don't know if this is similar. but it sounded to me like what Vince was getting at....


As with most of the cases where O'Caml is different apparently only to be different from SML, it's a difference that makes the language worse, not better.


you think it's because they're French? ;)