I disagree. "Lisp syntax" is almost a misnomer, as there's so little of it. Pretty much the only thing you're guaranteed is that () are for grouping, and spaces are separators (and even that is not necessarily true in CL). Everything beyond that is up to the DSL in question, and people can and do get overly "creative" with the syntax such that it's not simple or obvious to read at all.

Java anon classes aren't quite the same because of the lack of "var" or similar - so you can implement interface members or override base class members, but you cannot introduce new members that can then be referenced outside of that object.

OTOH, C# anon classes don't support base types...

I'm not necessarily saying that begin..end is better, just that it's an obvious alternative. Personally, I don't mind {}, though I think that it's really redundant, and the proper way is to treat everything as an expression, in which case semicolon becomes a sequence operator (i.e. "a;b" means "evaluate a, then throw the result away and evaluate b" - like comma in C), and you just use parens to group things where needed.

If you read my post, you'll see that it specifically calls out "import static", and why it's not really good enough.

Scala's problem, I think, is not that it has operator overloading, but that the conventions around the language encourage its use for DSLs. C++ also has this problem, but to a significantly smaller degree, and C# doesn't have it at all.

And how is this different from setX?

In case of Java, there's no clear indication where the code starts, either. Any class that has a static method called "main" can be the entry point, which is why you have to provide the name of the class to Java when starting your program. It's not any different in Python - you provide the name of the startup script, and the code that is in that script on the top level is your entry point, starting with the very first line of it. This seems a very straightforward definition to me: when you tell it to run X, it starts to run X from the beginning of X.

BTW, note that there is a difference here between "outside of the class" and "global namespace". There's really no such thing as "global namespace" in Python - every .py file is implicitly a package with its own namespace. If you want to access something from another package, you have to import it and reference things using their fully qualified names (or import those specific things).

And Java approach to forcing everything into a class doesn't really do anything to solve that, it just makes it long winded, because now all those globals are statics in some class called "Utility" or some such.

Fundamentally, some kind of global variables is plainly necessary, which is why Java offers them in a thinly veiled form as statics. It's semantically not different from globals at all, except that it forces you to spell out a prefix (class name) every time. And no, it's not there for namespacing purposes, because Java already has packages for that. Static classes just add another useless layer that is kinda sorta like packages but not really.

Consider something like math functions or constants like pi. In Java, these are put into the Math class. Why? That class never has any instance of it created. A proper design would be to put them into something like java.math package, and the only reason why they're in a class instead is because a package cannot directly contain methods and fields. So that restriction is directly contrary to good API design here, and necessitates hacks like introducing a class that is functionally a package for all effective purposes (but still different syntactically, both when defining it and when using it), and the users are forced to write Math.abs, Math.PI etc for no good reason. Later on, because of the verbosity and the disparity, they've added "import static", which is basically another hack - it makes static classes look even more like packages, and finally lets API clients write "abs" and "PI" without qualification, but many differences still remain.

IMO, the proper approach here is rather to educate people as to why global shared state (regardless of its lexical scope) is usually not the right thing for large applications, excepting certain things such as common constants and utility functions.

And, of course, for many small applications (command-line tools and such), it's actually a valid approach entirely - there's no need to make things any more complicated than they need to be, and when what you have is a script that's 3 pages long end to end, it's actually easier to read the code when it uses globals in many cases, then it is to follow the data flow when you explicitly pass everything from function to function every single time.

My point is basically that Java forces unnecessary and redundant structure due to the requirement that packages can only contain classes, and anything else must be contained in a class.

C# went through this in 2008. It's still around, and practice has shown the fears to be unfounded. Lambdas are heavily used in idiomatic C# today, and many libraries (e.g. ASP.NET MVC) rely heavily on them, and it didn't really have any detrimental effect on code quality.

Up until C# 3.5 (when lambdas and LINQ first showed up), C# really wasn't all that different from Java; though it already had non-erased generics, which, I think, are a huge benefit if you use them heavily. It was really 3.5+ that started adding new and very distinct features at a fast pace.

By the way, one thing that GP forgot about (possibly because it's not really used all that much) is "dynamic", which is basically opt-in duck typing.

Lambdas are cryptic in the same way classes are cryptic: it's an unfamiliar concept to many people because they haven't met them yet, but it's also a very powerful concept that makes it possible to write neat, concise and readable code when learned. C# developers were similarly bitching when lambdas were introduced there in 2008, but by now everyone uses them and loves them.

The notion of distinct paradigms is bullshit, anyway. There's no reason why OOP and FP (and other stuff) cannot coexist in the same language.

Thing is, there's no reason to have a class for the program (that doesn't actually ever have any instances), and for main to be a static method of the class. That class is completely unnecessary scaffolding, that exists solely because the designers of the language wanted to "simplify" by saying that everything is a method in a class. Every Java application has the same "public static void main" line in it, exactly identical to any other such line. That is a clear indicator that it is superfluous.

In practice, this has an opposite effect for pedagogical purposes, since you have to either explain all those things before getting to something as simple as "Hello, world", or else just handwave them away by saying something along the lines of "you just always type this exact same thing when you want to do this; we'll go over what it actually means later".

In contrast, take something like Python. It does have namespaces, and classes, and objects (and indeed, unlike Java, in Python "everything is an object" is actually true!). But you don't have to know any of that to write or understand "Hello, world", because it also allows for global functions, and for code outside of functions, and it automatically imports the builtins namespace with the most frequently used functions that are useful to get started. So you can explain the basic concepts like variables, conditionals and loops to people first, and then gradually introduce them to procedural programming with functions (and locals and recursion), and then to OOP with classes, and to code structuring with namespaces. And at all levels in this progression, the new skills learned are purely additive - once you learn classes, you can do classes, but things that make more sense as global functions still remain global functions.

It's also nice for app development because you can use the most basic instruments that are necessary for the task at hand. If you're writing a simple console app that reads input, processes it, and spits the result out, you probably don't need any classes, and the language doesn't force you to write any just because.

It seems that OP is confusing Algol-60 with Pascal.

From the standard input. Which is called "standard" for that exact reason.

By using the default conversion that is appropriate for the current locale (note that this is actually implicit in the Java code, as well).

What a stupid question. Because for the purpose of this discussion, we're talking about reading an integer, and nothing more.

Probably the sole valid complaint here. Though the notion of output parameters is not exactly obscure, it's nice when they're spelled out as such at call site, and not just when defined. For example, as in C#: read(out x).

Not really, it's just a way to tell the function what type to read. Since you've already explicitly spelled out that type when declaring the variable, there's no reason to repeat it again when reading into that variable. DRY and all that.

Virtually anything; for example, "begin" and "end" as in Pascal; or implicit beginning of the block and "end" as in Lua; or parentheses in languages that don't distinguish between expressions and statements, like OCaml (OCaml additionally defines "begin" and "end" as aliases of "(" and ")", though).

If you're willing to go that far back, I would dispute your assertion that they were always "the party of grownups who have jobs & families, understand cause/effect, understand TAANSTAFL, and participate much more deliberately in the political process". As far as I'm concerned, there's virtually nothing in common between GOP in 1875 and 1975, much less Reagan's times to today.