

What if C++ looked more like Python or CoffeeScript? - SupremumLimit
http://cpprocks.com/what-if-c-looked-more-like-python-or-coffeescript/

======
pwang
This is an interesting exercise, but most of the suggestions on the page are
just cosmetic, and do not address the fundamental challenge of C++ - perhaps
the biggest divergence between Python and C++:

A core design principle of C++ is that you do not pay (performance-wise) for
what you don't use. This leads to all sorts of nasty things like object
slicing, law of big 3, template preprocessor hell just to get pseudo-generics.

A core design principle of Python is that you should pay the minimum cognitive
burden for what you are not using. Don't care to customize object dispatch?
Then you don't need to know about descriptors and __slots__ just to write a
simple class.

No amount of syntactic cargo culting is going to bridge this gap. The
whitespace and lack of semicolons is not why people embrace Python. Just as
removing integer types and sensible scoping from C++ won't make it Javascript,
replacing braces with tabs is not going to make it Python.

~~~
sanxiyn
This is obviously not trying to address divergence between Python and C++.
Stop attacking strawmen.

Nobody sane would imagine C++ in Python syntax would appeal to Python
programmers. On the other hand, C++ in Python syntax would appeal to C++
programmers who prefer Python syntax to C++ syntax. I am one of them, and this
is a good try.

------
Qworg
This is the exact opposite of what I want in C++.

The use of characters to clearly delineate code sections and scope is a strong
benefit of C++ over these other languages. They're not a "source of errors" \-
they allow a competent programmer the opportunity to quickly reason about the
structure of the code. If vertical compression is an issue - get a bigger
monitor or an IDE that allows for code hiding.

It is also far better to have a "oops, I missed a brace" error that your
compiler/IDE catches, versus a "man, why does my program keep seg faulting
unexpectedly" error that takes hours to track down since you missed a single
tab somewhere.

~~~
seertaak
> This is the exact opposite of what I want in C++.

This is the exact response I was expecting to go to the top of hacker news --
negative and dismissive. Also, it's nonsense.

Go to a Python mailing list, and count the number of emails complaining that
"my program keeps seg faulting unexpectedly" due to "missing a single tab
somewhere". Can't find any examples? Well, it would appear that Python coders
are more competent than you.

Alternatively, perhaps our eyes and brain are intrinsically wired to easily
detect vertical and horizontal lines. Maybe that's why they're so prominent in
design -- just a thought. And maybe that's why all C++ programs have some
scheme of indentation to denote scope anyway.

I really hate that whenever someone makes a proposal for a language, the
zealots, be they lisp or C++ or whatever, immediately come out of the woodwork
to heap scorn upon the idea. Personally, I think the kind of change proposed
by the OP (with a few modifications) would be really nice, and would give the
language a more Pythonic flavour, which isn't called executable pseudocode for
nothing.

> If vertical compression is an issue - get a bigger monitor or an IDE that
> allows for code hiding.

You need to listen to yourself type.

~~~
nightski
Maybe this is true, but I am just having a real hard time believing a fresh
syntax is going to solve any real problems with C++. To do that a language
with better semantics is needed, which is a much tougher problem being tackled
by D, Rust, etc...

------
claudius

      $ wc -c a.cpp t.cpp 
      399 a.cpp
      380 t.cpp
      779 total
      $ cat t.cpp 
      #include <iostream>
      using namespace std;
      
      namespace utils {
        template<typename T> T square(const T& n) { return n * n; }
      }
      
      int main() {
        int input(0);
        auto message("Please enter a positive number");
      
        cout << message << ":\n";
        cin >> input;
      
        if (input>0) { cout << "Result: " << utils::square(input) << "\n"; }
        else         { cout << message << "\n"; }
      
        return 0;
      }
      $ cat a.cpp 
      #include <iostream>
      using namespace std
      
      namespace utils
          template<typename T>
          auto square(const T& n)
              return n * n
     
      int main()
          auto input = 0
          auto message = "Please enter a positive number"
      
          cout << message << ":" << endl
          cin >> input
      
          if input > 0
              cout << "Result: " << utils::square(10) << endl
          else
              cout << message << endl
          return 0
    
    

I am not entirely convinced that t.cpp has any more or less noise than a.cpp
and where exactly there is any sort of gain from this – I had more trouble
indenting the second piece of code properly for HN than the first.

~~~
SupremumLimit
If you squint in just the right way so as not to see any of the braces,
semicolons and parentheses in the first example, then naturally we are going
to disagree about the amount of noise :)

~~~
claudius
Maybe my visual capabilities are just more limited than yours :) That said, I
wouldn’t call things like ‘end of statement’ or ‘end of this block’ _noise_.
They have very real effects and using ; and } over "\n" and "\t" seems a
decent choice. Natural languages have ".", "," and ";" for a reason, too;
although one could argue for paragraphs to be roughly (but only roughly!)
block-equivalents and inherently whitespacy.

