Slashdot Mirror

with map/filter/etc

Remember when Guido decided those are too difficult for the average Python developer?

Filter and Map got a stay of execution, due to massive backlash. Reduce, the one he "always hated most" was moved in to functools.

They'd never have made it in had he not allowed them to be added on a whim. If your BDFL had taken a few minutes to actually plan that backward-compatibility-breaking monstrosity, you wouldn't have filter, map, or reduce at all.

Remember kids: Thoughtless design is bad design. It's why lambda's are completely borked.

I'd also genuinely like to learn more about how anonymous functions are crippled by whitespace.

I'll let Guido answer that.

Of course, he sees nothing wrong with the absurd constraints imposed on lambdas by his ridiculous white space rules:

In my mind, the inability of lambda to contain a print statement or a while-loop etc. is only a minor flaw;

Scott Meyers is his usual excellent self: http://www.artima.com/shop/ove...

Take virtual methods for example. The linux kernel is chuck full of structures filled with function pointers. That is a virtual method in C++, except in C++ you don't have to worry at runtime if the function your calling is NULL because the compiler assured that during compile time.

Please explain this and why I can get "pure virtual function called errors in C++. According to you it should be impossible, yet I can find hundreds of pages explaing it and I have done it a few times myself.

The kernel is not full of macros for RB trees, linked lists/etc. Those are libraries that use malloc and dealloc, which when doing kernal programming you really can't use. You will have to write those out specifically using your own memory handler, which means anyone else's library is not valid.

Like I said before, if you can't use C++ features without incurring massive performance penalities that you don't want, so you limit it to what C can do, why use C++. Bonus problem. Write "hello world" in C with stdout, and again in C++ with cout. Now tell me how many orders of magnitue the binary for C++ is larger than C. If you use ANY C++ feature you include the entire C++ library, which you have to rewrite for your kernel to use, while writing libc is trivial in comparison.

Please don't respond with guesses about how things work if you've never done kernel programming and don't understand the difference between that and normal programming. Its fine to want to use C++ for kernel development, but making the claim that its "just as good as C" is an outright lie.

GvR is not a dictator. This move should not matter to someone who wants to leave their creation run free.

Which part of Benevolent Dictator For Life do you not understand?

http://www.artima.com/weblogs/viewpost.jsp?thread=235725

The best article that I've ever read on coding style is Style is Substance by Ken Arnold.

I won't repeat what he has to say here, because he explains it better than I could. But I wish that more programming languages would follow what he is advocating, because we waste way too much time arguing about braces and tabs.

You know, if you're interested in the origins and influence of C# ... you might want to check out it's (main) inventor : Anders Hejlsberg.

Interview on the origin of C# (the short version : Turbo Pascal => Borland Pascal => Delphi (Object pascal). If you've used these different languages, this is beyond obvious : C# is a more concise version of Delphi's Object Pascal)

Frankly, more people should try C#, it's a much more ... complete ... language than java when it comes to language features. It's got all the things java misses, from function references, delegates (which are basically function pointers to class member functions, dear God I can't tell you how much java needs these), full generics (as opposed to type-erasure generics), properties (full getter/setter functionality without the pain), a full VM ... This means that any java program is trivially translated to C#, and can easily be improved from there. The reverse ... oh dear God you don't want to try converting a non-trivial C# program to java.

But as libraries go, C# is a disaster ... Microsoft really should start over from scratch and build a big coherent library (imnsho).

And of course, the things they both do very, very, very well : tool support. While java's (whether you're using eclipse or netbeans or even intellij) is a bit clunky, it's at least there : refactorings, code completion, ... C# has this too, even better than eclipse in my opinion, both on linux and on windows. But, even if C# edges out Java in this regard, both are very usable (as opposed to, say, scala's tool support. Want to learn functional programming ? F# is seriously more usable just because the tools are better)

What's wrong with type-erasure generics ? This would seem an obvious feature for a map class, if an instance doesn't exist yet, create it using the default constructor :

class Map<K, T> {
    public T get(K key) {
        if (contains(key)) return _get(key) else return new T();
    }
}

