Show HN: Coffee++, idea for a language that compiles into C++

> I'm definitely upvoting this, as i think this is very much the right direction (I'm actually working on something similar).

C++'s boilerplate is maybe 10th on my list of major beefs with the language, so to me it seems to have the wrong priorities. Still interesting to see a take on it though.

> 1. using := instead of = is straigh up worse. No way i'd use 2 characters instead of 1 for an operator that common.

Less typoing "==" as "=" and your code still compiling though, and it's ":=" instead of "auto ... =" - so 4 fewer characters.

> 2.i don't think the eventuality of bugs really justifies the repetition of public and private at EVERY SINGLE variable, that's a lot of repetitions

C# got me used to that!

> 1. using := instead of = is straigh up worse. No way i'd use 2 characters instead of 1 for an operator that common.

Maybe you have mistaken := as the assign operator? It rather is for local variable declaration:

foo := xy

becomes

auto foo = xy;

so it's 2 characters instead of 7 :)

> 2.i don't think the eventuality of bugs really justifies the repetition of public and private at EVERY SINGLE variable, that's a lot of repetitions

Good point. My thinking was that Java/C# seem to be fine with that decision. Also the : after public/protected/private clashes with Coffee++'s Python-like scopes.

> 4. (also a lot of other minor things that don't add meaning, like (int argc, char argv) that really shouldn't be there)

The reason for keeping stuff like (int argc, char argv) is that I want this to be used in C++ projects in the sense that you could have some Coffee++ files and some C++ files together with the only difference, that your build system translates the Coffee++ files to C++ before compiling. But I'm open to replacing other annoyances of C++. Maybe

    int main(std::vector<std::string> foo):

could be translated into

    int main(int argc, char** argv) {
        std::vector<std::string> foo;
        for (int i = 0; i < argc; ++i) {
            foo.emplace_back(argv[i]);
        }

;)

Not saying this is the point of Coffee++, but I thought about doing the same thing for Golang -> JavaScript, specifically for React Native. I was willing to use a subset of Golang to get a 1:1 transpile.

My reasons were gaining that my tooling, testing, etc was very Go centric, yet React Native offered a compelling solution to mobile UI development.

Currently I'm choosing not to do it, mainly because JSX is a very nice syntax for React, compared to chaining Go functions ad infinitum. Regardless, I'm just offering some perspective as best I can. Making their own language though is a bit different than my example, because they're just changing syntax, not re-using tooling.

> But if it compiles one to one to C++, then it is just a different and more Python-like syntax for C++ ?

Yes. In some cases this is an advantage as C++ can become very verbose with unnecessary repetitions (manually synchronize signatures in .hpp and .cpp files) or stuff that can result in bugs after merges (public/protected/private not explicitly written in front of each method).

Every programming language can be described as "just a different syntax" for some other language, e.g. "C is just a different more Algol like syntax for assembly language." The differences in syntax is what can make a language useful (or not useful, e.g. Brainfuck).

Because of existing C++ code. Most languages only have a C FFI - not C++. With Coffee++ you can just mix C++ and Coffee++ source files.