In article <1149590709.940712.268140@h76g2000cwa.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:
> Paul Schlyter wrote:
>
>> That's the way to go if you want to integrate a piece of old code in a new,
>> larger, application of course. But I was more thinking of code which shouldn't
>> be expanded but merely moved to a new platform and there behave as it did
>> on the old platform. It doesn't seem particularly productive to wrap your
>> old C code into a Java wrapper which does nothing but executes that old C code...
>
> Indeed. If you have a large application that's already written to a
> standard that allows it to be portable, you keep maintaining it until
> end of life. Unless the language it's written in becomes end of life
> first :-)
If the application is important, and if it's too expensive to port to
a new environment, it would be feasible to maintain an old environment
(either physically or through emulation) just to be able to run that
application.
> My concern is the manner in which small libraries or copy/paste chunks
> of code pollute the relatively portable space of newer languages. In
> .NET, you can issue a keyword and switch into old-school mode. It
> doesn't exactly provide an environment that encourages good design. Why
> you would include features that good developers won't use is beyond me,
> unless of course it's lousy developers you're catering to, which may
> well be the point.
The point isn't whether the developers are lousy or good - the point
(to the management) is whether one can get the product out the door
more quickly. Pasting old code in old-school mode is often quicker
than reimplementing the old code in new-school mode. That's what
matters in a commercial situation: to meet the deadline - a deadline
which often is quite tight because your company won the contract over
its competitors. Basically it's about promising amost more than you
can keep later.
>> I suppose you mean "the commercial world" when you say "the real
>> world". Yes, the commerical world is a continuous hectic race where
>> there's not really any time to do solid work. It's more important
>> that the product is flashy and that it appears early. Buggy? Of
>> course, but so what? Let customer support take care of the
>> complaining customers while we're developing the next product to
>> appear early and being flashier still .... the lifetime of a software
>> product is nowadays so short anyway.....
>
> It's actually irrelevant what sector we speak of - productivity
> enhancements are productivity enhancements. While there are sectors
> where you can 'afford' the extra time investment required to develop in
> legacy languages, there's little reason to do so.
>
>> In such an environment it's probably best to throw away old code and
>> let everyone reinvent their wheels once more .... with humps and bumps
>> that there's no time to polish away.
>
> In this case, the old wheel has humps and bumps with regards to
> portability and security. Should we throw those away? Absolutely.
>
>>> This is the real world effect of Microsofts design decision (pollute
>>> the new language with old problems) versus the Java model. Still
>>> hobbling with legacy for no reason whatsoever than a couple of very
>>> poorly concieved design ideas. And ones that history has already shown
>>> has a simple, clean solution.
>>>
>>> "Those who cannot learn from history are doomed to repeat it...."
>>
>> Actually, there are lots of people who do this, for their enjoyment.
>> I'm referring to vintage computing of course, and this very newsgroup is
>> part of that movement.
>>
>> Yep, it belongs to "the real world" too....
>
> Of course, but when your platform isn't evolving you don't need
> evolving development methodologies. The older techniques are adequate,
> and in the case of the Apple II, a great deal of fun on such a
> constrained environment. However, old techniques only scale so high,
> and hit those limits. In the case of C/C++, those limits have been hit,
> or close to it. There's still a large problem domain you use these
> tools for, as it's the most appropriate. But many new problem domains
> demand tools that have less restrictions, particularly in terms of
> development time. Sometimes this involves using a slightly more
> constrained language. Less is more!
>
>> If C/C++ macros should be made aware of namespaces, should they also be
>> made aware of other parts of the underlying langauge? If so, which
>> parts? I think you'll have a can of worms there if you open that one....
>
> This is precisely why it is advocated that constants, plus language
> constructs be used for conditional compilation.
Then you'll have to choose a language which indeed supports conditional
compilation, and which e.g. doesn't enforce correct syntax on those pieces
which shouldn't be compiled at that time. In C and C++ you'll need
the preprocessor for this. In Java, your only option is regular if statements.
>> Only if you're sloppy about your macro definitions. If the macro is to
>> have effect in only one source file, then you'll of course define it
>> *after* all your #include's. But what if that macro had been defined
>> somewhere else already? The compiler will immediately complain so you'll
>> notice it soon enough - it can be handled in this way:
>
> Sure. Eventually you reach the point where the manual on good coding
> convention and style is larger than the language specification. At that
> point, it's time to rethink, and use more appropriate tools.
>
>> Unfortunately, Ruby interpreters aren't particularly common in web browsers.. :-)
>
> Yeah, and Java VM's as well :-(
>
>> Are you trying to say one can do something in C that cannot be done in C++ ? :-)
>
> :-) No, just that C++ style OO is 'broken'
C++ isn't a pure OO langauge, and it never pretended to be.
C++ tries to be a "do-everything" language. You can do OO development
in it and it works if you keep the discipline. You can do non-OO
development - that works too. And you're quite backwards compatible
to C.
> But for the sake of being anal and including yet another example:
>
> int x = 1;
> void *p = &x;
> int *i = p;
> printf("The number was %d ", *i);
>
> Won't work in C++ :-)
That's because you're trying to voilate the C++ type checking here.
You must either switch to C, or do one of the following:
int x = 1;
void *p = &x;
int *i = (int *) p;
printf("The number was %d ", *i);
or:
int x = 1;
int *p = &x;
int *i = p;
printf("The number was %d ", *i);
:-)
>>> The things you're prevented from doing in Java are prevented because
>>> they've proven to be more trouble than they're worth, and there are
>>> other techniques which allow the same things to be implemented without
>>> rehashing error-prone on non-portable paradigms.
>>
>> Such as unsigned integers or complex arithmetic? <g>
>
> unsigned types have error prone issues when casting from signed to
> unsigned types of the same size in C/C++, as no conversion takes place.
> You lose a little space efficiency without them but little else.
In Java one could add some code for checking here, since efficiency
isn't such a big concern anyway, and throw an exception in case the
conversion caused an overflow.
Btw this issue already exists in Java. Try this in Java:
int i = -2147483648;
int j = -i;
if ( i == j )
System.out.println("Java thinks -2147483648 is equal to -(-2147483648)....");
There will be no compile time error or even warning, and no exception at runtime....
> The case for operator overloading has been argued over and over.
> Originally, it was argued that they unnecessarily complicated the
> language, and the number of legitimate use cases for them is relatively
> small. I tend to agree that the feature is overused in C++, but I don't
> think that justifies removing it.
>
> Many features originally left out have made appearances recently, and
> it's likely to continue. I'd expect to see operator overloading appear.
>
> Matt
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/