Slashdot Mirror

Lambda notation has no place in an imperative language; mixing paradigms is confusing for the vast majority of Java programmers

Really? Common Lisp had it for 30 years now.

And lambdas do not necessarily correspond to a "functional" paradigm. For that matter, paradigms themselves are blurry - they are a rather arbitrary, and very coarse, human classification of much more complicated patterns. If you have ever passed a function pointer to another function in C, one could argue that you're "mixing paradigms".

The Optional class. Instead of checking directly for a null result, you have to unpack every result out of this idiotic wrapper.

It's a good thing, because it forces you to check when you use, while allowing pass-through to be zero-overhead.

Null pointer, which you have to check, but can use without checking, is a flawed concept in that regard due to decoupling of these two operations - which is why NRE or equivalent is one of the most common unintended exception type in Java (and other languages that share the concept, which is most mainstream ones). Even the guy who invented the concept 50 years ago considers it his worst mistake.

What Java could use is a better syntax for making those checks/uses - some kind of syntactic sugar that's more concise than lambdas. Something like "match" from ML would be nice, but probably too unfamiliar to most Java users. Kotlin does the next best thing by making regular null comparisons change the type of the compared variable within one of the branches, i.e.:

var x: String?; // ? means nullable
y = x.length; // won't compile, since String? can be null, and member access is not valid on null.
...
if (x != null) {
// x is of type String inside here, cannot be null
  y = x.length; // compiles, no NRE possible here
}
...
y = x.length; // still illegal
...

which is really the same thing, but wrapped in a way that's more familiar to someone coming from a C-style language.

The rest are (and always have been) operating under the misapprehension that computers are electronic brains or oracles that you can converse with as you would another human being.

I agree with you; also Dijkstra was right about this.

At risk of being modded off-topic I'll also note that this stuff bears implications for whether or not strong AI is possible...

Any AI even remotely intelligent is going to instinctively figure out that there's a killswitch of some kind somewhere.

I don't think it works like that.

In the same sense that Dijkstra pointed out our misuse of anthropomorphizing language regarding computers it is also incorrect to assume determinism (lack of free will) and use just about any part of the English language. Think about it. Almost every single word that has to do with an actor implies or requires intention which requires free will.

There's a wealth of new research going on in Programming Language Theory, with several breakthroughs in the last years bridging the gap between functional and imperative programming.

The other trend in declarative programming is reactive languages like React.js and Flux being applied to user interfaces. This allows for tools like React Native which can abstract away all the spaghetti code to handle events, providing a higher abstraction, including the "debug & rewind" and "live programming" capabilities seen in online "web embedded" environments like Github Gist or JSFiddle.

I expect that, as these techniques mature, they will settle down and allow for development techniques that allow for easy discoverability of APIs without having to learn a particular complex syntax, and better programming by connecting components without the drawbacks and limitations of classic Visual tools.

All these new techniques based in Category Theory are driving advances in mainstream languages - starting with libraries like Linq and jQuery but also Python, Javascript and even C++ adopting lambdas, advanced type systems with auto-inference of types, and libraries with constructs for declarative race-free parallelism such as promises and agent models.

The majority of those techniques are being tested first in experimental languages by researchers eating their own dog food, with Haskell often having its most pure form (see what I did there?). Anyone interested in enhancing the expressivity of PLs may lurk Lambda the ultimage, where guys much more clever than you and me hang around and can give pointers to all the relevant theoretical results.

There's no reason their numbers should correlate to each other at all on GitHub, especially considering neither is a programming language.

This will either interest or agitate you. HTML5 + CSS3 has been proven to be Turing complete. Just to drive the point home, someone's even made the effort to produce a desktop calculator app using only those two technologies.

Since no one answered this question, I did a simple google search which threw up these results :-

Nimrod: A New Systems Programming Language
Category:Nimrod
Consider the Nimrod Programming Language
What I like about the Nimrod programming language
Araq/Nimrod
Nimrod: A New Approach to Metaprogramming
Nimrod: A new statically typed, compiled programming language which supports metaprogramming

I am just a layman when it comes to Wikipedia editing, but it looks pretty substantial to me. It would appear that the complaint that notability requirements are too strict has just cause.

HTML5 + CSS3 is Turing complete, which is the usual criteria.

Picking nits...

