Slashdot Mirror

Not true. The Dalvik compiler was used to compile the GPL-released Java library/package source.

The Java library source in Android is based on Apache Harmony, and is Apache-licensed, not GPL. Here's an example file from it, with complete copyright notices.

Wow. So many wrong things I don't know where to begin.

1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp.

If you want to pick a functional language as an example of mono-paradigm, then surely Lisp (esp. Common Lisp) would be the wrong one, since it's a quite eclectic mixture of imperative and functional.

2. Difficulty. 90% of programmers (not on the internet, in general) write code like Fortran when its 2010. The most popular languages now, C# and Java, are popular because they are extremely easy to understand [...]

Ever tried to write a closure in Java? And you have to, in event-driven constructions. Something absolutely simple in Perl, Python, Javascript, Tcl and (gasp!) Lisp, wrapping the idea of "do this action, taking all its environment at a later point in time, when that happens" looks like this abomination?

3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead.

Quite a few really high-performance applications are written in Common Lisp. Google for Allegro and Lisp to see a couple of examples. The thing is -- the flexible design of the language makes some tricks easy which would be prohibitively difficult (given the right circumstances) with other language designs. And have a look at the language shootout some day. SBCL (yes, a Common Lisp implementation) ranges up there with Java server and other compiled languages, way beyond Python, Perl & Lua.

In the real world my experience is, though, that the right choice of the architecture and algorithms, and good use of the available platform (be it Scheme, VB or brainfuck) makes the difference. Blaming the tools just reflects on the craftsperson.

4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO...

Never heard so much nonsense so tightly packed. Common Lisps typically compile to the metal (SBCL does). I know people writing network perfommance analysis tools in Common Lisp.

I like the way C and OO work more than I like dynamic typing and having no data and all the other out of this world paradigms [...]

Then you'll like to know that Common Lisp has one of the more advanced object models (CLOS). They invented the "meta-object protocol", an idea which is now, over a decade later finding its way into the more naive languages.

Look: you don't have to like Lisp. It has its deficiencies, and given a job, I tend to choose the right tool carefully (and most of the times it won't be Lisp). But if you're talking languages you just can't afford not to know Lisp unless you want to look quite dumb.

Heck -- I'd like to make an addition to the headline: "...and why a programmer should master more than one language" (and yes, for that context Perl, Python Ruby and PHP count as one).

In Florian's paper, he points these out as Sun PROPRIETARY / CONFIDENTIAL. However, it looks like several of the sources come from Sun's mmademo, linked here. In this rendition of the document, each source file's license is a permissive one by Sun (i.e., not proprietary / confidential).

The ones from microedition seem to be mentioned elsewhere under GPL.

Some sources seem to come from here, where some of the files (e.g., Control.java) have the proprietary markings, but these are interfaces. Control, for example, is an empty interface. Not sure if that affects anything.

I'm not qualified to make any sense out of this, but it seems like several of the sources Florian mentions are actually GPL'd sources with incorrect headers. There are a few trivial ones that (in the source I found) seem to be correctly marked proprietary. As much as I admire Florian's ability to grep, I think he's just found an error in some headers, not actual violations.

The code snippet shown in the ZDNET article, the code that Google supposedly ripped off, is GPL.

Not sure why batch is such a bitch, but you can execute shell commands with Ant.

Thanks. According to http://www.java2s.com/Tutorial/JavaScript/0380__Window/windowonBlur.htm, onblur is triggered whenever focus is lost, so it seems to me that moving focus to another window would similarly work for this phishing attack.

Is it only me that I care for functionality and not decoration?

Two points:
1. You're not the average user.
2. Good UI design exposes functionality unobtrusively; it's not about airbrushed icons, and it's not just aesthetic.

Icon choice is only one minor facet of UI design. When you do File->Open in a native Windows application, it will probably look like this. The appearance may vary slightly, but for a given operating system revision the buttons are always the same size and in the same place. That is to say, the open file dialog is consistent across all applications, and a user familiar with the OS immediately recognizes it. Familiarity encourages your users by giving them a successful outcome essentially for free. "OK, I can do this." GTK+ on Windows ignores these conventions, giving the user something like this, or something like this. Though you might think they are stupid, 9 out of 10 users will be utterly baffled by the disparity here. They expect to see a Windows file open dialog, and they see... something completely new. They don't hate it because it doesn't look pretty, though I'm sure at some level that comes into play. More importantly they're thinking, "Oh crap, new interface! Man, if even opening a file takes this much thought and effort I hate to think what the rest of it is like." If they don't give up on the program outright, they'll have to spend an extra minute or two learning something they should already know how to do. Those are minutes they could have spent learning your program! Sit those same people in front of the same dialog in an Ubuntu context and they will chug right through it, mostly because they expect there to be a bit of a learning curve. But something as simple and ubiquitous as an open file dialog shouldn't present any learning curve. Do you see why?

If you're the only person using it, then you can design it using whatever interface you want. By definition you become familiar with it as you code it, and your interface will be designed around your logical conception of how the program works. I write most of my internal tools for CLI, just because it's easier. But if you ever expect non-programmers to use it, don't be surprised when they hate your program (and you) for making them jump through unnecessary hoops. "Why didn't the developers spend the time to do it right?" Things like whether or not the menus function as expected can make or break a project, and even an introductory UI and usability textbook should make this clear. Learning a proper cross platform kit takes a few hours at most, and makes everything feel loads more polished. And it will make your programs look a lot more professional if you ever decide to port them.

I'm struggling to think of a car analogy, but GTK+ applications under Windows remind me of a beat up car with primer gray doors, except that the seat belts pull up from the waist and buckle at the shoulder, and the ignition key turns the opposite direction. This is a trend we desperately need to change. The question isn't, "Does it function?" The question is, "Can the user operate it with minimal effort?"

Java can be a pain with lots of verbose code compared to a simple language.

Python is easier and not everything is an object. Object oriented programming is hard and this is especially true for newbies.

Whats easier?

#include studio.h
int main()
{
prinf( "Hello World")
} // its been years since I did C++ forgive me if I // am wrong

or
package helloworld;

public class HelloWorldApp {

        public HelloWorldApp() {
        }
        public static void main(String[] args) {
                System.out.println("Hello World!"); // Display the string.
        }

}

Count the lines of code it takes for a simple Message Dialog? Wow!

I do not know python but I have a feeling is pretty simple to say hello world for a noob and create a simple dialogue box.

Java will never die though because the api is very feature rich and its extremely portable.

For the User/Developer, among the best are ... "Open".

Apache FOP: http://freshmeat.net/projects/fop/
Apache FOP: http://xmlgraphics.apache.org/fop/download.html
    NetBeans: http://download.netbeans.org/netbeans/6.0/final/
    Alfresco: http://www.alfresco.com/

Good Guide: http://www.vrcommunications.com/PDFs/ditaotug141-03122007-pdf.pdf
Title DITA Open Toolkit User Guide: Fourth edition, December 17, 2007. Based on release 1.4.1 of DITA Open Toolkit. All files copyright 2006-2007 by VR Communications, Inc., unless otherwise indicated. Licensing Edition, release, copyright and usage of this document and related materials is regulated by a Common Public License (CPL) granted by OASIS (Organization for the Advancement of Structured Information Standards), http://www.oasis-open.org/ . DITA Open Toolkit is an open-source, reference implementation of the OASIS DITA standard (currently DITA 1.1).

JAVA: http://www.java2s.com/Open-Source/Java/CatalogJava.htm
Open Office: http://www.2008-official.com/openoffice/