Can't do it in java ... at all ... never ... Ever wished it would just work like that ? I know I did on many occasions.

Of course one of the better features of java is it's simplicity. It's brain-dead simple, in a way that Visual Basic is, but cleaner. Idiots can easily learn java programming, and fully mastering the language doesn't take all that much more.

Personally I wish google would fork java. Build a JVM (or just a Java++ compiler), and add a lot of features. Decent generics. Function pointers (including, *please* delegates). Properties. Tuples. But keep it some sort of compromise. More extensive than java, not quite as ridiculously complex as scala. Please : no stomping functional bits through everyone's throat, just a real extension to java.

Yeah, sure, all those banks, Google, Twitter... PHP through and through.

Google uses everything.

Twitter started with ruby on rails, then moved to Ruby on Rails to deliver most user-facing web pages, and some of the back-end Ruby services with applications running on the JVM and written in Scala.

Partially, yes, mostly, no.

Maybe the biggest problem with generics is that the "woods" gets hidden by too many "trees". Although I do not agree everything with http://www.artima.com/weblogs/viewpost.jsp?thread=299081 there is good example in the bottom. The beef, "map.sort.each", is hidden in the Java example by far too much litter.

As said by metamatic (above/sideways/how-should-I-describe-this) Java's first mistake was to have non-object types. The performance gain was minimal as optimizing compilers would have short-circuited most. E.g. Eiffel claimed 1-3% penalty at that time (when Java was born).

Then there is the Gödel's theorem. It states that no mathematical system can be "full" and "consistent". I believe it holds for programming languages too: either it is unusable or has some "inconsistent" semantics/behaviour.

Even more, design-by-committee problem: committee cannot make a clean design. Nowadays Java includes everything from kitchen sink to lambdas and soon parentheses and Prolog I fear. Sure it is nice to have function-almost-objects without class, but then so what?

You'll notice that I am no longer consistent, I hate extra verbosity that genericity incurs but then don't mind verbosity that full classes incur. Well, I do believe in "Gödel-extended-to-language" :-)

Perhaps closures could have been put nicely into the Java when Java was designed first time. Now adding them into the soup is most likely going to make the language worse with almost no gain. Unless you consider as "gain" the fact that some language theorists gets a few brain-orgasms.

They should have left Java as it was and made a new language on top of JVM.

I never get any modpoints any more, but if I had I'd mod you up.

For a personal app, the time and effort it takes to get it done also counts and here Swing and Java2D are well thought out.

Another hint.
Last I tried any drawing in java was 5 years ago.
I found it easy to set up a look that kept redrawing my canvas every 500ms.
I then ran the program through the debugger in eclipse, and I could see the image change as I changed the code, due to javas hot code replace.

Now a days I wouldn't write java code in my spare time.
Scala is more entertaining, and Scala also takes the pain out of Swing applications.
Take a look at this spreadsheet demo application:
http://www.cs.helsinki.fi/u/wikla/OTS/Sisalto/examples/html/ch33.html

Example is from Programming Scala. Best programming book I have read in years.
http://www.artima.com/shop/programming_in_scala

Actually (though I am not Ruby programmer), article http://www.artima.com/weblogs/viewpost.jsp?thread=299081 sums this up quite nicely.

Obviously I would have put it quite differently. For example last example would "ensure" that getInfo returns a map which is "? extends sortedmap", keys are "? extends comparable", etc.

After those the beef (map.sort.each) would be a tiny percentage of the entire code. This does nut sum up, IMHO.

the real question is: Can it web scale?

probably.

I was just reading over this page the other day and thinking to myself how bloated Java is getting.

As a whole the generics is a useless and dangerous disaster

You keep repeating that. Citation needed.

Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html.

Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

Indeed it is a bad thing. A problem that all excessively obscure and complex languages have rapidly revealed (C++, Perl) is that every difficult-to-use feature gets used (if it is usable at all) and has to be supported by every other programmer eventually since 90% of all programming is support of existing code.

The saving grace for Java generics is that beyond container typing it seems sufficiently hard to use that it rarely gets used. Some time back I scanned the source of several substantial and active open source projects without finding any examples in use beyond container typing.

