A Short List Of Not So Well Known, 'C-like' Scripting Languages

A Short List Of Not So Well Known, 'C-like' Scripting Languages

The following non complete list contains some exotic but interesting 'C-like' scripting languages. The list has been inspired by recent comments on r/programming.

EDIT: Link to Felix website updated; haXe removed; LPC, SPL, S-Lang, ICI added; licenses added.

Posted Nov 8, 2009, 9:22 PM UTC · edited

946
erickt•

Thanks for including felix, pointer2void! If you could, our current website is actually http://felix-lang.org. You linked to our old website, which I still haven't gotten around to taking down yet. Think you could update the link?

7
skulgnome•

How about you set up redirection at the old site? Doesn't take long and works for all older links too.

3
erickt•

Good point :)

3
[deleted]•

You might want to set DEBUG to False in Django installation. I got a 404 page with debug-information when I tried to access http://felix-lang.org/license/

1
erickt•

Oops, thanks for catch that :) I turned that on to fix something, then I forgot to turn it off.

1
[deleted]•

I still don't know your license though :)

1
erickt•

Oh, sorry! We're bsd. I'll make sure that's more explicitly stated somewhere :)

1
zahlman•

Why would you want a scripting language to be "C-like"?

5
erickt•

For felix, and potentially a lot of the other languages, we're semantically C-like, not syntactically. We're trying to make a high level language that allows for low level access like for graphics or systemy code when you need it, but exposing a lot of high level stuff like advanced type systems and actors when you don't.

7
zahlman•

I've looked at Felix. It really, honestly, looked to me like an attempt to trick C++ programmers into learning Haskell.

Also, I don't think "advanced type system" has anything to do with the high vs low level language axis.

4
erickt•

I've looked at Felix. It really, honestly, looked to me like an attempt to trick C++ programmers into learning Haskell.

Basically :)

But in all honesty, we're a lot less rigid about things than Haskell is. Our basic design goals are to incorporate a lot of the great ideas from languages like Haskell, Erlang, and O'Caml, and try to make them more approachable to the everyday programmer. Really, the most similar language to us design-wise is probably Scala, which I believe started around the same time felix did, but managed to get way more popular.

Also, I don't think "advanced type system" has anything to do with the high vs low level language axis.

Well, I think it depends. You're right that an advanced type system doesn't directly contribute to the high/low language axis, as shown with C++ compared to Haskell, but used appropriately it can help allow a language to perform at C speeds while staying expressive. Consider the classic functional singly linked list type in O'Caml that's just:

type 'a list = Empty | Cons of 'a * 'a list

And walked with:

let rec map f = function
| Empty -> Empty
| Cons (x, xs) -> let y = f x in Cons (y, map f xs)

Sure, you can use a dynamic language and write something similar, but you have to deal with the runtime costs.

6
luikore•

I need a scripting language to be "Chinese-like" (not joking), any suggestion ?

2
heroboy•
1
geocar•

APL

*/1+⍳N

is roughly the same as:

for (i = 0; i < n; ++i) {
  f *= (i + 1);
}

but is faster.

A+ (an APL-like language) can probably be turned into a scripting language.

1
OMouse•

This just supports the idea that teaching C to someone damages their brain. Afterwards they want to keep on using languages that look like it! :p

1
zahlman•

Not only that, but they keep wanting to use bizarrely indirect constructs for iteration, while at the same time complaining about not wanting to have to deal with "abstraction".

2
erickt•

I'm not familiar with those other languages, but with Felix doesn't mandate using those ancient iteration techniques. We support functional style higher order functions:

val x = list(1, 2, 3);
List::iter (proc (x:int) { print x }) x;

We also got generators:

gen repeat (var x:int) = {
  whilst true do
    yield x;
  done;
}

val fives = repeat 5;
print$ fives ();
print$ fives ();
3
pointer2voidOP•

You are in danger of creating a language that gets applause on reddit but Jo Programmer wouldn't consider to use.

0
irascible•

Because C fucked your mom.

-10
shadow2531•

I like Pike. I've only used it to write a mailto URI parser though and only did it in Pike (after doing it in other languages) for implementation experience.

