
Ritchie language: power of C and convenience of a high-level language - tambourine_man
https://github.com/riolet/ritchie
======
andrewchambers
Looks cool.

My advice to the authors is to take care on the little things. For example,
the compiler segfaults if there is no input and there is no message if
RITCHIE_HOME isn't set. Fixing those things early will increase the feeling of
polish and will probably help keep quality high to the very end.

------
6502nerdface
> There are five core principles behind Ritchie: ... No reserved keywords,
> everything is redefinable.

Why is this a principle? What advantage does it confer? My initial reaction is
that this will result in nightmarish code.

~~~
nostrademons
Makes it easy to build EDSLs. Very often, in an EDSL you want your users to be
able to use a language that's _almost_ like the host language, but has one or
two key constructs redefined.

I'm not sure it's the choice I would've made, but I can see it being very
attractive for someone whose primary experience with programming is designing
a programming language. Back when I was interested in PL design in college, I
was a big fan of this property in languages as well.

------
efferifick
Can someone explain the advantage of compiling to C instead of compiling to
LLVM-IR? I have seen more languages that compile to C than to LLVMIR. It seems
to me that there are a lot of advantages in using LLVM but I fail to see the
advantages of compiling to C.

Thanks

~~~
andrewchambers
Compiling to llvm brings a giant complicated build time dependency and it is
not pleasant to emit it as plain text due to some strange design decisions.

People are also more familar with C, it works on more platforms, and doesn't
require any familiarity with SSA.

I think you only really need llvm when you want to get into debug symbols.

------
Veedrac
I don't like the benchmark grid given.

It's not hard to use fewer characters than Python if you add superfluous
parentheses and don't use any of its higher-level features. Rewriting the
Python code to be roughly idiomatic shaves off a good 100 characters, even
without noticeably changing the algorithm, and that's even with adding some
newlines and the indentation cost that entails.

And, IMHO, saving bytes by not having a #! or by using "1" over "True", or
even "->" over "return, doesn't impress me much.

------
ilek
I don't see why it's <condition> if <statement> and so on.

Seems they want to be SVO just for the sake of it, and not because it's
actually a good idea.

For something that wants type safety like Scala, they don't seem to have put
much thought into their type system which is pretty fundamental.

Statements like point = Point x, y is confusing. Is it the same as Point (x),
y?

Respect either way however, not many people even get to this point with their
own language.

------
fenollp
> type inferred when they are first used and their type cannot be changed
> after that

So, where is the power of C? Where is my void*?

> if, while and for in Ritchie are all such verbs. They are not keywords, as
> you can redefine them, although this is probably not a good idea.

This is the worst idea. Have you heard of C++? Are you really going to read
someone else's code ever?

> Ritchie is whitespace sensitive

I am mixed on this. I think it works great with Python and Haskell, but is
terrible with Ruby…

------
phantom_oracle
Wow, so it finally happened.

The beauty of Python meets the power of C.

I do hope this project lives long and is not abandoned beyond the students
final years at college.

~~~
J_Darnley
> The beauty of Python

> Ritchie is whitespace sensitive

As I thought. No thanks.

~~~
duaneb
If you're still getting stuck up on semantic whitespace in 2015, you must not
use any of:

\+ Python \+ Haskell \+ Javascript \+ Go \+ Ruby \+ Bash

Anything else I'm missing? Whitespace is useful. Figure out how to view it in
your editor and move on already. This is so far beyond bike-shedding it's just
a depressing comment on how much programmers obsess on syntax.

~~~
J_Darnley
God no. Most of those hold no value or any interest for me. Bash only because
it is the default shell. And thanks for pointing out why I should avoid the
others.

Have you never looked at a diff? Massive whitespace changes hide real changes.
Next someone will say "Git has a -w option". To which I say "A diff without
whitespace changes in those languages would be useless". I can't test it,
apply it, or otherwise use it without re-indenting the source myself.

~~~
adrusi
Significant-whitespace languages don't introduce any additional whitespace
changes because most people keep their code in whitespace-agnostic languages
neatly indented anyway.

~~~
J_Darnley
Then I guess you don't work on any projects that only want to see non-
whitespace changes.

------
pspeter3
The Subject Verb Object language design is a really interesting way to parse
and understand code.

------
sritchie
speaking as a Ritchie, I wholeheartedly approve.