I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

Beyond container typing what aspects did you actually use? Have you ever written one genuine generic algorithm? That is - an algorithm with a generic interface that takes any appropriate generic type and returns an appropriate result type while maintaining typing throughout?

The funny thing is that Twitter did exactly what the parent suggested. They prototyped it in Ruby and then rewrote it in Java (Scala).

The idea is not only that automated testing is good, but that testable code is fundamentally better because it needs to be loosely coupled.

Which is a faulty assumption. Coming from this perspective, you want to unit test everything, and so you need to make everything loosely coupled. But the latter is not free, and sometimes the cost can be hefty - where a simple coding pattern would do before (say, a static factory method), you now get the mess with interface for every single class in your program, abstract factories everywhere (or IoC/DI with its maze of XML configs).

Ultimately, you write larger amounts of code that is harder to follow and harder to maintain, for 1) a real benefit of being able to unit test it, and 2) for an illusory benefit of being able to extend it easier. The reason why that last benefit is illusory is because, in most cases, you'll never actually use it, and in most cases when you do use it, the cost of maintaining the loosely coupled code up to that point is actually much more than the price you'd have paid for refactoring it to suit your new needs if you left it simple (and more coupled) originally.

Also, it does promote some patterns that are actively harmful. For example, in C#, methods are not virtual by default, and it's a conscious design decision to avoid the versioning problem with brittle base classes. But "testable code" must have all methods virtual in order for them to be mocked! So you either have to carefully consider the brittle base class issue for every single method you write, or just say "screw them all" and forget about it (the Java approach). The latter is what most people choose, and, naturally, it doesn't exactly increase product quality.

Of course, this all hinges on the definition of "testable code". The problem with that is that it's essentially defined by the limitations of current mainstream unit testing frameworks, particularly their mocking capabilities. "Oh, you need interfaces everywhere because we can't mock sealed classes or non-virtual members". And then a convenient explanation is concocted that says that this style is actually "testable code", and it's an inherently good one, regardless of any testing.

Gladly, TypeMock is about the only sane .NET unit testing framework out there - it lets you mock anything. Sealed classes, static members, constructors, non-virtual methods... you name it, it's there. And that is as it should be. It lets you design your API, thinking of issues that are actually relevant to that design - carefully considering versioning problems, not forgetting ease of use and conciseness, and providing the degree of decoupling that is relevant to a specific task at hand - with no regard to any limitations the testing framework sets.

It's no surprise that some people from the TDD community are hostile towards TypeMock because it's "too powerful", and doesn't force the programmer to conform to their vision of "testable code". But it's rather ironic, anyway, given how TDD itself is by and large an offshoot of Agile, which had always promoted principles such as "do what works" and "make things no more complicated than necessary".

Didn't we know Google was after administrating white space for the past five years?

Google employees are working on a new language based on Scala called Noop. Not enough to claim that Google is backing it but... Check here: http://www.artima.com/forums/flat.jsp?forum=270&thread=270125

Maybe, but because the jvm is targetted at Java my guess is that as alternatives like parrot, llvm or, god forbid, mono become more mature I expect more and more languages to start using them instead if for no other reason than it's easier to do. I doubt scala and clojure are going to decide to drop the jvm but unless you're writing a new language that looks a lot like java it seems like a lot of unncessesary work to target the jvm.

A good article I just found that talks about the jvm as a general platform:
http://www.artima.com/weblogs/viewpost.jsp?thread=176597

In fact, good accurate garbage collections could be considered the most important development in programming languages since OO (and some even think more important)

Really? Who thinks GC is more important? GC is helpful only for simple classes with no relationships, like strings and vectors. For real objects in real databases, where all the real work is done, GC is useless. Here's the argument for why Java has GC. From the link:

Garbage collection relieves you from the burden of freeing allocated memory

Brilliant... instead of calling delete, I have to call a method that does the exact same thing as a destructor.

Knowing when to explicitly free allocated memory can be very tricky.

