

Anic -- Faster than C, Safer than Java, Simpler than *sh - jhrobert
http://code.google.com/p/anic/wiki/Tutorial
ANI is a dataflow programming language, with strong typing, implicit parallelism, oop and the beggining of an implementation.<p>"Q: How does ANI resolve the fundamental issue of deadlock in parallel programming? How does the Dining Philosophers example on the main page work?<p>A: In ANI, under the hood, pipes implicitly enforce total resource orderings for acquiring data. Somewhat surprisingly, deadlock theory guarantees that there will be no deadlock if this condition is met."
======
gibeson
Still reading through, it's definitely piqued my interest. However, in the
interest of consistency [as it translates to readability] two issues right
away:

1) Get rid of the infix modifier to the filter. The statement is made that in
ANI everything flows left to right. The infix operator while providing
familiar 1+6->7 notation conflicts with the above flow statement. 1,6+->7
while not immediately familiar is easy to understand after explained. However,
added special case rules for infix operation muddies the water.

2) In the following code sample provided, the left to right rule is again not
followed and thus leads to increased difficulty in [human] parsing:

multiPrint= [string\ s, int\ times] {

    
    
            \\[std.gen] <- \times s ->std.out;
    

};

"Hello, World!\n", 10 ->multiPrint;

Instead, to be consistent and follow the previous left to right flow rule, use
the following syntax:

multiPrint= [string\ s, int\ times] {

    
    
            \times -> \\[std.gen];
    
            s ->std.out;
    

};

"Hello, World!\n", 10 ->multiPrint;

In general if there is an everything flows left to right rule, there should
not be a <\- operator.

imho

~~~
ComputerGuru
s/peeked/piqued

~~~
gibeson
Thanks.

------
milkshakes
gotta love the url _<http://code.google.com/p/anic/> _

------
jws
_Faster than C_ – this is explained in the FAQ as most C programs being single
threaded and ANI being inherently multithreaded.

ANIC was posted to HN most of a year ago:
<http://news.ycombinator.com/item?id=1042122> with much commentary.

~~~
jhrobert
Sorry, I missed it at the time. BTW I wanted to avoid a double submit and I
have been looking for some "search" box without success, it is probably
obvious once you know where it is, where is it?

~~~
milkshakes
<http://searchyc.com/>

