Researcher question – what's the point of semicolons and curly braces?

[Joe Duarte via Digitalmars-d]

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.