Slashdot Mirror


Miguel On GNOME, Bonobo, .NET and more

unixbob writes: "Microsofts developer site MSDN is running an interview with lead GNOME developer Miguel de Icaza entitled Using the ECMA Standards: An Interview with Miguel de Icaza ."

1 of 24 comments (clear)

  1. Re:Do We Need This? by pthisis · · Score: 4, Interesting

    I have to consider C++ a high level language because it's possible (and not too hard) to keep everything pretty well abstracted. I would say that of the high level languages C++ is the lowest, but that doesn't make much sense :)

    The point was that in this context referring to C++ as a high-level language is pretty iffy. To an EE designing a chip, i386 assembly is a high-level language. To an OS implementor, asm is a low-level language and C is a high-level language. To your typical application developer, C is a low level language and Python and VB are high-level languages. In the context of Smalltalk, Python, Java, C#, and C++--which is what we were talking about--C++ is unquestionably a low-level language.

    It's all relative to your point of reference.

    parameterized types are basically a must-have.

    I've seen some huge Java projects with very clean designs, so "must-have" seems awfully strong.

    Way to snip the context. I said something along the lines of "in a strongly statically typed language, parameterized types are basically a must-have". Java purports to be such a language, but any sizeable program using collections foists off a fair amount of manual dynamic type-checking on the programmer. All this without the RAD and code-density advantages of a true dynamically typed language.

    Seriously, this and the borked up I/O and threading capabilities are some of the worst parts of Java. That's not to say you can't write large projects in Java--_any_ language can be used to write large, successful projects with enough skill and effort. Java simply doesn't, in my opinion, approach either the dynamic (Smalltalk, Python) languages or the more mature static (OCaml, SML) languages as far as ease of implementation for large projects. It's libraries are it's strength and weakness; many of them are horribly designed, but they're bog-standard and they have an API (however poor) for basically everything. But Java still doesn't come anywhere near approaching especially Smalltalk in terms of installed base by application size and transaction counts, nor by total $$$ handled. And it doesn't approach even a goofy language like VB for worldwide LOCs or apps written. This despite a lot more marketing behind Java than Smalltalk ever had.

    It's hardly the worst language ever written, in fact the language (as opposed to the libraries and the JVM platform) is a decent one if they'd just add parameterized types. But there are much better ones out there that have open licensing and source.

    Personally, I'd recommend the following 4 language groups to any computer scientist wanting to learn several kinds of programming styles:

    1. C, as a basic procedural language and because most other languages are implemented in it.
    2. A strong statically typed functional language like OCaml, ML, or Haskell; OCaml wins based mostly on quality of implementation and availability, as well as offering an exposure to OO in a statically typed functional context.
    3. A highly dynamic language like Lisp, Scheme, Smalltalk, or Python; Python and Smalltalk are my tossup choices here because they also offer an exposure to true OO programming (not simple class-oriented programming a la C++ and Java)
    4. A weakly or non-typed language like typical Perl 4 or Tcl just to appreciate the alternatives. (Perl 4 wins because Perl knowledge is often handy)

    Those I'd recommend well before C++ or Java (which offer comprimises on categories 1-3), although those 2 would probably be next (simply because of increasing prevalence) along with a programming by contract language like Eiffel and a logic-based language like Prolog.

    Even if you wind up using VB on a daily basis, a good exposure to functional programming, static typing, etc will make you a better software engineer.

    For real-world problems I almost always find myself falling on a mix of C, Python, Smalltalk, and high-level script (awk, Bourne, sed, etc). But I wouldn't give up my fp experience for the world.

    Sumner

    --
    rage, rage against the dying of the light