The Crack Programming Language | Hacker News Reader

The Crack Programming Language

code.google.com

33 points0x199732 comments

This 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?)

Technically, work on Crack became public before work on Go did. So you should be asking what Go provides that Crack doesn't. Technically.

and rust,

but yeah, maybe its the name

   import 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''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-è.

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.

It might go a long way to explaining why I don't come across many Italian Unix sysadmins, and the few I have come across coded their system scripts in php.

I'm Italian and nearly everyone I know (who's a programmer) uses an US 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...)

The scripting language is Perl, apparently.

Does Perl make us of a lot of characters you can't find on your keyboard? Sure, you can use backticks shell style, but you'll probably have better luck with IPC::Open3.

Perl's strings look pretty much the same as everyone else's strings.

"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.

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.

"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/

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.

Locking people into needing a specific editor just to get the documentation is a bad move.

Yeah, sorry - I just couldn't find any time to write an online version. Will do it as soon as possible.

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.

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 :) )

Reply on news.ycombinator.com