Seriously? You mean the line of code where I decide I want the object gone from memory isn't the right place to call the destructor? Somehow I'm better off not knowing whether or not an object in my database is still in use?

There are plenty of real world case studies that prove your personal experience to not be the general case for Java:

http://www.sun.com/customers/index.xml?soln=31a8487e-0f60-11da-99bc-080020a9ed93&page=1&sort=date&asc=false

This case study is particularly relevant:

http://www.sun.com/customers/servers/transact_tools.xml

This page is rather out of date, but shows that Java was performing well even in 2003:

http://www.artima.com/weblogs/viewpost.jsp?thread=8142

Java has become the number one most prominent language in business with good reason. It's flexible, and can cater to pretty much anything you throw at it if you understand the tools and technologies available, and which ones are suited to your particular problem. Garbage collection really just comes down to having an understanding of the way the garbage collector works and being able to develop with that in mind. See here for an example discussion of just that from back in 2003:

http://java.sys-con.com/node/37613

here's a slightly more recent (but still relatively dated in technology terms) article:

http://articles.techrepublic.com.com/5100-10878_11-6108296.html

The problem Java and .NET seem to face is people approaching the language, from say a C++ background and not understanding what's different about it and how it works to be able to implement a solution in it to an equivalent level of their C++ application. This does not mean experienced Java/.NET programmers cannot do just that though- they can, and do. Again, it's really a question of competence in a particular skillset rather than inherent flaws in a particular technology.

I have not only seen the book but also read it (assuming you mean Programming in Scala). It is very well written and gets you started with Scala easily.

I do not agree that the syntax is redundant. To the contrary: an important part of the language design is that Scala enables the programmer to extend the language using libraries. A good example is the way collections and iteration work in Scala vs. the way the foreach loop has been added in Java 5.

Whether static type systems help or hinder depends on whether you work with or agaist it, and on the kind of programs you write. The Scala type system is rather advanced (in the sense of complete) such that it allows you to express more in the type system than other languages do.

For Java style programming Scala is just much simpler and shorter to write. When you have written some code in both you can appreciate the way Scala works.

There has already been a comment on multi-paradigm programming, I do not have to extend that.

I don't know about the claim that the JIT compiles everything... but I do know that it does have an interpretter. Its quite possible to run the .Net CLR in pure interpretted mode.

Please explain how and/or provide the links. All reference material on .NET that I am familiar with which touches the topic quite explicitly states that there is no bytecode interpreter in .NET by design - so bytecode can be optimized for the easy JIT compilation specifically. This is often highlighted as one of the major points of difference between CLR and JVM.

For example, here is the interview with Anders Hejlsberg - a man who is certainly qualified to speak on how CLR works - about CLR design choices. In it, he says:

Anders Hejlsberg: ... In our case, though, we never intended to target an interpreted scenario with the CLR. We intended to always JIT [Just-in-time compile] ...

We're finalizing a bit of text that we're going to add to the interview about JRuby. It was an oversight on my part to not do this initially. You'll see the official answer once we get the final form of the text approved by the Twitter guys, but the gist is that they did indeed give JRuby a try, and the main problem they had that disqualified it was that their Ruby app used a lot of libraries with C extensions that weren't available for the JVM. So it was not a simple matter of taking their Ruby app and running it on the JVM with JRuby. When they tried that, it didn't run.

(Now quoting parent):

And what does scala have over say erlang for concurrency and performance?

I'd say that maybe it's that Alex has written a book on Scala, whereas they don't have someone on staff that's written a book on Erlang?

Use what you know, as long as it can get the job done...

For people like me, without Scala the JVM wouldn't even be under consideration, though I admit that Java has been more usable since it got generics.

The creator of Scala, Martin Odersky, was instrumental in the design and development of Java's generics. I believe he is also responsible for (some version of) Sun's javac implementation.

For a reference, see
http://www.artima.com/forums/flat.jsp?forum=276&thread=221233

