Am I the only one thinking this code looks ugly and hacky. I would never code in this.
Classic Blub programmer reaction; extra bonus for dismissing a language just because of unfamiliarity/dislike of the syntax.
Anic -- Faster than C, Safer than Java, Simpler than *sh
81–90 of 96 posts
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#82I'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.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#83I'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 u…
nm, i see in the comments... so its a false claim then. nice. :/
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#84Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#85Earlier quoted context omitted.
Hell, many operating system's thread schedulers are written in C..
Ironically the task of scheduling threads isn't one that is particularly parallel, but I think the point stands.
Actually, it's entirely parallel, unless you only have one core. In a typical OS (like Linux), the scheduler runs on each core and selects which task to run next on that core.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#86Earlier quoted context omitted.
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
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.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#87Latch 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.
Easy enough with Perl arrays using push and shift.
With the added bonus that Perl makes it obvious you're talking about an array.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#88Earlier 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 know that I agree, I really am not sure what "GIVING COBOL" means.
Really? I've never coded in COBOL and it was pretty obvious straight away that it was an assignment.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#89Faster 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.
People shouldn't make claims like that honestly. It makes be discount the language almost immediately because I know I can't really trust what's written about it on its site. Furthermore, there's tons and tons of parallel C code. Probably more than any other language. Almost any decent C library is reentrant. Many of major C projects (mostly thinking of server software and operating system kernels) are threaded.
People should also understand generalization, though.
That there's "tons and tons of parallel C code" doesn't matter.
Parallelization is built-in into this language. It is not built-in, as a first class language feature, in C.
A lot of C projects, such as servers, are indeed threaded, but threads are also so last century.
Different paradigms (like in Erlang) are better to parallelize, easier to write, more performant, and much much less confusing to debug than threads. Heck, even no-side-effects functional language programming is better to parallelize than C with threads.
Re: Anic -- Faster than C, Safer than Java, Simpler than *sh
#90I'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 u…
nm, i see in the comments... so its a false claim then. nice. :/
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).