1. What problem does this language solve? How can I make it precise?
2. How can I show it solves this problem? How can I make it precise?
3. Is there another solution? Do other languages solve this problem? How? What are the advantages of my solution? of their solution? What are the disadvantages of my solution? of their solution?
4. How can I show that my solution cannot be expressed in some other language? That is, what is the unique property of my language which is lacking in others which enables a solution?
5. What parts of my language are essential to that unique property?

In case I'm missing your sarcasm, CSS (+HTML5) already is Turing Complete

The most depressing thing about Drupal is that http://lambda-the-ultimate.org/ , a website devoted to discussing the latest in programming languages research, is a drupal site. How on earth can a site that decries the unsoundess of C code, and can discuss the relationships of monads to any of three different effects calculi use PHP to run their site? Mind boggling.

> C++ is the spawn of Satan.

The technical term is over-engineered. Instead of fixing the grammar to allow _one_ extra character in order make programmer's lives easier, they would rather fuck around adding every esoteric feature in the kitchen sink that most people never use bloating the language making C++ even _more_ obscure!

i.e.

void Foo(); // prototype
 
// non-brain-dead C++ allows programmers to copy and paste prototypes, the semi-colon is IGNORED ! Don't hold your breath for this one simple change to C++ though ...
void Foo(); // semi-colon is IGNORED! woot
{
}

I give C++ another 20 years before the language designers stop being retarded and provide an exponent operator, get rid of the long long int shit, _standardize_ on pragmas, and have a _proper_ type-safe macro system.

Ranting aside, bringing this back on topic I believe you are referring to the chart of History, Tragedy, and Farce! :-)

Languages . . . . History Tragedy Farce
OOP . . . . . . . Simula Smalltalk Java
Systems languages BCPL C C
Wirth languages . Pascal Modula Oberon
Lisp languages. . LISP Scheme CommonLisp
ML languages. . . ML O'CAML F sharp
Starting with C . C ANSI C C++
C++ languages . . C++ C++11 C#
C# languages . . .v1 v2 v3
BASIC . . . . . . BASIC VB VB.net
Haskell . . . . . Haskell Haskell Haskell

Reference:
http://lambda-the-ultimate.org/node/4112#comment-62497

--
Slashdot's Lameness filter SUCKS ass for listing code, alignment (detects spaces as junk characters!?), and programming language names

Here is an older post about it: http://lambda-the-ultimate.org/node/4476

"Google's new language landed with a loud thud, causing lots of interesting debates about the best place to stick semicolons..." I did not RTFA but a search on the page for "semi" did not show any hits on semicolons. But then again. I know where they can stick their semicolons. But if I write it my post will be caught by the profanity filter.

You could just read http://lambda-the-ultimate.org/ . Slashdot doesn't quite cut it anymore since the great dumbing down of 2008.

There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.

Ditto. The #1 advantage to age is domain knowledge. You need to play this up.

Code monkeys are cheap, but a guy who knows his algorithms and has good domain knowledge is cheaper. Code monkeys will cut and paste, do naive things or write unmaintainable code. According to Alan Kay, on average, 80% of the cost of software development is after the software has been released. This means that in order to beat those odds, good code needs to be written from the start. You should make this case in your job interviews.

For anyone out there doing hiring, here's a tip for spotting good programmers: they tend to work on paper first. Give them a practice problem and see if they can decompose it without a computer. No code needs to be written, just watch the process unfold. Any competent programmer, or one who dares to call himself an 'engineer' should be able to do this in front of you.

Their claim that OOP is "anti-modular" is of course absurd.

No it's not. You're biased because you're used to the cognitive load associated with reasoning about open recursion, higher order programming, runtime type checking, covariance/contravariance and so on.

It seems to me that CMU's made the very obvious decision that today, OO is a tool for craftsmen, not for freshman computer scientists.

No, they are making the point that properly grasping OO principles requires understanding some very advanced concepts in computer science, concepts which are not appropriate for freshman.

Not to dismiss my earlier reply, but I couldn't resist passing this along:

HTML5 + CSS3 is Turing Complete

Neat, apparently Eli Fox-Epstein managed to implement Rule 110 in HTML5 and CSS3 -- check it out

I know it misses the point -- but it's absolutely hilarious given your last post.

If you don't like $FEATURE then don't use it.