------
flohofwoe
This looks neat on first glance and on small code samples, but I've had so
many messed up whitespaces after merging branches that in the real world this
would be just another way to shoot yourself in the foot. I really like python
for scripting up into the 10k lines-of-code area, but for bigger projects (and
teams with more then - say - 3 coders) I wouldn't even consider a dynamically
typed language, let alone a language where intendations and newlines are
language constructs.

I don't really find the example at the end of the article much more readable
(even though it "cheats" a bit by using the C++11 auto keyword and range-based
for loop), on the contrary, the white space on the left side looks more messy
then on the right side to me.

C++ code which has a lot of STL containers and complex templates _does_ look
ugly though, that's why I prefer to either not use this, or hide it under
typedefs and decltypes. I also don't like the new auto keyword very much, the
compiler SHOULD complain when someone on the team changes types around.

------
keypusher
I love Python and it is one of my primary development languages, but I have
come to believe meaningful indentation was a bad idea. As Rob Pike said in the
recent Go conference keynote: "It is a profound mistake to have your semantics
depend on invisible characters". Braces also make parsing and auto-formatting
easier and better. It seems Go struck a good balance with with a newline after
statements (no semicolon necessary), and braces for all structures.

~~~
gohrt
Newlines are invisible characters.

Tabs+spaces are the real problem with python indentation. It should be a
compiler error to mix them in a file.

~~~
shurcooL
I would not classify newlines as invisible characters. Except maybe the last
newline in the file.

Invisible characters are those that you can't tell if they're present or not.
Assuming there are visible characters following, a newline can be clearly
"seen" because it shifts the remaining text one line lower.

~~~
Someone
You must have never encountered a file with mixed line endings.

Somebody should design an esoteric language that uses LF to separate
statements in a block and CRLF to separate blocks.

Alternatively, find a unicode line break character that editors recognize, but
C doesn't treat as a line break, and sneak it into a source file at a
strategic place to introduce a back door.

~~~
gmjosack
Semi-related, you might be interested in Whitespace