Pike's syntax being c++-like is refreshing for some reason (maybe because I like C++'s).

I also like how you use / to split a string.

array(string) arr = str / ",";
5
invalid_user_name•

Pike is really nice, basically like python with a C-like syntax and without the retarded problems python has (gimped lambda, no conditional, no tail call optimization, etc). Also, I always miss:

some_array[*]['foo']

when using other languages.

1
bholmes•

perhaps you could also list some features or advantages of each? otherwise I feel no real motivation to try any of these.

4
erickt•

I wrote something about this for felix a couple weeks ago the highlights are:

  • An erlang/scala-esque actor model for tens of thousands of threads. Technically our implementation is a little lower than theirs though. We provide queue-less channel synchronization, but don't do mailboxing yet.
  • A haskell-esque type system with type classes and kinding.
  • A dynamic scoped GLR syntax that lets you easily create extensions like comprehensions as a library. Our syntax is almost entirely defined at runtime.
  • Zero-cost binding to C++ code. We compile directly to C++ (although I am working on an llvm backend). This lets us trivially bind to libraries like STL or libsdl.
  • We're pretty fast too. We can beat g++ sometimes, even though we compile down to C++. We can do that because we can make stronger guarantees about things for the optimizer with our type system than what C++ can.

edit: zero-cost wasn't really a clear term.

5
radarsat1•

zero-cost synchronization

can you explain what this means? thanks.

1
erickt•

Sure. I think I chose a poor phase, and I'll change it from my other post. What I meant is that one fiber communicates to another through channels that act like queues, but don't use any space to store the values. So, when one fiber wants to send an object to another fiber, first it checks if the other fiber is blocked reading. If so, it wakes the other thread and the data is copied. So, there's no queuing up the data in a synchronized data structure. If the reader isn't ready, then the writer fiber is added to a waiting queue, and when the reader is ready, the writer is woken and the data is copied.

1
[deleted]•

Really? This is your comment? Way to sour on someone providing an interesting set of links.

We look at these things because we're hackers, because we're in love with knowledge and weird programming toys and clever tricks. We look at these things out of joy, not out of "motivation."

0
bholmes•

I love to learn new languages as well. And yes, it gives me joy. (also just to clarify I believe joy can be a motivation) but someone posting a few scripting languages without any kind of description or features is like listing a random assortment of books without saying how good they are or why they're good or even which genre they belong to. I wasn't trying to sour anyone's links I just asked for some more info.

1
munificent•

While I'm personally tired of Algol-derived syntax, Felix looks like a really cool language.

4
erickt•

Thanks. I'm not crazy about the algol-ish syntax either, it's a carry-over back when our grammar was (I think) LR(1). Now that we've switched to a dynamic GLR syntax, we have the opportunity to deal with some more complex syntax, we just haven't had time to revisit it.

2
munificent•

I'm not crazy about the algol-ish syntax either, it's a carry-over back when our grammar was (I think) LR(1).

My hunch is that many language designers either are primarily interested in syntax or semantics. Felix looks to me like it focuses more on the semantics. People in that camp seem to just go for Algol because it's a simple default syntax (and lots of people know it).

You can come up with (in my opinion at least) much better syntaxes without making the grammar any more complex. Smalltalk is LL(1) and I think it's syntax is pretty nice.

I am (of course) partial to the syntax of the language I'm toying with, and it's LL(2) with a very simple hand-written lexer and parser. If you end up revisiting Felix's syntax and borrow stuff from my language, it'll be close to the perfect language for me. The semantics your language has are very similar to what I'm going for.

5
erickt•

Well we do have a dynamic syntax, where you could use felix as middleware :) Here's our grammar-in-our-library if you want to see how we do it. We basically have a bootstrap grammar, that's just enough to parse that grammar file I mentioned.

Can't promise that it'd be easy though ;)

1
munificent•

Interesting. Just what I need, another side project. :)

1
Felicia_Svilling•

I think in this we are often biased by our own intrests. For me it would seem like nearly every language designer is using the syntax of either ML or Lisp, but that might have to do with what papers I read.