I always cringe when I see this statement in a discussion about programming languages. The presence or absence of a particular feature will impact the third-party libraries you use, the code samples and tutorials you come across, and the legacy apps you inherit. Even if you develop in a vacuum, some features can impact you by accident [operator overloading isn't a good example, but implict-conversion-of-numeric-types-to-boolean is].

In $FEATURE desirable or not for a particular programming language? Most always, that's going to be a complex usability/design question answerable by some combination of analysis, research, experience, testing, etc. Read the programming languages weblog or the discussion forums for D, Haskell, etc., to see the level of thought that goes into make these tradeoffs.

Garbage collection interacts very badly with swap. Once your Java program starts hitting the disk, it will stand still for minutes. Bigger memory sizes are solving this problem nowadays.

swap allows on OS to move UNUSED applications / etc off to disk, so they can be restored later to main memory when they need to run. if your system is trying to run an application that's located in swap, that's called thrashing and any application is going to perform like crap.

You are wrong in two subtle but crucial ways here:

1. Swap (or, more accurately named, "paging") allows the OS to move unused MEMORY PAGES to disk. It doesn't happen on a per-application basis as you say; it's finer grained than that. If an application doesn't touch a page in its address space for a long time, that page can be swapped out to disk while leaving the process's active set in memory, freeing up memory for other things—even things that may benefit that one process (e.g., caching filesystem blocks that the process is using).
2. The reason garbage collection interacts badly with swap is that garbage collection needs to touch all of the memory pages in a generation. This means that memory pages that are really inactive often need to be swapped back into memory just so that the GC can look at them—for no good reason, since the objects were not in memory anyway...

I once read an interesting paper on an experiment where they modified a Java VM's garbage collector and a Linux kernel to be more aware of each other and improve performance: Garbage Collection Without Paging. Worth looking at. (There's also an amusing story of how the authors of the papers submitted a patch to get their GC-oriented advisory kernel calls into the Linux kernel, and got rejected by folks who didn't give a damn.)

From 10,000 feet, I'd say that one of the issues is that operating system kernels have been designed for C-style languages with manual memory management, and don't provide any services designed for garbage-collected languages.

A lot of the "benefits" of object-oriented systems had little to do directly with things like data abstraction, encapsulation, modularity, polymorphism, and inheritance.

In the case of Smalltalk (which I do like) they had to do with:
* garbage collection
* a good set of libraries with consistently named functions
* message passing (not quite the same as objects, though usually related)
* good tools including inspectors and debuggers (where you could restart code with corrections)
* GUIs and related support
* a virtual machine
* machine-architecture independent virtual images of computing structures
* version control
* a way of naming functions with keyword syntax where the meaning of arguments was clear
* a full numerical tower including fractions as a special case of representation
* often, an event loop
* probably other good stuff

Visual Basic had some of these even without having pure objects. A language like C++ has none of these even while having objects. Which mix is better depends on the task.

Ultimately, what matters most about object-oriented programming is actually "message passing". Alan Kay has said he misnamed it. He should have called it message-oriented programming. Example:
http://lambda-the-ultimate.org/node/3265
"For me, the bottom line is that modern, mainstream OO languages have been sold to us as a bill of goods. There's really nothing "real-world" about mainstream OO. I believe Alan Kay lamented the fact that he didn't call OO message-oriented programming."

If you do real-time programming or parallel programming, with message queues and semaphores and event loops, in a way, you are doing message-oriented programming.
http://www.google.com/#q=message-oriented+programming

And here is why it is always hard to model the real world as simplistic "objects" because of various data-representation problems (including splitting and joining representations of "objects" as needs change):
"Data and Reality [Excerpts]"
http://www.bkent.net/Doc/darxrp.htm

==== From the preface to the Second Edition of Data and Reality:

Preface to the Second Edition

Despite critical acclaim, outside of a small circle of enthusiastic readers this book has been a sleeper for over twenty years. Publishers have recently offered to market and distribute it with more vigor if I would provide a new revised edition, but I've resisted. Laziness might be seen as the excuse, but I'm beginning to realize there's a better reason.

A new revised edition would miss the point of the book. Many texts and reference works are available to keep you on the leading edge of data processing technology. That's not what this book is about. This book addresses timeless questions about how we as human beings perceive and process information about the world we operate in, and how we struggle to impose that view on our data processing machines. The concerns at this level are the same whether we use hierarchical, relational, or object-oriented information structures; whether we process data via punched-card machines or interactive graphic interfaces; whether we correspond by paper mail or e-mail; whether we shop from paper-based catalogs or the web. No matter what the technology, these underlying issues have to be understood. Failure to address these issues imperils the success of your application regardless of the tools you are using.

That's not to say the technical matrix of the book is obsolete or antiquated. The data record is still a fundamental component of the way we organize computer information. Sections of the book exploring new models including behavioral elements are precursors of object orientation.

The scope of the book extends beyond computer technology. The questions aren't so much about how we process data

http://lambda-the-ultimate.org/node/3133

I don't really see a good solution here, and JavaScript seems like a reasonable trade-off.

I'm not disagreeing with you, but my point is that is a far from optimal approach. HTML 5 and CSS 3 are truly advancing the state of the web; it's time that the code aspect of the web took similarly large steps forward. GWT is just a compromise to overcome the shortfalls of JavaScript. That's fine if you don't care to dream.

Even Python, as much as I love to write in it, is the wrong answer for the web. Really, we need to have a standardized byte-code/virtual machine implemented (gasp, identically!) over all browsers :) Then for your standard situations you could choose whatever you wanted -- Python, JavaScript, etc. And for applications where it was advisable, you could pick Erlang or Haskell, etc., or hell, even Logo, if you wanted! It wouldn't matter! We'd be free to create compiler for whatever language we chose that target that virtual machine.

