Live data from Hacker News

Anic -- Faster than C, Safer than Java, Simpler than *sh

code.google.com

71–80 of 96 posts

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#71
post #47

Earlier quoted context omitted.

Why not?

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…

Perhaps you meant interpreted/interpretation instead of interrupted/interruption?

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#72
post #48

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

(To make my comment clearer: there is no working compiler, no code generation, not even a proof of concept of what the compiled code would look like. It could become more interesting, but so far it's just an imaginary language making wild promises. IIRC the author also wants to code the whole stdlib in assembly for speed and because it's so 'radically different' from C...)

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#73

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

I think it would make an excellent backend for a visual programming language. I've developed a simple data flow-based system that I use for home automation, and could see using something like this to replace my current "interpreter." Imagine something like Yahoo Pipes or Pure Data compiled directly into parallel code.

Granted, tasks which have a natural sequence can be a lot more difficult in dataflow-driven languages, so use whatever works for a given situation.

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#74

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.

go channels are like that (im a little rusty but it works pretty much like this). c := make(chan int, 2); c c y <- c;//y=1

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.

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#75

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

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.

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#76
post #48

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

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.

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#77
post #76
post #48

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

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 ou…

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

Re: Anic -- Faster than C, Safer than Java, Simpler than *sh

#78
post #14

Earlier quoted context omitted.

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.

I don't think that "englishy" (COBOL, applescript) code is readable, and I bet many programmers agree. Python is readable because its syntax is very close to many people's version of pseudocode. This is why non-Python programmers find it easy to read.

I find Applescript quite readable, especially for its purpose, but it's a pain to write, because, unless you use it often, you never know which subset of English is valid.
Post reply on HN