~~~
hippich
[http://www.google.com/search?q=site:news.ycombinator.com+key...](http://www.google.com/search?q=site:news.ycombinator.com+keyword)

------
mey
Maybe it's just me, but I don't believe you can claim Windows supported by
Cygwin proxy.

~~~
BrandonM
Why not?

~~~
mey
The compiled binary result of an ANIC program can not run on Windows natively.
Thus where on other systems my dependency list is simply the native binary, on
Windows, Cygwin either needs to be packaged with the release or installed
manually by the user.

It's a blurry question regarding where you say a VM/Compatibility shim means
that you no longer running the application natively. The same can be asked of
Java, Flash, and a lot of interrupted/bytecode languages. The distinction to
me in this case is that the code is meant to be compiled to native code (which
it isn't in this case), and Cygwin is not a common platform available on a
Windows system.

[Edit:] The asker of parent question should not be down voted, it is a
reasonable question, and as I've stated it's open to interruption.

~~~
rlpb
What about .NET? By your logic, applications written for the .NET CLR don't
support Windows (XP) either.

~~~
sjs
Well, they don't. That XP users are likely to have something installed that
has dragged in .NET doesn't change that fact.

------
CoryMathews
Am I the only one thinking this code looks ugly and hacky. I would never code
in this.

~~~
jameskilton
Frankly there isn't a language in existence that's "easy to read" and I'm kind
of sick of seeing that claim. There's no way you can read anyone's code
without knowing at least something about the language.

That said, I really like the ideas this language is offering and I'm
definitely interested in giving it at try.

~~~
endtime
I'd argue that Python is very easy to read for someone new to programming,
particularly someone familiar with mathematical notation. Something like:

    
    
        for animal in ['dog', 'cat', 'bear']:
            print animal
    

strikes me as intuitive and obvious, both absolutely and also relative to the
equivalents in other languages.

~~~
groby_b
That is not necessarily a sign of a good language, though.

ADD 1 TO COBOL GIVING COBOL

is also readable, and yet (thankfully!) we've mostly abandoned COBOL.

And no, I'm not saying Python is bad, or like COBOL - just that readability
and quality of a language are not necessarily related.

~~~
frozenflame
I don't know that I agree, I really am not sure what "GIVING COBOL" means.

~~~
a-priori
It's the assignment part; it says where the result should go. In this case,
back to the "COBOL" variable. But, it's optional if you're assigning back to
the source: ADD 1 TO COBOL means the same thing as ADD 1 TO COBOL GIVING
COBOL. But, you can also do ADD 1 TO COBOL GIVING FOOBAR to assign it
somewhere else.

(Yes, I just spent the last 10 minutes reading the COBOL pages on Wikipedia
and Wikibooks.)

------
huhtenberg
Latch concept is probably worth exploring further. Does anyone know of a
language with native variables being a FIFO pipe? I.e.

    
    
      x = 1   // x now contains 1
      x = 2   // x now contains 1 and 2
      y = x   // x now contains 2, y now contains 1
      ...
    

This sort of thing. Not as an add-on construct, but as a native part of the
language.

~~~
lukesandberg
go channels are like that (im a little rusty but it works pretty much like
this).

c := make(chan int, 2);

c <\- 1;//c contains 1

c <\- 2;// c contains 1 followed by 2

y <\- c;//y=1

~~~
nitrogen
It looks like make(chan int, 2) creates a channel with a maximum depth of two
elements. I was curious how channels work, so I looked up the relevant part of
the spec (<http://golang.org/doc/go_spec.html#Channel_types>). In case anyone
else was wondering, specifying the length of a channel allows it to be written
and read asynchronously until the channel is full. A zero-length channel will
block until both a sender and receiver access the channel.

------
metachris
I think the concept of a data-flow programming language is very interesting
and I'd love to see an active, open-source data-flow programming language like
Anic (which doesn't currently exists). Which makes me a bit uneasy about Anic
is that it only has 3 committers, with the last update end of September, and
no working compiler.

The developer needs two things: (a) financial support so he can work on it
full time, and (b) an active community of contributors. Maybe some
organization could sponsor him, or perhaps do a Kickstarter fundraise or
simply ask around for donations... I just hope it gets some traction and a
compiler; for certain problems Anic could be a very interesting and natural
approach.

PS: The first response in this thread contains a few well articulated reasons
for being interested in Anic: [http://groups.google.com/group/ani-
compiler/browse_thread/th...](http://groups.google.com/group/ani-
compiler/browse_thread/thread/4454069ad411282)

~~~
dkersten
_makes me a bit uneasy about Anic is that it only has 3 committers_

Sadly its much worse than that.

Only one of those 3 committers, Adrian/Ultimus, is actually actively
committing. I know this because I'm one of those three committers - I was
given commit access because I helped answer questions and edit the wiki pages
a little (because I knew enough about dataflow languages prior to encountering
ANI that I was quickly able to understand the concepts and code). But I have
yet to actually commit any code.

I was working on a simple x86 code generator (basically walk the AST, using
maximal munch instruction _tiling_ ), but its not near working and I've been
horribly busy with paying projects to finish it :(

------
jheriko
I'm curious how a language with no compiler is "faster than C" since the speed
of C is nothing to do with the language and everything to do with the compiler
implementations which have been so heavily worked over the years.

I can believe it - I've made my own language and compiler whose results are
faster in the niche area it targets than any C compiler I've ever seen - I'm
just curious how this assertion is backed up.

~~~
jheriko
nm, i see in the comments... so its a false claim then. nice. :/

~~~
foljs
Nowhere in the comments it is shown to be a false claim.

"Faster than C" is doable, but needs qualifiers, e.g:

CUDA in modern GPU hardware is faster than dektop C.

JITed Java was shown to be faster than C in several cases, because the JIT
compiler could make adaptable optimizations based on the actual runtime
environment.

And, any competent language that takes advantage of multiple cores easily is
faster than most C equivalent programs (even most multi-threaded ones).

------
jgalvez
That is the fugliest thing I've ever seen.

Looks like it's well written, planned and engineered tho.

~~~
shib71
Those were my thoughts as well. I like the idea of a language where
multithreading is the default, but all those back slashes - it reminds me of *
in C.

~~~
gte910h
Yeah, it could use with different characters for syntax.

------
Goladus
My suggestion is to get an editor to look at that tutorial. It's fantastic
that so much effort was put into presenting the language, but reading it is
rather painful.

At best it's written like a oral lecture, at worst it's wordy, condescending,
overuses of italics for emphasis, leads by the nose for no apparent reason,
and has obvious exaggerations that aren't clarified.

The grammar is all fine and so is the general structure, but I suspect a good
writer could help a lot with the remaining details.

------
gte910h
Looks like a computationally executed VHDL.

Interesting, but not necessarily useful. And looking how hard it is to "write"
good vhdl logic, I'm not sure how many could handle coding in ANI.

~~~
dkersten
While I partially agree with you're saying (VHDL _is_ hard to write well;
thinking in parallel _is_ hard), I'm not sure I can completely agree. In it
current textual form, you are probably right, but with a visual programming
frontend, I think a dataflow language like ANI may actually be easier to
program than a standard sequential program in a traditional language.

Why do I think this? Because visual dataflow languages have been _very_
successful as programming tools for non-programmers in niche areas. Eg, in
music production: Puredata, MAX/MSP, Syntmaker, Reaktor; in 3D modeling (at
least Blender has a dataflow-esque language for describing the render passes,
but I've seen other visualization/graphics programs use datalow-like visual
programming languages); in game development tools (I've seen at least three
commercial engines which use some form of dataflow-esque visual programming
language for describing shaders, AI and probably other things); the scientific
community has LabVIEW. I'm sure theres others too (not exactly _non-
programmers_ , but the defense/aerospace industries have SCADE).

Of course, coming up with an intuitive, yet sophisticated enough to do real
programs in, visual representation and GUI interface would still be a
difficult task and I certainly agree that for a textual programming langauge,
your comment is probably correct.

------
ramchip
AFAIK, this thing doesn't work any more than it did a year ago...

~~~
chancho
And just like a year ago, there's nearly 100 comments about whether or not the
syntax is ugly, whether or not you find it readable because you can't break
out of your Algol mindset, whether or not anything can truly be "faster than
C", whether or not C is easy to parallelize, the url spells "panic", etc etc,
and yet there's only 1 or 2 people that bother to look at the commit log and
browse the source tree to find out that it's _total fucking vapor._

Pretty embarrassing for HN to be so reliably trolled.

~~~
sagarm
The commit log shows plenty of activity:
<http://code.google.com/p/anic/source/list>

~~~
ramchip
I respect the author's dedication, but I think he has his priorities
completely wrong (and I told him so last year): how can you commit something
like "cleanup and performance boost for color-coded output" when there is not
even a proof of concept that the language is implementable? He's worked a lot
on the parsing and the front-end, but I wish he would get something compiled,
anything, and just show that his idea can work, instead of debating about
things that are ridiculously minor for the moment like syntax or an
interactive environment. Chancho's post is exactly my thoughts.

For example, why not compile or manually translate some examples to C as a
prototype? What can be done in assembly can mostly be done in C as well, if
you're willing to sacrifice some performance.

~~~
dkersten
Well, fwiw, the binary that does exist (which does, as far as i can tell,
parsing, type inference/type checking and a bunch of semantics checking, plus
it walks to AST to generate code (except it doesn't actually generate code
yet), so far is insanely fast, even in verbose mode (where it prints a load of
shit to stdout).

As for proof of concepts, on the mailing list he has stated that ANI is more
or less a natural progression from previous unreleased projects.

Having said that, I agree that focusing on getting something working before
trying to make it fast is the _correct_ way to do it...

------
akkartik
It looks tantalizing, and I _love_ shell scripts, and I've spent countless
hours wishing for pipes in my programming language.

But: when it says, _"ANI is designed to abstract away from the idea of an
"algorithm" altogether,"_ I go, "quackery."

~~~
stcredzero
There are things which aren't algorithms, but which can embody the same
strategy as an algorithm, like sorting networks. Instead of series of steps,
the sorting network specifies a bunch of data flows, wherein things can happen
in parallel.

------
colbyolson
At first glance I always think it's "simpler than shit.", but then I read the
article, and no, for my poor brain it is not simpler than shit.

------
siim
This latching and piping seems intuitive if you have done some monadic
programming in Haskell.

------
vault_
I'm not really sure of the accuracy of any of its claims, but it certainly
looks interesting.

------
bubbleboy
what problem does this solve?

------
kqueue
The syntax hurts my eyes.

------
binaryfinery
Interesting, if he knows what he's doing. This doesn't fill me with hope
however:

Building main executable... src/types.cpp: In member function
'TypeStatus::operator uintptr_t() const': src/types.cpp:1514: error: cast from
'Type*' to 'unsigned int' loses precision

~~~
dkersten
Its easily fixed though: either compile on a 32bit machine, or change that
line to type-cast to uintptr_t instead of unsigned int.