Projects such as SquirrelFish are great, because I think they will show the world exactly what the benefits of a virtual machine for the web will be. Once projects like it are incorporated into the browser, it is a relatively small step to abstract away from JavaScript and support any language that has a compiler targeting this VM. If you are interested there is a very interesting discussion on Lambda that addressed this and similar projects, and the trade-offs and advantages of different JIT implementations :)

Have you tried concurrency in Java? ... doing it java is pure pain.

Things will change to some extent in Java 7 (though it's still not as seamless as in Go).

>[cut] most memory problems you have are the same ones between Java and Objective-C - over-retention. That's not something GC fixes for you.

A GC *could* help: there has been some research with GC which cooperates with the kernel's virtual memory manager, the main advantage is that memory referenced but unused can be swapped instead of being kept in memory by the garbage collector, see http://lambda-the-ultimate.org/node/2391

Unfortunately this require modification of the kernel's virtual memory manager, so AFAIK the research has never been used :-(

That article is a pile of garbage, and until I see further evidence, I'm going to consider its author the same. Besides managementspeak tidbits like "net-net", the article contains such wonderful truisms as:

In summary, blinding performance depends on removing overhead. Such overhead has nothing to do with SQL, but instead revolves around traditional implementations of ACID transactions, multi-threading, and disk management. To go wildly faster, one must remove...overhead. This is possible in either a SQL context or some other context.

Well, yes, that's true in the same way it's true than an integer is either positive or negative. So?

Then Stonebraker proceeds to end the article with two citations, one of which points to an article he wrote himself!

This other article, well, here's a summary:

A not directly PL-related paper about a new database architecture, but the authors provide some interesting and possibly controversial perspectives:

• They split the application into per-core, single-threaded instances without any communication between them.
• Instead of using SQL from an external (web app) process to communicate with the database, they envision embedding Ruby on Rails directly into the database.
• They state that most database warehouse tasks rely on pre-canned queries only, so there is no need for ad-hoc querying.

Yes, Stonebraker has rediscovered the stored procedure and the shared-nothing architecture. Does he have any original thoughts?

The details are on NICTA's web site. Basically, they have verified that the C source code accurately implements a formal model of the L4 spec. They have not, for example, verified that the C compiler accurately implements the formal subset of C.

Formally verified compilers are still an active research area. Formally verified hardware has at least been around for a while, at least for chips smaller than VLSI.

What you'd like is for the entire stack to be formally verifiable, but we're a long way off that at the moment. Remember, it's only been in the last few years that assisted theorem provers like Isabelle and Coq have been up to the job.

Sure, an implementation could do such type checking, but I dare you to find me one in anywhere near common use that actually does.

For the sake of this argument, I could write one ;)

Put another way, Java is type-safe from this perspective. C is not type-safe even if a particular implementation is. Type safety to me means a guarantee, and since the C standard doesn't make such a guarantee, it's not type safe. Since Java's spec does make such a guarantee, it is.