[http://en.wikipedia.org/wiki/Whitespace_(programming_languag...](http://en.wikipedia.org/wiki/Whitespace_\(programming_language\))

------
mrbrowning
> _I’m quite fond of languages with minimal syntax._

Maybe this is the Lisp enthusiast in me, but as someone who does the bulk of
their workaday programming in Python I still feel compelled to say that it's a
perverse worldview that holds up Python as an instance of "minimal syntax."

~~~
SupremumLimit
Well, I didn't say that Python is the pinnacle of minimalism :) However, it's
hard to reduce C++ to Lisp syntax without completely changing the nature of
the language.

------
sanxiyn
This doesn't seem to address
[http://en.wikipedia.org/wiki/Most_vexing_parse](http://en.wikipedia.org/wiki/Most_vexing_parse)
at all.

On the other hand, if you don't care about backward compatibility, I guess
completely eliminating constructor syntax in favor of C++11 uniform
initialization syntax is a good solution as any. (But maybe curly brace haters
won't like that solution.)

~~~
jeorgun
I'd be fully in support of that if it weren't for the fact that
initializer_lists end up causing their own sets of issues.

For instance, type-inference is completely borked:

    
    
        auto foo{tmp};
    

results in

    
    
       std::initializer_list<decltype(tmp)>
    

Not to mention issues such as

    
    
        std::vector<int>{ 3, 4 } // => [3, 4]
    

vs

    
    
        std::vector<int>( 3, 4 ) // => [4, 4, 4, 4]
    

Unless some alternate syntax is proposed for initializer_lists, the old
syntactic forms are kind of indispensable.

~~~
nly
There's a proposal to fix the 'foo' case but, as an outsider, it's unclear
whether it will be fixed in time for C++14. [0]

The vector case is unfortunate, but I'd personally argue the defect is in the
vector class. There's no significant performance advantage, that I can see, to
the (n, T) construction over a default construction followed by v.resize(n,
T).

[0] [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n392...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html)

------
porges
This looks really error-prone to me.

Have you looked at previous attempts, such as SPECS?
[http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...](http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html)

~~~
kcbanner
Any python developer will tell you they have accidentally indented or un-
indented some code, and that error took hours to find

~~~
3d7718844
I've been programming in Python for 4 years and I've never spent hours trying
to find an indentation error.

It comes up, sure, but no more frequently than any other syntax error in a
different language and there are usually dead giveaways indicating what
happened. Most IDEs/editors have options to view whitespace characters, so if
you're worried about encountering a bug from this you can always enable that
feature.

It's really a non-issue.

~~~
Walkman
totally agree with you

------
minaandrawos
How about exploring a modern language like Google GO (Golang)? Go was designed
exactly for the purpose of having a performance that could be compared to some
extent to powerful languages like C/C++ and in the same time maintains a
Python like syntax. I have programmed with both languages and I'd say by the
end of the day both languages are powerful tools in your developer's toolbox
however Go is a very attractive choice when it comes to rapid to develop
performant applications

~~~
lukeholder
I agree, would be an interesting to see the same experiment done for Go. Will
have a stab!

~~~
SupremumLimit
As somebody posted in another comment, it looks like it's already been done:
[https://news.ycombinator.com/item?id=7444459](https://news.ycombinator.com/item?id=7444459)

------
srean
It has not been mentioned in the original post or the comments yet, so here is
a working prototype of a similar idea
[https://github.com/pfultz2/Pythy](https://github.com/pfultz2/Pythy) (for some
specific value of working, you will need Clang)

Its birth lies here _Having it all: Pythy syntax for C++_ [1]. It was a nice
read. Unfortunately cpp-next seems to be down right now. Let me try to find it
in Google's cache or internet archive.

Here it is [https://web.archive.org/web/20130820172127/http://cpp-
next.c...](https://web.archive.org/web/20130820172127/http://cpp-
next.com/archive/2011/11/having-it-all-pythy-syntax/)

[1] [http://cpp-next.com/archive/2011/11/having-it-all-pythy-
synt...](http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/)

~~~
SupremumLimit
I think generic lambdas provide for this in C++14.

------
shurcooL
This really reminds me of a similar attempt for Go, called iGo [1]. There are
a lot more cases to handle for C++.

[1]
[https://news.ycombinator.com/item?id=7444459](https://news.ycombinator.com/item?id=7444459)

~~~
SupremumLimit
Interesting, thanks for the link. This does look quite similar!

~~~
DAddYE
Yep, reading your article I found myself in it and "go" is very simple
(compared to c++) however main issue is the readability of function calls with
multi lambda arguments.

------
616c
Since no one has said so yet, and I quickly searched the comments, the answer
is basically a language called Nimrod.

It shows up here a lot, and not many people use it still. Time will tell.

------
sanxiyn
This doesn't seem to allow single line if or while statements, because
parentheses are optional.

I like single line if when it is appropriate. (Python allows single line if by
using colons.) Apart from my taste, C preprocessor macros can't expand to more
than a single line, so this seems to prevent macros expanding to contain
control structures. Is there an easy fix?

~~~
SupremumLimit
You could do it by separating the body with a semicolon:

    
    
        if something_is_true(); log("warning!")
    

I haven't really considered the preprocessor as I prefer to avoid it as much
as possible.

~~~
sanxiyn
This doesn't work. "if a; if b; c; d" is then an ambiguous parse to both "if
(a) { if (b) { c; d; } }" and "if (a) { if (b) { c; } d; }". If you decide to
parse one way, how do you write the other one in a single line?

~~~
SupremumLimit
I'd make this parse as "if (a) { if (b) { c; d; } }" and leave it at that. One
of the reasons for significant indentation is to discourage this kind of code
layout because it's hard to read.

~~~
sanxiyn
Okay, concretely, I'd like to see a translation of this real-world C++ code
(taken from V8):

    
    
      #define RETURN_OBJECT_UNLESS_EXCEPTION(ISOLATE, RETURN_VALUE, RETURN_EMPTY) \
        if (!__allocation__.IsRetry()) {                                          \
          __object__ = __allocation__.ToObjectChecked();                          \
          if (__object__ == (ISOLATE)->heap()->exception()) { RETURN_EMPTY; }     \
          RETURN_VALUE;                                                           \
        }

~~~
SupremumLimit
This seems to be missing backslashes. I haven't considered how to deal with
preprocessor macros, but the _if_ statement converts very simply:

    
    
        if !__allocation__.IsRetry()
            __object__ = __allocation__.ToObjectChecked()
            if __object__ == (ISOLATE)->heap()->exception(); RETURN_EMPTY
            RETURN_VALUE
    

This isn't ambiguous like the example you suggested before.

~~~
sanxiyn
That doesn't work, because if statement is inside preprocessor macro and must
be in a single line.

~~~
SupremumLimit
I see what you mean. Yes, the _if_ in a macro is a problem. I haven't
addressed macros, that's a whole different can of worms.

------
ASneakyFox
Python is easier to type but its harder to read. Ides that help you code
faster are a better investment of time than a language that's easier to write
in notepad. My ide does brackets and indention for me. I never think about
them. They're just there for my reading pleasure. I like these things its
easier to follow the code when reading.

------
zvrba
If you think that syntax is THE problem that needs to be solved to make C++
less error-prone, you don't know shit about C++.

------
andrewstuart
Why can't IDEs just hide all the brackets and replace them with sane
whitespace structure?

~~~
marvy
If your only goal is to read the code, then they could probably do it, after
working out a few minor issues. The question is, how do you enter new code?
With braces, which vanish as you type, or with whitespace, which means the
braces exist only on disk? And if you mess up, how do you cope with the
compiler errors?

------
Executor
I would support this if you can remove header files. It is hell to manage
function prototypes. Let the compiler figure that out with "public/private"
keywords.

------
pskocik
What if I wanted to take a peek at this article without giving up my email
address? If only there was an easy way to stop JavaScript from blocking my
page view with that subscribe request …

------
drivingmenuts
If it looked more like Python or CoffeeScript, then it wouldn't be C++
anymore.

~~~
SupremumLimit
My goal was to make the code remain recognisably C++, but remove some of the
noise.

------
jbeja
Nobody needs that

------
kcbanner
Seems like a step in exactly the wrong direction

