
The Crack Programming Language - 0x1997
http://code.google.com/p/crack-language/
======
dietrichepp
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?)

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

~~~
rjzzleep
and rust,

but yeah, maybe its the name

------
mitchi

       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.

~~~
peteretep
You don't know where to find the backtick on your keyboard?!

~~~
gosub
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-è.

~~~
kokey
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.

~~~
fceccon
I'm Italian and nearly everyone I know (who's a programmer) uses an US layout.

------
jacobolus
_"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”?

~~~
dietrichepp
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.)

~~~
seanmcdirmid
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.

~~~
dietrichepp
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.

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

~~~
wbhart
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!

~~~
blitzprog
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.

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

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

------
pike
Some more info here:
[http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.ht...](http://www.mindhog.net/~mmuller/projects/crack/Manual-0.7.html)

------
octo_t
Start reading the spec, get to "For complex types (which we'll discuss later),
a null pointer is used" under _default initialization_

wonderful.

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

~~~
laumars
Joking aside, 'Crack' is a questionable name for a programming language.

------
perfunctory
I am inclined to dismiss the language for this:

    
    
      i++

~~~
derleth
Why?

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