In the end it all boils down to the definition of "type safe", again. This LtU post has an interesting classification, and the rest of the thread mirrors our discussion in many ways (specifically "type safety" vs "memory safety", or one being subset of another).

Dropping C... for what exactly? We're not talking application level security. We're talking kernel level. That means talking to the bare metal. Even if you implement a microkernel with userspace modules for everything, and with those modules written in something more robust than C, that last crucial bit of code that is the microkernel itself is probably going to end up being written in C with ASM snippets, simply because at some point you need to explicitly state what the hardware is doing.

There's no reason why the kernel has to be written in an "unsafe" language such as C. It has to be written in a low-level language to be usable, sure, but it is quite possible to design a "safe" low-level language. One example of such project was BitC. Don't mind the Lispish syntax - they've used it because they didn't want to waste time on designing a proper syntax, and parsing it. Aside from syntax, this thing is nothing like Lisp at all.

The sad part of it that the project has stalled now because the main guy behind it was hired by Microsoft to work on the prototype of their own next gen OS, which seems to also be built on the same principles, from what little that we know about it.

Guess we can add this one to the list.

Yes, that's a big issue with most GC: they interact badly with swap, note that it's possible to make the GC and the kernel's Virtual Memory Manager cooperate to avoid this, see:
http://lambda-the-ultimate.org/node/2391

Now, as it only works if the kernel's VMM is patched to support this kind of GC, I wonder if swapping won't be made obsolete by memory's low price before this kind of GC becomes used..

That is a great explanation of why NULL is bad.However, note that in imperative languages, NULL can almost always be eliminated. For example, an OCaml function for finding an item in a list could return a string option. In an imperative language, you would throw an exception instead of returning anything at all. For default values, you can use NullObjects.

It's not so easy, unfortunately. The problem with imperative languages specifically is, what to do with default initialization rules? Right now Java default-initializes all fields of a new object to null, and also all elements of a newly allocated array. You can require explicit initialization for fields, sure - take C++ semantics and make them more strict - but what about arrays? A functional approach would be to require an initializer for the array as well, for example, in the form of index-to-value mapping function that would provide some specific value for every element. Good, now try to implement, say, a generic Java-style ArrayList on top of such an array - keep in mind that you have to pre-allocate extra space for new elements in advance, and, since there is no "null", you don't have any reasonable default value for an arbitrary generic type parameter T for those pre-allocated slots. So, it's not all that simple.

Of course, you can still provide a "magic" implementation of ArrayList in the standard library that is implemented in an unspecified, implementation-defined, unsafe-but-proven-correct way, and expose only the API for that. But that's not "neat".

This was actually covered on LtU not long ago, in a post about the very same article.

Ha, I love when some neophyte suggests that I'm the one that needs to learn something. Your ignorance is glaring. Grasshopper, much to learn you have.

Hang out here, ya might learn something. Or seriously, just search for "Object-Oriented considered harmful" or "OOP sucks" or any number of things. Then maybe when you get out of school I will hire you.

Agreed. The web is not a place for applications. HTML is designed for hyper_text_.

A "webapp browser" would essentially be the view and one half of the controller in the MVC pattern. An interesting idea would be to have the browser as an environment for Adobe Adam & Eve scripts: http://lambda-the-ultimate.org/node/563 .

I don't know. I haven't used Python.

You might look at this comparison, or just have a look at some sample code.

