 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf
Interesting.
If nothing else, look at the statistics slide near the very end of the
presentation for a giggle.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
>
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf
I learned today that OS/2 is still being used in some ATM's and other
legacy systems.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/23/2011 10:40, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>>
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf
>
> I learned today that OS/2 is still being used in some ATM's and other
> legacy systems.
>
Was there a connection there, or just "this too is interesting"? :-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> On 7/23/2011 10:40, Warp wrote:
> > Darren New<dne### [at] sanrrcom> wrote:
> >>
http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf
> >
> > I learned today that OS/2 is still being used in some ATM's and other
> > legacy systems.
> >
> Was there a connection there, or just "this too is interesting"? :-)
No connection (except that both are related to computers and fringe
systems). It was just another random fact that came to mind.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/07/2011 06:37 PM, Darren New wrote:
> Interesting.
I'm ticked by "C++ crashes a lot if it's immature".
What, if C++ is immature? Or the C++ codebase is immature? Or perhaps
you mean if the C++ developers are immature? ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/24/2011 3:38, Orchid XP v8 wrote:
> On 23/07/2011 06:37 PM, Darren New wrote:
>
>> Interesting.
>
> I'm ticked by "C++ crashes a lot if it's immature".
>
> What, if C++ is immature? Or the C++ codebase is immature? Or perhaps you
> mean if the C++ developers are immature? ;-)
I think they meant your code crashes a lot if it's written in C++ and hasn't
had lots of debugging.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> On 7/24/2011 3:38, Orchid XP v8 wrote:
> > On 23/07/2011 06:37 PM, Darren New wrote:
> >
> >> Interesting.
> >
> > I'm ticked by "C++ crashes a lot if it's immature".
> >
> > What, if C++ is immature? Or the C++ codebase is immature? Or perhaps you
> > mean if the C++ developers are immature? ;-)
> I think they meant your code crashes a lot if it's written in C++ and hasn't
> had lots of debugging.
I think it depends a lot on the competence of the C++ programmer(s).
Granted, becoming a very competent C++ programmer (whose code seldom crashes,
or if it does, the crashes get caught very early on the development cycle)
may require more work than with some other languages, but it's not impossible.
Of course with C++ (and C and other C-compatible languages) the rare
circumstance where you get a nightmarish bug can be pretty fun. By
"nightmarish" I'm talking about the random crashes that happen sometimes
but not always (so that it's very difficult and laborious to get the program
to crash on purpose), where the debugger is of no help whatsoever even if
you are running in full debug mode (you either get no stack trace whatsoever,
or the stack trace is completely unhelpful because the crash happens
somewhere in the main runloop rather than in your code), where no debugging
tool is reporting any error (ie. no memory leaks, no zombie objects, no
misuse of STL, nothing), and the system does not have nor support tools like
valgrind. And you have no idea whatsoever which line from the tens of
thousands of lines of code is causing the problem (and that's if you are
lucky and it's just a bug in one line somewhere, rather than it being some
really hard to find combination of conflicts).
I wonder if something similar ever happens with the "safer" programming
languages (eg. you get a "null pointer exception" or some other similar
error and have absolutely no idea why, and no debugging tool is helping).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I think they meant your code crashes a lot if it's written in C++ and hasn't
>> had lots of debugging.
>
> I think it depends a lot on the competence of the C++ programmer(s).
I imagine it also varies considerably depending on how complicated
whatever you're trying to implement is.
By the looks of it, these guys were trying to implement stuff like
routing, statistics, license management, encryption, distributed lookup,
and probably complex business rules as well, all in C++, while their
servers get hammered by customers of tier-1 game titles. I'd imagine
that kinda thing isn't fun.
> Granted, becoming a very competent C++ programmer
> may require more work than with some other languages, but it's not impossible.
I'd presume [although I could of course be wrong] that a company that
develops exclusively in C++ would go out of their way to hire only the best.
> Of course with C++ (and C and other C-compatible languages) the rare
> circumstance where you get a nightmarish bug can be pretty fun.
Yeah, gotta love bugs that move around depending on what compiler flags
you set or which version of some 3rd party library you link to. (E.g.,
anything involving broken pointer arithmetic usually ends up causing
random behaviour that varies depending on the exact compilation details.)
> I wonder if something similar ever happens with the "safer" programming
> languages (eg. you get a "null pointer exception" or some other similar
> error and have absolutely no idea why, and no debugging tool is helping).
In Java, accessing a null pointer would throw an exception, which (if
nothing else) will dump a stack trace to stderr.
In Haskell, accessing a null pointer would... be quite impressive,
actually. Given that the core language itself has no notion of "pointer"
nor what it means to be "null".
Probably the closest equivalent is the "head []" error. If some function
was expecting a list of data, but at runtime that list happens to be
empty, then the program prints "head []" to stderr and halts. [Unless
you wrote some exception handling code, of course.]
Good luck figuring out where in the entire program the problem actually
resides. What's that? Bracket the problem parts with print statements?
Ah, but perhaps you're forgetting; Haskell does not execute code in the
order written, and printing is only permitted from the IO monad.
Yes, there /is/ a debugger. No, it will /not/ give you a stack trace.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> > I wonder if something similar ever happens with the "safer" programming
> > languages (eg. you get a "null pointer exception" or some other similar
> > error and have absolutely no idea why, and no debugging tool is helping).
> In Java, accessing a null pointer would throw an exception, which (if
> nothing else) will dump a stack trace to stderr.
But if the null pointer is accessed in the depths of some obscure system
library which gets called by the main runloop of the program (rather than
being directly called by your code), you might end up in a situation where
the stack trace is completely unhelpful and you have no idea whatsoever
where that null pointer is coming from in your code (which might happen if
you are not using that precise system library directly, but it's a library
used by a library used by a library which you are using, but you don't know
what this chain might be, as the implementation of the library you are using
is hidden behind its public interface).
> In Haskell, accessing a null pointer would... be quite impressive,
> actually. Given that the core language itself has no notion of "pointer"
> nor what it means to be "null".
Well, I did say "or some other similar error".
> Probably the closest equivalent is the "head []" error. If some function
> was expecting a list of data, but at runtime that list happens to be
> empty, then the program prints "head []" to stderr and halts. [Unless
> you wrote some exception handling code, of course.]
> Good luck figuring out where in the entire program the problem actually
> resides. What's that? Bracket the problem parts with print statements?
> Ah, but perhaps you're forgetting; Haskell does not execute code in the
> order written, and printing is only permitted from the IO monad.
> Yes, there /is/ a debugger. No, it will /not/ give you a stack trace.
So how is that problem usually solved? "Just review the entirety of your
code and try to find the bug"?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> In Java, accessing a null pointer would throw an exception, which (if
>> nothing else) will dump a stack trace to stderr.
>
> But [...] you might end up in a situation where
> the stack trace is completely unhelpful and you have no idea whatsoever
> where that null pointer is coming from in your code.
Yes. I hate it when that happens. While accessing a pointer without
checking whether it's null is arguably a bug, knowing where this happens
often tells you nothing about how the heck the pointer came to *be* null
in the first place - and /that/ is usually the real bug.
I gather people use step debuggers and the like to hunt down such
things. Let's just hope the null pointer isn't because of some cruel
concurrent thread interaction. (There's a /reason/ why most people avoid
concurrency.)
>> In Haskell, accessing a null pointer would... be quite impressive,
>> actually. Given that the core language itself has no notion of "pointer"
>> nor what it means to be "null".
>
> Well, I did say "or some other similar error".
Sure. I was just pointing out that an entire class of very nasty bugs
completely fails to exist, and hence never needs to be debugged. Which
is a big win. However...
>> Probably the closest equivalent is the "head []" error.
...it's not the solution to everything.
>> Yes, there /is/ a debugger. No, it will /not/ give you a stack trace.
>
> So how is that problem usually solved? "Just review the entirety of your
> code and try to find the bug"?
It would be nice if that wasn't the actual answer, wouldn't it?
I should point out that the error message is actually telling you what
function threw an exception. In this case, the "head" function threw an
exception because it was given an empty list as input. So you only need
to look at places in your code that call "head".
Good coding practise dictates that if you call "head", you should check
the list isn't empty first, and throw your own more-specific exception
if the list /is/ empty somehow. (E.g., if a dictionary lookup uses a
list internally somehow, it should throw an exception like "lookup: key
not found" rather than just "head []".)
Still, this is one of the more frustrating things about Haskell. It's
somewhat offset by the fact that we have a REPL, and you really can run
most pure functions without having to initialise a whole bunch of stuff
in a certain order. (I.e., you /can/ easily test isolated functions.)
Even so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
