The Crack Programming Language(code.google.com)
code.google.com
The Crack Programming Language
http://code.google.com/p/crack-language/
32 comments
import crack.io cout;
x := 'test';
cout `This is a $x\n`; # prints "this is a test" to standard output.
You don't know where to find the backtick on your keyboard?!
I''l give you an example: http://en.wikipedia.org/wiki/File:KB_Italian.svg
edit: a couple of funny things for italian keyboards, if you are a programmer or use linux/unix: there is no backtick, there is no tilde, '/' is shift-7, '/' and '?' are on different keys, '{}' are on altgr-shift-è.
edit: a couple of funny things for italian keyboards, if you are a programmer or use linux/unix: there is no backtick, there is no tilde, '/' is shift-7, '/' and '?' are on different keys, '{}' are on altgr-shift-è.
That keyboard layout doesn't seem particularly well-suited to programming. Then again, it doesn't seem particularly well-suited to typing Italian, either, though I now understand why Italians often write E' instead of È.
And this, ladies and gentlemen, is why all programmers, sysadmins and so on use a US keyboard layout.
I'm guessing you live in the US...
No. But I /do/ occasionally use bash, or call out to the shell from scripting languages...
BUT=$(echo So do I...)
"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”?
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.)
(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.
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.
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.
"Crack aims to provide the ease of development of a scripting language with the performance of a compiled language."
Have you looked at the Flua project yet? It's pretty much this and much more. http://flua-lang.org/
Have you looked at the Flua project yet? It's pretty much this and much more. http://flua-lang.org/
You are joking aren't you? There's not a line of documentation on the Flua webpage. The Windows download doesn't open on my Windows machine and I need a GUI to run it on Linux (which my linux box doesn't support). It also claims to be as fast as C, but a cursory examination of the source suggests it is entirely written in Python and Flua!
That's because there is no online version of the documentation right now. It's only available in the editor, it's an Alpha after all.
Just because the compiler is written in Python it does not mean the Flua programs are executed in Python. In fact they can be executed in multiple environments and C++ is the one which is currently being developed, hence the programs _are_ fast.
How come the Windows download doesn't work for you? It works on vanilla Windows, that's really strange.
Just stay on a constructive level. It would have been nice if you submitted a bug report on GitHub about the error you got on your Windows machine.
Just stay on a constructive level. It would have been nice if you submitted a bug report on GitHub about the error you got on your Windows machine.
Some more info here: http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.ht...
Start reading the spec, get to "For complex types (which we'll discuss later), a null pointer is used" under default initialization
wonderful.
wonderful.
Once could make all sorts of comments about the fact that this article currently appears immediately above the one on 'hacking my vagina' - but that would be too easy.
Joking aside, 'Crack' is a questionable name for a programming language.
I am inclined to dismiss the language for this:
i++I would have once disagreed with you being a C programmer. However, nowadays there is a tendency to providing functional features, including for example if..else expressions. But if you make i++ an expression, you end up with ambiguities if i++ ends up being the last line of an if..else branch, and say s = "hello" being the last line of the other branch. In a statically compiled language, the compiler has no choice but to interpret both as expressions and complain about the types of the two if..else branch expressions not matching. However, the programmer may have intended these expressions for their side effects only, not their values. Perfectly good code needs to be rewritten to work around the type checker. How fiddly.
Why?
I'd venture into guessing that the parent reason is that ++ and -- operators tend to make easy to bury side-effects where they're not obvious, like in the provided code sample:
__raw[args[i++]] = 1;
(C programmers would disagree about this, of course :) )
__raw[args[i++]] = 1;
(C programmers would disagree about this, of course :) )
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?)