[eropple]

I'm well aware that I don't know everything--but, with what little respect is due a troll like yourself, apparently I know more than you. :-) After all, I'm not the one saying "you don't need that" because I don't understand it; on the contrary--I am saying that these tools greatly empower a programmer to write better code. Because they do. You can certainly write "good" Java, but it will not be in the same ballpark as "good" Scala or "good" C# or "good" any-other-remotely-modern-language. The effort expended to write "good" Java is much greater, and as such it is a worse tool.

As for your ad hominem: I've been doing this at some level for ten years, thanks. I've been getting paid to do this stuff for about six. I didn't "just" start programming. I work in a fairly high-level, demanding environment with plenty of hard problems and a lot of code smell that can be directly attributed to poor Java expressivity.

That you can only fall back on "you're a kid" as a way to attack claims says much, much more about you than I.

You are describing to a T the sort of Blub programmer that is referred to in the Graham article I linked upthread, but I won't bother advising you to read it--you won't recognize yourself. Have a nice day. :)

[speckledjim]

You'll look back at these comments you're making in 10 years and be embarrassed. Hopefully by then you will have learnt a bit more about being a productive programmer.

The language doesn't matter. Repeat after me...

A good programmer can make good stuff in ANY language. A bad programmer can only make good stuff in their favorite language.

You should stand up, be confident, and realize that it is the programmer that creates awesome software. Not the language.

[karantza]

I think an example is in order. I'm going to code up a simple event dispatching algorithm in three languages. They'll have the same functionality. I consider myself fluent in all three, and I'll write them in the most consise and style-respecting way I can.

C++:

    #include <vector>
    #include <string>
    #include <iostream>
    typedef void (*hndlr)(std::string);

    class Event {
      private:
        std::vector<hndlr> handlers;
      public:
        void Listen(hndlr handler) {
          handlers.push_back(handler);
        }
        void trigger(string arg) {
          for (std::vector<hndlr>::iterator i = handlers.begin(); 
              i != handlers.end(); i++) {
            (*i)(arg);
          }
        }
    };
    
    void h1(std::string arg) { 
      std::cout << "First handler got " << arg << std::endl;
    }
    void h2(std::string arg) { 
      std::cout << "Second handler got " << arg << std::endl;
    }
    
    void main() {
      Event event;
      event.Listen(h1);
      event.Listen(h2);
      event.Trigger("something happened!");
    }

Lua:

    event = {listeners = {}}

    function event.listen(self, handler) 
      if (type(handler) ~= "function") return end
      table.insert(self.listeners, handler) 
    end
    
    function event.trigger(self, arg) 
      for handler in self.listeners do handler(arg) end
    end
    
    event:listen(function(text) print("First handler got "..text) end)
    event:listen(function(text) print("Second handler got "..text) end)
    event:trigger("something happened!")
    

C#:

    using System;
    public delegate void HandlerDelegate(string arg);

    class Main {
      static event HandlerDelegate Event;
      static void Main() {
        Event += (arg) => { Console.WriteLine("First handler got" + arg); };
        Event += (arg) => { Console.WriteLine("Second handler got" + arg); };
        Event("something happened!");
      }
    }
    
    

Now, go ahead and say that choice of language doesn't matter. You might not need lambdas, or first-class functions, or event handlers, and a good programmer can make the same algorithm "work" in any language. But by choosing a more powerful and expressive language, you can get those algorithms done in a way that's more readable, maintainable, and faster to code, which in the end is what really matters.

[Total_Meltdown]

Also fun: The only one of these that works when a callback removes itself from the event list in its own callback routine is C#. You get a hanging iterator in C++, and removing items from a table mid-iteration in Lua is undefined (though in practice usually works).

To make this case work properly, the place I work for has a 335 line C++ template class. This is all time that the developer could have spent actually building our product.

[eropple]

The C++ version could be greatly simplified by using boost::bind. It'd still be shorter and clearer than a Java equivalent that had to bung in anonymous classes and other crap to create a proper dispatch.

Your point, however, totally stands.

[Total_Meltdown]

I think you're misunderstanding the point here. It is perfectly possible to write awesome software in Java. With the amount of software out there, it would be completely insane for anyone to say that you can't do awesome things in Java.

> You should stand up, be confident, and realize that it is the programmer that creates awesome software. Not the language.

This highlights the misunderstanding. You're right. We should be spending our time making awesome software, not typing letters and building boilerplate code.

Full disclosure: I work with eropple on a fairly regular basis, I favor C#, I write C++ at my day job. I spent a few months doing Java, was able to do what I wanted to with it, but missed a lot of features from more featureful languages.

[dollarsigns]

There is more to awesome software than typing.

(Note this point stands compatible with the entirely orthogonal point about expressiveness and concision of a language.)

For me (at least due to client demands ..) awesome software, in part, posits the requirement of economically maintainable artifact.

PG's writings on Blub languages is imo addressed to a narrow audience of readers as it does not in anyway address maintenance and extensions to systems by non-elite development teams. Even elite teams, if tasked with delivery of products to non-elite consumers, must factor in the economic equation of the cost proposal.

To wit:

Having a bench of solid OCaml/Scala developers is a viable economic proposition for Wall Street and rich hedge funds; starry start-ups; and possibly elite teams in major media; a hacker community project. It is insanely difficult enough to find competent help in Blub-land, much less competent Scala programmers.

And, of course, the majority of software is developed/internally-consumed precisely by shops that must staff from blub-land. And surely you are aware that a big chunk of "programmers" out there are just recent graduates of some web-app vocational CS education.

Software language economy is not simply about lines of code. The economic cost equation of a language is definitely a critical factor if positioned as a general use language.

Java is unsurpassed in terms of the balance it brings to the economic equation: it is effectively powerful enough to allow serious developers to create "awesome" software, and approachable enough for blubland coders to crank out (yes) meh code that gets the (business) job done.

This fact was recognized by all entities chasing development dollars out there, including IBM, Oracle, and in its own cute way, via Google (Android).

Tell me: why isn't Android dev done with Scala or Clojure? My answer: Because Google management is not stupid.

[pg]

I'm embarrassed for both of you. Will you please stop baiting one another?

[eropple]

You don't seem to understand something that I guess I feel is rather basic: I don't have a "favorite" language. I have tools that are expressive and thus more useful because I spend more time in the problem space than I do in the language space. I also have Java.

Objects are a powerful concept because they allow a programmer to more easily map a problem to the available solution space. This is good. Java, however, fails to take the next step to enable even better mapping of a problem by creating a more flexible solution space. The other languages cited in this thread do create that more flexible solution space, and thus make getting a job done more easily and more cleanly a viable possibility.

.

A good programmer can make good stuff in any language. You are correct about this. Where you are wrong is in your inability to understand that a good programmer can make good stuff quicker and more easily in an environment that minimizes the distance between the problem and solution set.

But I rather get the impression that you don't know enough about what exists outside of your "box" to be as authoritative as you'd like to sound. You seem fundamentally uninterested in understanding the benefits that these constructs, and these simplified syntaxes (note: these are two separate points, but you seem to miss them both) provide to a developer. I don't think there's a lot of value in continuing this with you. Unless you bring forward salient points instead of petulant defenses based on fundamental ignorance, I won't reply to you again.

[smcj]

You ignorance is so painful embarrassing, it almost hurts to read your non-sense.