Emlyn wrote:
>
> Samantha Atkins wrote, amongst other things with which I had no quibbles:
> > At minimum a good
> > computer language survey class, data structures class, computability
> > theory class, compiler class and an OS class.
>
> Personally, I'd drop the computability class, replace it with something on
> algorithms + algorithmic complexity. Also, parallel & distributed computing
> is a must-have.
>
Without a theory of computation class it is difficult to understand and
evaluate what is and is not possible or what is actually being done in
computation.
> Also, libraries & environments can be more important than languages
> themselves, in my opinion. It is easier to move between two different
> languages with the same libraries/environment, than it is to move between
> two implementations of the same language with different environments (eg:
> javascript vs vbscript vs n-many other languages on IIS is easy. Borland's
> VCL <-> MFC is not so easy.)
>
The unifying element above is a component architecture such as COM or
CORBA rather than the libraries themselves. COM is relatively
proprietary to the Microsoft world and languages while CORBA is much
more universal. Yes, components help a lot. But to produce and use
components you still need knowledge of languages and general language
concepts. In addition you need the characteristics and limitations of
components, component environments and the implied language that is
implicit in the sorts of APIs and operations supported by the component
environment. As an implementor you need to know how to create
components yourself in some language[s] of choice.
> I'd highly recommend Java these days, specifically because of the J2EE
> specification for enterprise computing. The resources provided by that
> environment let you get as close as possible to industrial strength
> applications, without the usual heterogeneous hell-on-earth that accompanies
> similar efforts. You can start very small with Java, and go very large, and
> everywhere in between.
J2EE is a swiftly moving target. EJB 2.0 specs have some pretty scary
limitations and gotchas including a need to avoid any cycles in
session/entity bean calls (or the results are undefined). As a
long-term designer of middleware and server systems I find a lot to
question and dislike in J2EE. It is by no means ready for primetime and
I can produce witnesses who tried it wholeheartedly who will testify to
its problems.
Ask Ben Goertzel about the apporpriateness of Java for very large
systems.
I have already shot off my mouth here and elsewhere enough about the
pokey, boring simple-mindedness of Java.
- samantha
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 10:00:01 MDT