I'm definitely upvoting this, as i think this is very much the right direction (I'm actually working on something similar).
After reading into it, I think for me personally it really isn't enough though.. These are some of the reasons why I'll never use it :
1. using := instead of = is straigh up worse. No way i'd use 2 characters instead of 1 for an operator that common.
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
3. If I have to learn a new syntax, it really has to make my life easier: this Definitely includes automatic generation of all needed include statements (or import, whatever). I know there is some work to do to make it happen, but we definitely are able to do it in 2017. No way imports are something we should be doing by hand anymore
4. (also a lot of other minor things that don't add meaning, like (int argc, char argv) that really shouldn't be there)
Of course I hope it's clear that this is my very personal point of view :)
> 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]);
}
> 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
What is the point ? If it is just academic curiosity that is fine. But if it compiles one to one to C++, then it is just a different and more Python-like syntax for C++ ?
> 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).
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.
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).
There are clear differences in semantics between most programming languages. C is not just a different syntax over assembly: It has a type system, and obviously restricts what you can do (e.g. C abstracts over the registers)
A higher level language can be translated to a lower level one, (hence why Haskell can exist), but saying it's a purely syntactic transformation is extremely reductive.
A Haskell program compiles to something that uses places and mutates what is stored in those places because a Haskell program ulitimately runs on a machine designed with the Von Neumann architecture.
Reduction is what compilers do. In the old days C was often compiled to assembly (at least the parts that were not in-line assembly) and the assembly was assembled and all of it got linked into an executable. Crenshaw's classic Let's Build a Compiler is a great way to see how it was done even if it is written using Pascal. http://www.stack.nl/~marcov/compiler.pdf
C is compiled to still compiles to assembly, but usually (GCC) your compiler driver handles assembling, linking etc.
Haskell is translated to core (basically a simplification of a small subset of Haskell), then the STG(The abstract machine, spinless-tagless-Gmachine) then Cmm (Basically unsafe C) then LLVM.
The machine code can still be basically functional. GHC doesn't use any mutable data unless you tell it to, it generates and then immediately collects garbage rather than reuse mutable memory.
Garbage collection, RAII, dynamic typing, template metaprogramming, macros, type inference, exceptions ... are not "syntactic" features of programming languages.
Those are semantic features, that happen to have a syntax.
Reducing programming languages to syntax+isTuringComplete is missing the forest for the trees.
I don't think this is a good idea. I don't like c++, many people don't, so if we're making something better, why make it depend on c++? Why not use a completely _new_ language, like D or nim?
After reading into it, I think for me personally it really isn't enough though.. These are some of the reasons why I'll never use it :
1. using := instead of = is straigh up worse. No way i'd use 2 characters instead of 1 for an operator that common.
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
3. If I have to learn a new syntax, it really has to make my life easier: this Definitely includes automatic generation of all needed include statements (or import, whatever). I know there is some work to do to make it happen, but we definitely are able to do it in 2017. No way imports are something we should be doing by hand anymore
4. (also a lot of other minor things that don't add meaning, like (int argc, char argv) that really shouldn't be there)
Of course I hope it's clear that this is my very personal point of view :)