Managed code performance is good enough for essentially anything aside from high-performance video games (and even that isn't far off).

Not only it isn't far off, we've been here already. For example, all Unreal games are built on top of UnrealScript, which is largely a Java-like, bytecode-interpreted (not even JITted!) language. Of course the 3D rendering parts and such are still written in C++ (not C, by the way) and marked as "native" classes and methods in UnrealScript.

On a side note, Unreal Engine 3 uses mark & sweep garbage collection, as well.

For the record, here is one of the few LtU arguments that happened on that subject - you might find it an entertaining read.

This LTU discussion has a bit more info, including an explanatory comment by one of the language designers.

It's not another general-purpose programming language. It's a very narrow-domain language specifically designed to fit a certain niche. The fact that among its major influences the language designers list ML, Haskell, and TLA+ might ring a bell.

See this and this for more info.

To understand what specifically they are about, it helps to watch Anders' talk at JAOO. It's titled "Where are programming languages going", but to make more sense out of of it, it's best to mentally rewrite it as "What is the Microsoft language strategy for today" - which makes sense, given that Anders is the guy who "oversees the general programming language strategy for the company" at MS these days. It has a large section devoted to metaprogramming in general and DSLs in particular, among other interesting bits such as FP. If you have a reasonable knowledge of modern language design concepts, you won't hear anything new in that talk, and will probably find the explanations pretty dumbed-down; nonetheless, the interesting stuff is not what's being said so much as it is who is saying it, and in what context (particularly looking for phrases like ".. and this is what we'd like to do in future versions of our platform" - and metaprogramming/DSLs has that).

Perhaps the key statement is this:

"... and certainly, in a static world, we need more modern metaprogramming APIs ... C# 3.0 expression trees is a start, but it is but a start ... We need to get out of the black-boxness of our compilers and turn them into services, the APIs that you can use."

Hm... CommonLisp.NET?

It's not another general-purpose programming language. It's a very narrow-domain language specifically designed to fit a certain niche. The fact that among its major influences the language designers list ML, Haskell, and TLA+ might ring a bell.

See this and this for more info.

To understand what specifically they are about, it helps to watch Anders' talk at JAOO. It's titled "Where are programming languages going", but to make more sense out of of it, it's best to mentally rewrite it as "What is the Microsoft language strategy for today" - which makes sense, given that Anders is the guy who "oversees the general programming language strategy for the company" at MS these days. It has a large section devoted to metaprogramming in general and DSLs in particular, among other interesting bits such as FP. If you have a reasonable knowledge of modern language design concepts, you won't hear anything new in that talk, and will probably find the explanations pretty dumbed-down; nonetheless, the interesting stuff is not what's being said so much as it is who is saying it, and in what context (particularly looking for phrases like ".. and this is what we'd like to do in future versions of our platform" - and metaprogramming/DSLs has that).

Perhaps the key statement is this:

"... and certainly, in a static world, we need more modern metaprogramming APIs ... C# 3.0 expression trees is a start, but it is but a start ... We need to get out of the black-boxness of our compilers and turn them into services, the APIs that you can use."

Hm... CommonLisp.NET?

in the end, procedural programming is simply more intuitive

Maybe that's the reason why you can do procedural programming in functional languages. And monads are the way to do it; they are so important because they provide the bridge between the imperative and functional worlds, keeping the best of both.

If you really appreciate imperative programming, you should learn how monads work, because monads are a mathematical (declarative) description of procedural computations. Monads are used by building a sequence of operations, much like a Unix pipe, carrying state from one operation to the next. (Why defining a monad then, instead of using an imperative language? Because with the monad, you have the definition visible in your program, instead of hidden in your execution engine/virtual machine).

As for the *why* of monads: they are a Design Pattern in functional languages, just like "Observer" or "Strategy" are design patterns in Object-Oriented Programming. If you structure your code according to the predefined pattern, you'll likely get some benefits in terms of flexibility and mantainability.

The benefits provided by monads are close to those provided by Dependency Injection and Inversion of Control in OOP: you can delegate some complex processing into a supporting framework. Then you can build your application in terms of small blocks whose control flow is handled by the framework in the right order, thus helping reusability and simplifying the bookkeeping a lot.

For the *how* this is done, I recommend reading about the assembly line and space station metaphors (in that order), as well as any explanation intended "for imperative programmers". As I said, the structure of a monad is similar to a Unix pipe, but with user-defined types instead of just plain text. The "lift" and "bind" functions are methods defining an interface to comply with the pattern definition (they are a constructor and a sequencer, respectively).

Now that I'm working in academia researching functional programming languages I read feeds like Lambda the Ultimate, comp.lang.functional, PLNews, Topix Programming Languages, Planet Python and Planet Haskell.

Lambda The Ultimate (programming languages): http://lambda-the-ultimate.org/rss.xml

Greg Costikyan (culture): http://feeds.feedburner.com/costik/gXjD

Darius Kazemi (gamedev networking): http://tinysubversions.blogspot.com/atom.xml

Warren Spector (design): http://junctionpoint.wordpress.com/feed/

Tom Forsyth (graphics): http://www.eelpi.gotdns.org/blog.wiki.xml

Christer Ericson (collision detection): http://realtimecollisiondetection.net/blog/?feed=rss2

Erin Catto (physics): http://www.gphysics.com/feed

Duncan Fyfe? (writing): http://www.hitselfdestruct.com/feeds/posts/default

Soren Johnson (design): http://feeds.feedburner.com/Designer-notes

Fun Motion (physics games): http://www.fun-motion.com/feed/

Play This Thing (short reviews & commentary): http://playthisthing.com/allposts/feed

GoGamer (game deals): http://feeds.feedburner.com/Gogamercom48hourMadnessSpecial

CheapAssGamer (game deals): http://feeds.feedburner.com/cheapassgamer

Kotaku (news & commentary): http://kotaku.com/index.xml

Rock, Paper, Shotgun (PC gaming): http://www.rockpapershotgun.com/?feed=rss2

You don't seem to be very clear on the differences between strong vs. weak type systems, and static vs. dynamic types.

Python is strongly typed. In every place where a Python program can have a type error, the result is defined: some sort of exception is raised immediately, and can be handled regularly through the exception handling system, or to propagate uncaught and kill your program immediately and in a clean fashion.

C is weakly typed. Many kinds of type error can happen at runtime that will leave your program in an undefined state, which may continue indefinitely. E.g., you can do pointer arithmetic and read data from random locations in memory, and interpret it as any type you want instead of what it's supposed to be.

Python is a dynamically typed language. A valid Python program may not contain enough information to infer the type of the values that are assigned to its variables at runtime; or, in other words, any variable may be assigned any value of any type, values in Python must be tagged with their types at runtime, and Python runtime systems need to check the types of arguments at runtime are compatible with the types of the operations applied to them.

C is a statically typed language. The C compiler must be able to determine, at compilation time, the type of every variable, and every expression must type-check for a program to be valid. The way C ensures this is by requiring type declarations on every variable and function. However, that's not essential; languages like OCaml and Haskell are smart enough to infer the types of most of your variables and functions without declarations.

Now, having said all that, let's quote you:

Python assumes you know what the hell you're doing, so it won't throw errors if you create two variables, put an Int in each one, and do an Int operation on them, all without declaring a type...It'll figure out the type by context.

The main problem with this statement here is that you're not specifying what you mean by "context" here. There are two kinds of context that could be relevant: (a) compilation context; (b) runtime context. As it turns out, Python (because of dynamic typing) is allowed to use (b) to figure out the type. However, a language like OCaml can also "figure out the type by context," in the very different sense that it can analyze the program well enough at compilation to figure out that the variables are bound to ints, without your telling it. (And to make it more complicated: an implementation of a dynamically typed language is not required to check types at runtime in every case. A technique used by optimizing compilers for dynamically typed languages is to perform incomplete type inference on programs, figure out the types of variables as best as possible, and use this information to remove runtime type checks where the compiler can prove that they will always succeed. See this blog post for examples of people who've tried to do this for Python in various ways.)

