Hacker News Reader

Comment by drvortex | Hacker News Reader

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++ ?

View on HN

> 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).

That isn't really true.

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

Umm, I know how compilers work.

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 turtle at the bottom of Haskell is machine code...mutable non functional machine code that is isomorphic with the Haskell source.

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.

You can have mutable data in Haskell, obviously.

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 agree because I think dismissing Coffee++ as just Python-like syntax also seems to ignore semantics. That was the gist of my remark.

Reply on news.ycombinator.com