Re: GoTo in Java

Good response, Michael.

Some quick comments below...

"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:dr8b22014ad@xxxxxxxxxxxxxxxxxxxx
>
> In article <43m8tiF1og6p9U1@xxxxxxxxxxxxxx>, "Pete Dashwood"
> <dashwood@xxxxxxxxxxxxxx> writes:
>> "Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
>> news:dr2ofd014s3@xxxxxxxxxxxxxxxxxxxx
>> >

<snip>

> 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 agree it would be unreasonable to expect a switch.(Certainly not until you
were a year or two down the track and everybody was very happy with OCaml.
At that time the consensus would probably be for converting existing code as
when time allowed.) I didn't that conversion should be suggested.


<snip>>
> 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.

Agreed and understood.
>
> - 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.
>
Not SUCH a big problem... it is open source.

> - 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.

That is true irrespective of which language you use. I wasn't suggesting
re-implementation or conversion.
>
> - 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.

Funny you should say that... yesterday one of my development team (they are
all J2EE people) came across an article I wrote some years back explaining
COBOL as a scripting language for .NET .
(http://authors.aspalliance.com/aldotnet/examples/coboldotnet.aspx)

He had never seen COBOL source and was a little embarrassed because he
hadn't. We went through the code in the example above and he was really
interested and expressed some amazement that COBOL could do these things or
that OO COBOL even existed. He easily understood the code and was surprised
how simple it was. If I had suggested all future development was to be in OO
COBOL, I don't think he would have objected :-)

Compare this with COBOL programmers discussing Java... :-)

This forum is becoming much more civilized in this regard as people come to
the realization that Java isn't going to go away, and extend their skill
sets. (As I have been begging people to do here for at least 6 years
now...). But there was a time when to suggest that anything other than COBOL
should be considered as a tool for the job, resulted in scorn and
villification. (A bit like my suggestion 7 years ago that people should drop
the COBOL file system in favour of SQL... now they take it as read. I
smile.)

I've been a voice crying in the wilderness for components, for some years
now, and there are starting to be some other voices and echoes... :-) It is
too late for OO COBOL and COBOL in general (OO COBOL might have saved it;
no-one was interested) , but I believe today's programmers are interested in
programming art (rather than evangelists for any given language) and will
happily learn a new language, so acceptance of OCaml may not be as difficult
as you think.
>
> 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.

Yes, that is true. But they are also driven by their CVs and the more
mnemonics on it, the better... :-)
>
> 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.
>
Yes, there is no point in browbeating people. The case has to stand on it's
own merits. From what you have described here, it certainly looks as though
it might.

>> 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.
>
Do it one-on-one. Show people who are interested, some OCaml code. Let them
reach for more information, and suggest a pilot study.

I was working in Germany when ADA was first developed. One guy in our shop
was really interested and never missed a chance to extol the virtues of ADA.
He believed in it passionately but overdid it. Most of us just avoided
him....:-) Yet, in retrospect, I think it was our loss.

>> 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.
>
That is exactly what I was suggesting. Once people get to know it and become
facile with it, it is very likely that someone will suggest some conversion
of existing code...

> I may try to put together a group to try this out at the next big
> developer meeting.
>
Good for you!

>> 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. :-)
>
OK. I'm glad that isn't the problem... :-)

> 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.
>
Interesting... I can learn something here. I never feel encouraged when my
ideas get turned down; I just feel devastated :-) Fortunately, it doesn't
happen very often, mainly because I am very careful which ideas I make
public :-). Seriously, I think it is great that you can be positive about
it. I'll give this more thought with a view to improving my own attitude...

>> 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.
>
Good luck with the OCaml and let us know if anything happens.

Pete.
> --
> 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: Compiler and an interpreter
    ... >> coded in that having to learn a new language isn't significant. ... > Most programmers don't see it that way though, ... OCaml programs that generate C code... ... virtual ~Scene(); ...
    (comp.programming)
  • Re: references about the beauty of functional programming ?
    ... I have no experience using OCaml in either small or large projects ... (except for installing it in order to use the Felix language.) ... Replacing OCaml with Erlang, I wholeheartedly agree. ... Many of the Erlang programmers I work with are ex C++ programmers, ...
    (comp.lang.functional)
  • Re: Infinite Loops and Explicit Exits
    ... but C programmers know not to do it that way. ... not what Cobol programmers want. ... null-terminated memory format is unsuited to storage in a file. ... What kind of programming language doesn't natively support ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... like RDB, for the same reason. ... COBOL was left behind. ... businesses to keep their old language, or to go to a new language: ... they have mainframe programmers and web programmers. ...
    (comp.lang.cobol)
  • Re: 7E7 Flight Controls Electronics
    ... Cobol hit the world at a time when the only other programming language ... Ada, OTOH tried to address the needs of embedded systems programmers and ... that embedded programmers already had something - C - which was cheap ...
    (comp.lang.ada)