Ritchie language: power of C and convenience of a high-level language

https://github.com/riolet/ritchie

by tambourine_man • 11 years ago

79 32 11 years ago

github.com

phantom_oracle• 11 years ago

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.

dinedal• 11 years ago

Some of the current open issues worry me, this is a very very early stage project.

I will keep an eye on it and wish it the best, but I feel like Nim is still my go to (pun not intended) for "C speeds but not C level"

rubiquity• 11 years ago

Nim was the first language that popped into my mind as well when I read "The beauty of Python meets the power of C."

p4wnc6• 11 years ago

Julia and Cython are just two of the languages that already achieve this (albeit with their own warts and bumps) and from what I see at the Ritchie page, I think I'll stick with those.

BTW -- speaking as someone who first learned to program in a dynamically typed language and only later saw the beauty of static typing, I would strongly debate the idea that type inference everywhere is a good thing. The benefit of strict static typing is not so much that it allows a compiler to produce fast code -- there are lots of ways to achieve that. The benefit is that by forcing the programmer to type out the type signatures of functions in advance, you force a level of thought clarity and appreciation for the way that different pieces of code have to pass off data or state to other parts. I find it leads to better software not because of the compiler (although a compiler catching your mistakes is great for productivity), but because it makes you think much more clearly.

It's sort of like the habit of writing down your moves in chess. The benefit is that it creates a ritual of thought and reflection, and potentially makes you more careful.

These days, I see code with enforced type declarations and typed signatures as so much more elegant than similar code that, while having fewer characters, conveys significantly less about the programming intention. Those extra characters for type info are not clutter, not by a long shot.

sanderjd• 11 years ago

I find that specifying parameter types, encouraging pure functions, and encouraging small functions is the best formula to be able to reason locally about code, which I think is one of the most powerful abilities in order to not be overwhelmed by large and complicated projects. I find myself increasingly drawn toward languages and frameworks that encourage this sort of programming. Fortunately, I seem to be in agreement with many language and framework authors these days, and I'm really excited about the landscape over the next few years.

J_Darnley3• 11 years ago

The beauty of Python
Ritchie is whitespace sensitive

As I thought. No thanks.

chm• 11 years ago

I also don't see the interest, but with a decent editor this shouldn't be a problem. For the little Python I write, Vim takes care of formatting the code.

duaneb• 11 years ago

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.

girvo• 11 years ago

Y'know, I used to feel the same way. But using a decently configured Vim or Atom, programming in Nim (which is white-space sensitive) has been perfectly fine. Not good, not bad, it just _is_. The language itself is great, too.

6502nerdface• 11 years ago

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.

nostrademons2• 11 years ago

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.

blacksqr• 11 years ago

See e.g. FORTRAN.

vorg• 11 years ago

When there's a close match between a lexical rule and a semantic rule, it's easier to remember how to use the semantics.

Most languages have an arbitrary rule for distinguishing between an identifier (it begins with letter, except for 30 to 80 special cases) and keyword (30 to 80 special cases) which is hard to remember. When the rule is that the first character of an alphanumeric sequence determines whether it references a number (it begins with digit) or identifier (it begins with letter), that's easy to remember. Golang extends that idea by also distinguishing between public (beginning with uppercase) and private variables in this way, but it still falls short on its rule for recognizing the 50-odd keywords and special identifiers.

Languages that have simple lexical-semantic matches enable people to program in it without IDE's or other crud.

pspeter3• 11 years ago

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

sritchie• 11 years ago

speaking as a Ritchie, I wholeheartedly approve.

andrewchambers2• 11 years ago

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.

Veedrac• 11 years ago

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.

efferifick• 11 years ago

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

andrewchambers2• 11 years ago

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.

srean• 11 years ago

As a targets both C and LLVM-IR are quite popular, but I really wish there was a mature target that enabled efficient coroutines cleanly and _portably_. C exposed pretty much every low level extraction of the underlying machine model but left out stack switching, which the PDPs were very capable of.

fenollp• 11 years ago

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…

ilek• 11 years ago

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.

Ritchie language: power of C and convenience of a high-level language

Related Stories