The Crack Programming Language
code.google.com
The Crack Programming Language
1–10 of 33 posts
Re: The Crack Programming Language
#2"Crack aims to provide the ease of development of a scripting language with the performance of a compiled language."
Where’s the speed comparison? Where’s a substantial enough code sample to show that development is “easy”?
Re: The Crack Programming Language
#3"Crack aims to provide the ease of development of a scripting language with the performance of a compiled language." Where’s the speed comparison? Where’s a substantial enough code sample to show that development is “easy”?
They probably assume that as long as it's not too burdened with runtime dispatch, then LLVM will take care of the speed. And they'd be right.
(Popular JavaScript implementations manage high speed even with runtime dispatch. The optimizations make heavy use of static analysis, but this is difficult to do.)
Re: The Crack Programming Language
#4"Crack aims to provide the ease of development of a scripting language with the performance of a compiled language." Where’s the speed comparison? Where’s a substantial enough code sample to show that development is “easy”?
They probably assume that as long as it's not too burdened with runtime dispatch, then LLVM will take care of the speed. And they'd be right. (Popular JavaScript implementations manage high speed even with runtime dispatch. The optimizations make heavy use of static analysis, but this is difficult to do.)
Why do you think run time dispatch is that slow? With static typing you can setup an efficient vtable, while even with just dynamic typing there is a lot of cachingq you can do to reduce call overhead. Static analysis helps for some inlining, but the gain isn't more than a few percent.
Garbage collection and run time safety checks probably cost more than call indirection.
Re: The Crack Programming Language
#5This page doesn't sell it to me. Maybe it's a great language, who knows?
1. With Go, I understand the point. It makes advances in terms of how easy it is to write concurrent programs, without completely ditching the traditional imperative model.
2. Rust is a different take on the same point. We want concurrency and safety. Rust's difference from Go is that it is more safe, and makes it easier to give latency guarantees.
But I don't get what's "hard" about, say, Go, that Crack would make things easier for me. What does Crack offer that Go doesn't? Or Python? Why would I want to use Crack at all?
(I get that they want to say it's "addictive" so they'll call it "crack", but it's a terrible name. I worked for a company that wanted a product to go viral so they code-named it "Marburg", after a biological weapon. Maybe I should name my next product "Enola Gay" because it will level the competition?)
Re: The Crack Programming Language
#6Earlier quoted context omitted.
They probably assume that as long as it's not too burdened with runtime dispatch, then LLVM will take care of the speed. And they'd be right. (Popular JavaScript implementations manage high speed even with runtime dispatch. The optimizations make heavy use of static analysis, but this is difficult to do.)
Why do you think run time dispatch is that slow? With static typing you can setup an efficient vtable, while even with just dynamic typing there is a lot of cachingq you can do to reduce call overhead. Static analysis helps for some inlining, but the gain isn't more than a few percent. Garbage collection and run time safety checks probably cost more than call indirection.
Call indirection prevents inlining. It's not about comparing indirect calls versus direct calls, it's about comparing indirect calls against no function call at all.
For example, imagine a function that multiplies two matrices. If the matrices are statically typed, the resulting function would only need to allocate the result. If the matrices aren't statically typed, you need to dispatch on the type of each element in each matrix. That will take much longer.
Yes, there are ways around this in languages with dynamic dispatch. However, my point is that LLVM won't do it for you.
Re: The Crack Programming Language
#7Some more info here: http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.ht...
Re: The Crack Programming Language
#8 import crack.io cout;
x := 'test';
cout `This is a $x\n`; # prints "this is a test" to standard output.
Re: The Crack Programming Language
#9import crack.io cout; x := 'test'; cout `This is a $x\n`; # prints "this is a test" to standard output. Really weird strings... I don't even know how to type this character with my keyboard layout. Nice job for this language. It has a lot of things for so few versions. I couldn't build something like this. But who would use this? D is 10 times better and mature and almost no one uses it.
You don't know where to find the backtick on your keyboard?!
Re: The Crack Programming Language
#10import crack.io cout; x := 'test'; cout `This is a $x\n`; # prints "this is a test" to standard output. Really weird strings... I don't even know how to type this character with my keyboard layout. Nice job for this language. It has a lot of things for so few versions. I couldn't build something like this. But who would use this? D is 10 times better and mature and almost no one uses it.
You don't know where to find the backtick on your keyboard?!
I'm guessing you live in the US...