Live data from Hacker News

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

code.google.com

91–96 of 96 posts

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

#91

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

Actually, that is something we've discussed on the mailing list (I've been on the list since the last time this was posted to HN) and its something I'm personally interested in building once the compiler and runtime are far enough along. Dataflow-based visual programming is something I've been very interested for a while now and is even partially related to my startup stuff, so its something close to my heart.

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

#92
post #17

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.

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.

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

#93
post #86
post #77

Earlier quoted context omitted.

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

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

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

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

#94

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

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

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

#95

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…

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

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

#96

Earlier quoted context omitted.

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?

Look at the links in the page footer (Lists, RSS, Search, ...).

Thanks. it's obvious, now! ;)
Post reply on HN