In my opinion, Scala is excellent. So far I've used Scala to generate code which leverages NVIDIA GPU's for computational physics. I've also used Scala to do simple combinatorics and text processing. The latter is particularly pleasant -- a parser-combinator framework is included in the standard library which makes it a snap to define and process arbritrary grammars. My biggest frustration with Scala has been the somewhat spotty IDE support (compared to Java). However, the situation is improving and decent plugins for Eclipse, Netbeans and IDEA are all on the horizon.

Not really. Keep learning 2.x as you were. Quoth Guido:

http://www.artima.com/weblogs/viewpost.jsp?thread=211200

Ignore 3.0 for now. If you encounter it, there is a handy script to help update your code, though most of the language is unchanged. The biggest gotcha is that print is now a function print() rather than a statement.

Well, that is a quote from 2007 saying "I expect it'll be two years before you'll need to learn Python 3.0".

Not really. Keep learning 2.x as you were. Quoth Guido:

http://www.artima.com/weblogs/viewpost.jsp?thread=211200

Ignore 3.0 for now. If you encounter it, there is a handy script to help update your code, though most of the language is unchanged. The biggest gotcha is that print is now a function print() rather than a statement.

Wow. Are you joking? You just had to create an object class

And in Python, you have to create a module. The only difference is that Java repeats the name of the class/module within the source code file, and Python doesn't. The other difference (a main method) isn't required by Python, but it's a common practice.

What language would you recommend for an OO programmer to start with?

Any language will work to start with, just commit to not using assignment statements. Twenty years ago, I was a FORTRAN programmer who got introduced to LISP. I decided to try rewriting some of my programs without assignments. Since FORTRAN didn't allow recursion, there were lot of places where I got stuck, but it was surprising how I was able to get done. And I seem to recall that the programs were easier to debug, since there were fewer places where data could get clobbered. It should be easier these days since modern languages support functional programing, you just need the self-discipline to stick to that style.