1
munificent•

Yeah, over in academia, pretty much every language looks like ML (or Haskell) or Lisp because those are the languages language researchers are using.

In non-academia, like embedded home-grown scripting languages, I see a lot more "I'll make it look like C because that's what I know".

2
yttrill•

erickt has hassled me to say something about Felix so here goes..

Felix started off as an attempt to solve two problems in a Telco environment. The first problem was that one would like to manage a phone call with a thread, but consider that a telephony switch can start 600 calls per second and calls average about 3 minutes, then you need a capacity to handle 600 x 60 x 3 = 100K concurrent threads. At the time Unix OS couldn't possibly cope with this many pre-emptive threads (and probably still can't).

The second problem was to write the call handling code in a familiar language .. in a major C++ shop that meant something vaguely like C.

The technical solution was to write a compiler that "control inverted" threaded like code into co-routines mechanically and transparently, in fact, a well known idiom using a spaghetti stack of C++ class objects for function stack frames, and a resume() method to restart code where it left off. With this technology I managed to launch 500K threads on a PC in one second .. way more than the biggest multi-CPU Unix server could handle.

A key feature of this method of cooperative multitasking is that code is fully compiled and optimised C++, so it is extremely fast. Task switching is done by a scheduler that basically just swaps an object pointer and invokes a resume() method, which is typically faster than hardware task switching on a CISC processor.

However despite the vague resemblance of the (original) language to C, underneath the system used an ML like static type system. Apart from being superior to C/C++ in terms of ease of programming, it also allow unprecedented high level optimisations which simply cannot be achieved in weaker systems.

Furthermore, because it is presented as a scripting language, where you think you are executing text (and the compilation is all done transparently), Felix is able to do whole program optimisations way beyond what can be done in C, C++, Ocaml or even Haskell, so it typically generates code faster than any other language. In some case I don't even really understand myself why it is so fast.

There is a clear connection between superior performance and high level programming semantics. As an example consider that Felix optimises parallel assignments such as:

a, b, c = b, c + a, a+b

By specification these are done like:

tmp1 = b tmp2 = c + a tmp3 = a + b a = tmp1 b = tmp2 c = tmp3

and that's a how a brain dead compiler would generate code. But Felix actually minimises the number of temporaries required and the number of assignments needed. In straight line code this isn't important, but when you're handling initialisation of the variables of a function from a tail recursive call, it is utterly vital.

I could write a lot more: with features like overloading of polymorphic functions with constraints and typeclasses with semantic specifications, the type system is in some ways ahead of ML or Haskell. Most of these advanced features were added so that libraries could easily be written to bind to C/C++ code, and yet could be easy to use: statically typesafe yet looking like a scripting language:

println$ "Felix",101;

2
segoe•

Great list. Kaya seems really really nice.

1
anonaccounts•

haXe is not a scripting language.

::edit:: Seriously down voted for stating an obvious fact?

I am stating a fact, it's a compiled language it compiles to many target languages some of which are 'scripting languages', however as it stands HaXe is not a scripting language how hard is it to understand this fact? Go to the website and find me the reference where they even mention that it is a scripting language.

1
Felicia_Svilling•

"scripting language" is not a well defined term.

1
poporz•

Never forget LPC, the script for LPMud.... Millions of person get benefit from it.

1
invalid_user_name•

He listed pike. It's a modern LPC.

1
YakumoFuji•

There is also SPL. I remember reading about pawn (nee Small) in DDJ ages ago, essentially all they did was alter Cain/Hendrix Small C compiler to use a different backend that was a virtual machine target isntead of a real cpu and Small evolved from there, including all its warts (eg; lack of structs/unions etc etc etc). All of which are still inherant. Pawn is imo still aweful as far as embedding it goes because of its memory management.

1
[deleted]•

[deleted]

1
shaurz•

ZE GOGGLES

1
anthropoid•

A couple more suggestions:

1
InCaseOfEmergency•

There is also the Fledgling Languages List for those interested in languages that are in their infancy.

1
[deleted]•

Haven't looked at examples, but I wouldn't call haXe C-like.

0