However, if you try to multiply an Int by a String, it'll throw the same type errors any other strongly type language will. They call it "duck typing."

The phrase "multiply an Int by a String" turns out to be ambiguous. Most of the people who responded to you thought about it in terms of syntax: "foo" * 7. The thing is that Python overloads the * operator, and dispatches it to different concrete operations, depending on the type of the arguments. What Python does do is, when applying a concrete operation, throw the type errors.

But also, that is not what the term "duck typing" means. Read your own link. What you're mentioning is just plain old dynamic typing--raise a type error at runtime when the tagged type of the arguments does not match the type required by the operation.

Chris Oakasaki on Indentation Syntax. Sorry, but his word carries a lot more weight than yours.

You are right, and I've been telling this for quite a while (for example, my most recent post here).

I have also suggested this in other sites (example: LtU), but the response was "oh no!" and "disaster!"

For me, it's clear that the so called 'standards' for development of web applications are of very low quality: badly thought out, inefficient, without any concern on security. Perhaps if more people recognized this, the community would be pushed to create something better...

It's notable that Scala is expressive enough that you can implement Erlang style concurrency using Actors very easily:
http://lambda-the-ultimate.org/node/1615
http://debasishg.blogspot.com/2006/11/threadless-concurrency-on-jvm-aka-scala.html
and still be running inside a standard JVM.

-Tupshin