Hint: any place that you want to make an assignment, turn the rest of the block into a function and pass the value as a parameter. If you have a loop, try coding it as a reduce-type algorithm; it's mentally easier than turning it into a recursive algorithm and it maps well to massively parallel architectures. Python somehow got a lot of functional stuff added in when Guido wasn't paying close attention (http://www.artima.com/forums/flat.jsp?forum=106&thread=98196), so it's a great language to play with.

After that, follow the suggestions in the article. Learn Scala, F#, Erlang or Haskell. Get a copy of Mathematica. Have fun, and you'll learn a lot.

You miss the real reason why it's all so much less complicated on .NET : There's only one platform to target, and that platform is Microsoft.

None of the reasons the GP mentioned in this post have anything to do with "one platform". He seems to be mostly content with C#-the-language, not .NET-the-platform. Java could have its own LINQ analog and type inference already, if only Sun (or Google, or IBM, or other of the big players) wanted it - which they don't. End result - talented language designers like Neal Gafter are leaving the Java scene and joining Microsoft to work on C#. And, given that Neal was the author of the most well thought-out proposal on adding closures to Java, it means that this feature will likely not make it into the language anytime soon - not until Java 8, if it will ever happen (by which time MS will already roll out C# 5.0, etc).

Sad...

Strong vs weak, static vs dynamic typing

http://www.artima.com/weblogs/viewpost.jsp?thread=7590

Plus add explicit vs implicit (explicit almost always means static, implicit can be either).

That might seem wrong given that Python lists threading modules, but just look at Python's GIL to know what I mean. As in, no matter what you do, Python will still be running on one core. So, if you just want a performance boost because of a lot of I/O, then threads can get you there. Unfortunately, if you want to take advantage of a multi-core CPU with Python, Python's threads won't get you there. There has actually been a lot of discussion on this topic, but Guido just refuses to do it. The interpreter has no threads and the lib is not thread safe.

If you want to do multi-processing with Python, look at its subprocess module.

Guido's blog post on the GIL:
http://www.artima.com/weblogs/viewpost.jsp?thread=214235

The FAQ entry on a (fallacious) reason why they won't remove it:
http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock

So the company where I've worked for the last 10 months hired me for an intermediate development position which I accepted because of the location. My prior position was as a senior developer working for a similar sized organisation in the same domain (banking). Not only did my current employer not take advantage of my carefully honed skills and considerable experience, I'm now leaving the organisation because their development practice is a shambles and it was made clear to me by the CIO that I would be unable to address issues I had raised (things as basic as software version control).

When I indicated I was taking a broken window approach to website changes I was told not to bother, "I'll probably just hire a student to do that one holidays".

A web person was hired to assist me with some basic website udpates, failed dreadfully, wasn't provided any training in an unfamiliar technology, and was then pushed out the door - he was the 8th person offered the position, the previous 7 turned it down because the pay was crap. Etc.

I'm leaving the position with some extraordinary examples of how not to do things, my self-respect, and just under a year of Java immersion.

That's a library implementation issue. Once again, there is no reason why QFrame and QMenuData couldn't be interfaces with an implementation class behind the scenes that has an instance of both classes for implementation.

For you, as a user of Qt, you would still just extend from QPopupMenu or QMenuBar. As a library user, nothing would have changed for you. Surely you don't expect to extend from both QMenuBar and QPopupMenu?

http://www.artima.com/lejava/articles/designprinciples4.html

Erich Gamma's seems more to agree with me. And I agree with Gosling that abstract classes (partial interface/partial implementation) were a bad idea.

Your interface and your implementation should remain separate.

An interview with Erich Gamma.

Never let the facts get in the way of a good rant:

Q. If you're killing reduce(), why are you keeping map() and filter()?

A. I'm not killing reduce() because I hate functional programming; I'm killing it because almost all code using reduce() is less readable than the same thing written out using a for loop and an accumulator variable. On the other hand, map() and filter() are often useful and when used with a pre-existing function (e.g. a built-in) they are clearer than a list comprehension or generator expression. (Don't use these with a lambda though; then a list comprehension is clearer and faster.)

As it stands, map() and filter() will both remain, and reduce() is being moved into functools. This isn't the deal breaker you're making it out to be.

>I am so completely convinced of the superiority of the .NET model and the C# language

Your sentence is missing something: the superiority of C# *compared to what*??
Or you believe that C# is the best language currently?

I agree that C# is superior to C++ for ease of development (but not for speed and memory usage),
but I don't find it superior to Scala.
A small intro to Scala: http://www.artima.com/scalazine/articles/steps.html

oak project (the java origin) was all about programable portable devices

The Java programming language has things about architecture-neutral executions, for instance, and dealing with the fragile base-class problem. You can actually solve those problems within the context of C++. I mean, it's just sort of an artifact of the way the C++ compilers are built that they have this problem. My original goal was to build a C++ compiler that didn't have these problems. But then as I worked on that, and as the developers on the project sort of came after me, it became really clear that there were other problems that needed solving, and it sort of evolved into just a new language.

Python's lambda is limited to a single expression, which sucks, but you can always do def _(...) just before use.

No anonymous lambdas, hmm? That does seem like an advantage to Perl.

As for closures, Python implements closures properly (properly = as described in SICP, the environment model of evaluation)...

I have SICP right here; can you give me a reference that says you cannot write to lexicals in proper closures? You can in Perl. (Admittedly you can in Python as well; close over an aggregate and modify an element of that aggregate.)

Python's parsing of vertical whitespace is not ambiguous.

Whatever other reason Guido may give for not including multi-line lambdas, he has said:

Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an unsolvable puzzle.

Language Design Is Not Just Solving Puzzles

what, you think I haven't read the jargon file?

Of course python counts as an entry for "languages of choice" as that's how the jargon is used. Evidence: this thread. Many people consider it a choice language, so the jargon fits.

That doesn't mean they are correct, though. Python is all about forcing you into a specific style of programming, and a pretty basic one at that. The fact that the designer thinks many important programming concepts are confusing is hilarious. The fact that he forces others down to his level by limiting how you can program in python is sad, at best.

And I'm not EVEN going to talk about whitespace.

Alright, I know this is going to be flame fodder, but I'm genuinely curious: does Ruby have anything to offer for someone who's already very proficient in Python (and Django, so Rails is already covered)?

If you look at it from a features and libraries perspective, then you really won't find much different. But you shouldn't look at it that way.

There's a significant programming style difference between the Python and Ruby communities. Python programmers, as a general rule, tend to be more inclined toward imperative programming, while Ruby has much more of the feel of a multi-paradigm language. To understand a lot of Ruby code out there, you need to wrap your head around concepts like functional programming, metaprogramming, and domain-specific languages. Ruby code tends favor higher-order functional combinators over primitive looping syntax (an influence from functional programming), extending the system base classes extensively (an influence from Smalltalk), and a lot of it has the flavor of trying to extend the language to look more like the problem space itself (domain-specific languages; look at something like rake, for example).

Python aims to be "clean" in a very contentious sense of "clean." To put it in a way that will be taken very partisanly: Python is the language that you get when "clean and easy to understand" is taken to mean "only promotes the concepts that are easy to understand to a mediocre imperative programmer." For example, Guido is on the record that higher-order functions like reduce are supposedly hard to understand.

To be fair, yeah, Python is a reasonably clean imperative/OOP dynamic language, which is no mean feat, but many of us folks really would rather have a language that supports a broader range of programming paradigms. (Though I'm not as great of a fan of Ruby as I used to be before I got going on Scheme, I must say...)

Please read what Anders Hejlsberg has to say before telling your bullshit to the ignorant masses of Slashdot.
http://www.artima.com/intv/anders.html

If you want to understand why delegates and events are the way they are, read this :
http://www.artima.com/intv/simplexity.html

This has nothing to do with the state of win32 itself.
Also, if you read the *whole* interview of Anders, you'll understand that some of the clunky things people with a smalltalk or objective c background don't like are the way they are because of PERFORMANCE. Like C++ and Object Pascal, Anders Hejlsberg designed C# with performance in mind. That's why you get structs (value types), instance methods that are not virtual by default (unlike Java) and the way generics are implemented. That's also why C# is never going to be as dynamic as Objective C. .net went through a LOT of research, some of it are already in C# 3, some of it is in side projects that may or may never make it to the commercial product. But be sure of the fact that Microsoft is working a lot more on language research than Apple and don't confuse the docs on MSDN with the way they do their work inside.
See :
http://en.wikipedia.org/wiki/C%CF%89
http://en.wikipedia.org/wiki/Spec_sharp
http://en.wikipedia.org/wiki/Sing_sharp
http://en.wikipedia.org/wiki/Polyphonic_C_sharp
http://en.wikipedia.org/wiki/Microsoft_Singularity

Please read what Anders Hejlsberg has to say before telling your bullshit to the ignorant masses of Slashdot.
http://www.artima.com/intv/anders.html

If you want to understand why delegates and events are the way they are, read this :
http://www.artima.com/intv/simplexity.html

This has nothing to do with the state of win32 itself.
Also, if you read the *whole* interview of Anders, you'll understand that some of the clunky things people with a smalltalk or objective c background don't like are the way they are because of PERFORMANCE. Like C++ and Object Pascal, Anders Hejlsberg designed C# with performance in mind. That's why you get structs (value types), instance methods that are not virtual by default (unlike Java) and the way generics are implemented. That's also why C# is never going to be as dynamic as Objective C. .net went through a LOT of research, some of it are already in C# 3, some of it is in side projects that may or may never make it to the commercial product. But be sure of the fact that Microsoft is working a lot more on language research than Apple and don't confuse the docs on MSDN with the way they do their work inside.
See :
http://en.wikipedia.org/wiki/C%CF%89
http://en.wikipedia.org/wiki/Spec_sharp
http://en.wikipedia.org/wiki/Sing_sharp
http://en.wikipedia.org/wiki/Polyphonic_C_sharp
http://en.wikipedia.org/wiki/Microsoft_Singularity

This isn't so suprising:

• Most C programmers don't bother to check the return of system calls like printf()
• Most C++ programmers have no idea what an invariant is.
• There are a lot more people who can "just put together a database for us" than can tell a company why they do or don't need one
• Most users of computers have little to no security on their machines.

The world at large is uninterested and/or unaware of security when it comes to computers.