What if C++ looked more like Python or CoffeeScript?
cpprocks.com
cpprocks.com
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.
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.
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.
I would argue that whitespace sensitivity makes those kinds of errors less likely, not more. Curly braces everywhere lead to a lot of visual noise, and can obscure what the code is doing. Consider the classic C syntax error:
if (foo > bar)
printf("Hey!\n");
return foo;
return bar;
With whitespace sensitivity, this would do what you think it would. With curly braces, it's misleading.No. There are two braces per block and as long as you are consistent and always use braces even for single-statement if(){}, you need to miss two braces for equivalence with missing one tab. You also get the benefit that the editor can trivially re-indent your code without actually changing its meaning.
TBH, the real problem with C is not the braces - its that braces are optional.
Python 3 deals with this by throwing a warning about inconsistent use of tabs and spaces before it even finishes parsing the file (so basically before runtime). There's no reason why any other language can't do the same.
Clearly we both can't be pleased. ;)
[1] Except in Lisp.
- editors that allow one to set tab width different from 1.
- editors, compilers, and OSes that distinguish tabs from spaces in any way (display of invisible characters, search).
- revision control systems that do not randomly replace spaces by tabs and vice versa in all text files.
Back in the 1970s, I chose tabs to save bytes in my text files. Today I feel like I can afford the extravagance.
Yeah I am not entirely agreeing with "source of errors". Usually it is other things like inconsistent syntax or (I am just making it up here) error intolerant syntax. And by that I mean things like:
* I am allowed to use single '=' and '==' in a conditional (in C++). Program still compiles, runs and probably doesn't do what I expect.
* In Python, if I leave an extra , at the end of a variable it creates a tuple ( x = a vs x = a, ). Program still compiles and runs but probably doesn't do what I expect.
* In general think of the time you spent hours and days hunting a bug that ended up being a one character error like above.
In either case, it would be nice if compilers or linters should warn you...
But anyway, I don't think as you were saying, {} are necessary a cause for more or less "errors"
But, { } are a source of visual noise. I think it clutters the screen and it provides an opportunity for strange syntax. When I scan code quickly I don't match up parentheses, I look for nicely formatted and indented blocks of code first. Whitespace and indentation is best for that.
There shouldn't be 100+ page style guides for how to format a language, it should have a one, best, clearest, default formatting and it should be used by everyone. That, I found after programming Python for almost 10 year now, is very helpful.
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.
I often wonder if contrarianism is so prevalent in community discussions simply for the sake of disagreement or to provoke negative emotion. It's completely counter to constructive criticism.
Although to be fair, there are some comments to the contrary that at least make a passing effort to explain what they don't like about the suggestion and why they dislike whitespace languages in general, so I can't tar everyone with the same brush.
That said, considering some of the outright vitriol, I almost feel like someone ought to implement it on principle alone.
Python scripts segfault?
while (i < 100); //loop body is empty
{
// random unnamed block instead of loop body
}
Oh, and it's kind of difficult to get a bigger screen on a laptop. $ 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.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.
Tabs+spaces are the real problem with python indentation. It should be a compiler error to mix them in a 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.
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.
http://en.wikipedia.org/wiki/Whitespace_(programming_languag...
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."
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.)
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.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...
Have you looked at previous attempts, such as SPECS? http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...
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.
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...
[1] http://cpp-next.com/archive/2011/11/having-it-all-pythy-synt...
It shows up here a lot, and not many people use it still. Time will tell.
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?
if something_is_true(); log("warning!")
I haven't really considered the preprocessor as I prefer to avoid it as much as possible. #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; \
} 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.