Re: GoTo in Java


In article <43m8tiF1og6p9U1@xxxxxxxxxxxxxx>, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> writes:
> "Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
> news:dr2ofd014s3@xxxxxxxxxxxxxxxxxxxx
> >
> > (I'd love
> > to drop all the C and C++ we use here in favor of OCaml. I bet we'd
> > reduce the bug rate by an order of magnitude, at least. It'll never
> > happen.)
>
> You are an experienced and highly competent member of a prestigious team. If
> you really believe what you have written, why not prepare a case showing
> what you expect the benefits would be and why you believe so?
>
> I never heard of OCaml until I saw your posts, but I have enough respect for
> your past postings to recognize that you are worth listening to. If I can
> deduce that from occasionally browsing a newsgroup, why would the people who
> work with you and manage you every day, not also be interested to hear your
> opinion?

This is a good and interesting question (at least IMO), and worth a
serious answer. So this is a rather long post (and I certainly won't
be offended if people don't feel obliged to read all of it).


There are a number of factors that I think would prevent Micro Focus,
or even just one of the development groups here, from making this
sort of major switch. I think most organizations would find many of
them apply, so this doesn't reflect poorly on MF, in my opinion; it's
a pervasive situation. There are development teams with the
flexibility to switch languages, and I've seen anecdotes of that
happening successfully, but it's the exception rather than the rule.

Some of those factors are largely objective, and some are largely
subjective, but most have elements of both.

Here are some of the major ones:

- Schedules. While I do believe that it's very probable that a
language switch would pay off in faster development (due in part to
less time spent in debugging) in the long run, it has a very large
up-front time cost in retraining staff and reimplementing existing
functionality. Some of that can be amortized by using a phased
approach, but only to some extent - changing languages has to be
done in fairly large "chunks".

We can't just interrupt our development and release schedules for
months; customers are waiting for enhancements and fixes, and the
market moves along whether we do or not.

- Platforms. MF has to support a lot of platforms, some because of
their importance in the market and some for contractual reasons. To
move to a new language, we have to get an implementation of it for
every platform where we will be using it (so for every platform
where the rewritten components will be used) and verify that that
implementation is reliable. That can be surprisingly difficult, even
with, say, the free open-source OCaml compilers.

An anecdote: for some components, we are still obliged to support
platforms which don't have a standard-conforming C implementation.
The C standard is 16 years old, and we can't even rely on *it* being
available everywhere we want it.

- Stability. I'm sure we're all familiar (many through first-hand
experience) with what typically happens when a large code base is
reimplemented: the new implementation fails to capture some subtleties
of the behavior of the old one. Sometimes those are just bugs in the
new implementation. Sometimes they're bugs in the *old* implementa-
tion, but ones that existing software actually depends on. Sometimes
they're undocumented features that somehow leaked out to a customer
or two, or they're quirks that were officially undefined but which
someone decided to rely on.

That means a new implementation needs a lot of testing, and even so
it's going to cause some customers some grief. Again, in the long
run, you'll have a better product for your customers, but in the
short some of them are not going to be happy.

- Resistance. Programmers are an opinionated bunch. While software
development is (let's be honest) a cushy job - I'll certainly take it
over subsistence farming or sweatshop labor - we do put a lot of
ourselves into our work, and it's work that demands both attention to
detail and a measure of creativity. And people who spend a lot of
time using complex tools to create things will have strong opinions
about those tools.

Making a case for switching to OCaml would require not only making
the business case but convincing developers that OCaml is palatable.
But it's unlikely to be to everyone's taste. After all, programmers
generally do manage to self-select the languages they want to work
with, to some extent, particularly in a relatively large and
heterogeneous organization like MF. People who want to write COBOL
will gravitate into positions where they mostly write COBOL; the
Java fans tend to end up in groups that use a lot of Java; and so
forth.

The C and C++ developers at MF are mostly people who have some
affection for C and C++ and the ways those languages are usually
applied. OCaml encourages a rather different problem-solving
approach and uses a very different syntax. I think most of the C and
C++ developers here could learn to like OCaml, because they're smart
folks who will see its possibilities, and because it's interesting,
and because they're professionals who care about their craft and
doing a good job. But there would be resistance which would have to
be overcome gradually, with diplomacy and solid arguments. And
that's good, because you want new ideas vetted by people who know
something about them; but it takes time and it takes social capital,
which like anything else is a finite resource. Pushing a language
change through without convincing its users would be a Pyrrhic
victory at best.

> I believe you may be abandoning the field before a shot is fired. You
> believe you can't win, and there are certainly factors (like the
> "unknownness" of the language) working against you, but if the benefits are
> real, they represent real cost savings and management is duty bound to at
> least hear your case.

Yes, and I think they would; we have a very responsive management
structure here. (In fact, it's one of the major benefits to working
for the "new" MF.) But they'd have to weigh the short-term cost
against the long-term benefit. And I don't think convincing
management is even the harder part of making this sort of radical
change - it's getting agreement (what the business types call "buy-in")
from staff.

> If OCaml can be easily "acquired" by existing
> programmers and if it provides the benefits you believe it does, then why
> not suggest a pilot study?

I've mulled that idea over for a while. It may well be worth doing
when a suitable project comes along. I still don't believe that we'll
ever be able to gather the kind of resources (most particularly time)
to actually convert all, or even most, of our existing C codebase, but
it might be possible to introduce OCaml (or something else) as an
alternative for new development, and gain some of the benefit.

I may try to put together a group to try this out at the next big
developer meeting.

> It seems a pity to me that someone as useful as yourself would not have the
> confidence to try and improve things where you believe they honestly could
> be inproved.

Oh, I've made plenty of suggestions for (what I believe would be)
improvement over the years. No one at MF has ever accused me of not
speaking my mind, that I can recall. :-)

Some have been quite successful, others less so, but again I think
that's appropriate for a large group of smart people who are all
thinking about how to do their jobs. It can actually be quite
encouraging sometimes to have one of my ideas turned down, because
it's generally the result of some quite thoughtful discussion.

> I bet you wouldn't hesitate to rewrite or redesign bad code or
> architecture you came across...:-).

Well, we do have rules about code ownership and so forth, of course,
and tact is important to maintain a healthy work environment - and I
do try to remember that I've been wrong plenty of times. But yes,
when something bothers me I try to see it resolved.

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_
.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... Jon Harrop said: ... You're incorrectly assuming that older languages have necessarily had ... Have you looked as hard for bugs in OCaml as you have in g++? ...
    (comp.programming)
  • Re: Lisp and OCaml, why?
    ... > interpreted languages as possible over time, if not to use them at ... > lisp and OCaml though - why would someone use them in preference to ... Strong, static typing catches type errors at compile time, reducing ...
    (comp.programming)
  • Re: Compiler and an interpreter
    ... > OCaml is more general and can be reused. ... >> choose between languages. ... since elsewhere you talk about efficiency?) ... For really complicate formulae, OCaml will be relatively ...
    (comp.programming)
  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... the model-view-controller design pattern. ... Then you can use pattern matching to manipulate ...
    (comp.object)
  • Re: C / C++ skills
    ... but the pitfalls of so called safe languages are not that different. ... The only way to be sure of the absence of bugs is to design software to ... the odd operator precedence of C, tripping up new programmers. ... But yeah, a well-worded coding standard, and a culture that cares about it ...
    (comp.arch.embedded)