On Tuesday, 3 May 2016 at 22:17:18 UTC, cym13 wrote:
In my opinion putting commas at the end of a line is useless: if it happens at the end of each line (not counting closing-braces ones) then the effective quantity of information brought is null, and in more than one case chaining instructions on the same line (the only utility of commas) ends up being a bad idea. But it's part of those things that have such an inertia that you just wouldn't ever had heard of D if it hadn't had it I think. Having commas was not decided by their intrinsic usefulness but by the choice to target the C/C++ market.
Good point that line-ending semicolons carry no information if they're on every line (I assume you meant semicolons instead of commas).
An important point that I think is undocumented: text editors don't let you inhabit a new line unless you press Enter on the line above. In other words, you can't have a new line by using the down arrow or some other means. When I first learned programming, I was stumped by how a compiler was line-aware, how it knew when a line was truly ended, and what counted as line qua line (I wrongly assumed you could down-arrow to a new line). It's an invisible character by default, and they don't tell you how text editors behave. This comes up a bit in Markdown and in how people are inconsistently defining a "hard" vs "soft" line break.
But Python sacrifices a *lot* of performances to do that. D has its own way and different goals. Being performance-friendly is one of them and that sometimes gets you with long functions and ugly hacks. When it comes to that having curly braces (well any kind of delitmiter really) is a great thing.
It's not clear how curly braces deliver better performance. Anything expressed with curly braces can be expressed without them -- i.e. you could design a language in which that were true. Walter mentioned the issue of redundancy, which seems reasonable, but that doesn't bear on the performance issue. A good example of a non-curly brace compiled language is Crystal, at least last time I checked. Python loses a lot for being a text-executing interpreted language. What an interpreter does -- in comparison to a JIT compiler -- is wildly underdocumented. The standard answer to a lot of people on the web asking for an explanation is that a JIT compiles down to native code or machine code, while an interpret just interprets the code, or sometimes you'll see "executes it directly". Big gaping hole on how it gets down to machine code. But starting with text is crippling. I love Walter's decision to have pre-compiled modules instead of text headers -- I didn't realize that C compilers were literally parsing all this text every time.
Python could get some big wins from a well-designed IR and follow-on back-end code generator, or a JIT, or some combo. This is obviously not a new idea, but no one seems willing to do it in a professional, focused, and expensive way. Unladen Swallow was weird in that you had a couple of kids, undergrad students who had no experience trying to build it all. It's weird how casual and half-assed a lot of software projects are. If I were trying to do this, I'd want to assemble the Avengers -- I'd want a large team of elite software developers, architects, and testers, enough to do it in a year. That's a rare setup, but it's how I would do it if I were Microsoft, Google, FB, et al -- if I were willing to spend $20 million on it, say. Pyjion might become something interesting, but right now it looks pretty casual and might be the kind of thing where they'll a lot of outside open-source developer help (https://github.com/Microsoft/Pyjion). Pyston is only focused on Python 2, which is rearview mirror thing.
By the way, anyone should be able to create a version of C, D, or Go that doesn't use curly braces or semicolons, just by enforcing some rules about indentation and maybe line length that are already adhered to by virtue of common coding standards (e.g. blocks are typically indented; and I realize Go doesn't require semicolons). If we looked at typical code examples in almost any language like C, C#, D, Java, Swift, and we systematically encoded their meaning, reducing them down to a concise and non-redundant form, we'd find lots of redundancy and a lot of textual dead code, so to speak. This would be true even without semicolons and braces. There's still a lot for a compiler or any interpretive agent to go on.
