This project seriously pisses me off.

[phallus99]

Just to be frank, the stuff you are trying to claim is full of bull
shit. And really, I'm just tired of it. I keep hearing people at my
college talk about this "new", "amazing" language which is honestly
probably the worst language I have ever seen. It is not intuitive, and
all of you are fooling yourselves.
Faster than C?
Okay that statement pisses me off so fucking much that I will just
respond with this:

NO YOU ARE GOD DAMNED RETARDED DIDN'T YOU TAKE COMP SCI I??!!!'


That is all.

[Adrian]

Faster than *typical* c -- most people don't resort to parallel c
unless necessary because all but the simplest programs become very
difficult to manage.

You could certainly do the parallelization analysis by hand, and then
code an equivalent in c, but this scales extremely poorly. Anic
doesn't make the impossible possible, just the infeasible feasible,
and
the typical faster.

If you want to debate some specific point here, I'd love to do so,
but
I'm afraid I don't have time for silly name-calling. If anic isn't
your cup of tea, you're welcome to close your browser tab ;).

Thanks!
Adrian, project lead

[phallus99]

Maybe that was out of line, but in any case this has been building up
for a month.

The thing is Ani is restricted in parallelization, meaning that the
compiler decides how it is done and all of that.
It leaves no room for finniking to fit a certain job better.

Also I don't under stand your hate for pthreads. I find it
extraordinarily easy, but that's just me, so whatever.

[Daniel Kersten]

Wow, you really show how much you understand ANI and programming language design and implementation. That is to say, you obviously haven't got a clue.

First of all, if you don't like ANI, then ignore it. Nobody is asking you to care. There are a LOT of programming languages out there. Do you complain to each and every one of their creators too? Do you tell the developers of Factor or Go or Mirah or Frink or Thyrd or Coffeescript that you hate their projects because they make some bold claims (and every new programming language does claim to be the next great thing (in its area of specialism, ANI's is parallelism), if it didn't, why bother making it).

Secondly, ANI is not making any claims that we, the ANI community, believe it cannot achieve. The big claim ANI makes is "faster than C, safer than Java and simpler than shell scripting" - this goal is very possible and anybody who knows or follows language implementation knows this. Yes, its an ambitious goal (as most worthy goals are), but that doesn't make it less believable. Allow me to explain:

Simpler than shell scripting:
Don't be fooled by ANI's complex syntax; it only seems hard and complex because it is very different from most existing languages. If you had a broad experience of programming languages, you would see that ANI is incredibly simple. When ANI is ready to be released to the masses, then we will put effort into educating people and developing tools so that this simplicity can shine through. Until then, you'll have to take our word for it. ANI is based around a very small number of concepts, which it applies in a consistent manner - this makes the language inherently simple. Furthermore, I tested the syntax against some people new to dataflow programming and they found it incredibly intuitive once the most simple of concepts were explained.

Safer than Java:
Contrary to popular belief, Java is _not_ a safe language. The effort of important code paths against null pointers, for example, is a real problem for a lot of critical code. I'm not making this up, I'm saying this based on my own experiences programming Java (and C++) for core telecommunications systems (mostly for SMS messaging: anti fraud, parental control, messaging analytics and billing systems for mobile network operators, servers that filtered the networks SMS messages before sending them to service centers and such). Here I worked on some critical code, concurrent code, distributed code... I can tell you with complete confidence that Java, which is advertised as a safe programming language (don't get me wrong, compared to C and c++, it is), does have safety issues, especially in a concurrent environment, which ANI can, very realistically, overcome. ANI has a power type system and semantics analyser (mostly to ensure correct concurrency), which gives the compiler the information it needs to ensure safe code.

Faster than C:
I left this one for last on purpose, since its the big one. First of all, talking about a languages inherent speed isn't really very useful at all - you can make code in most languages run fast or slow and to write correct, fast C code is incredibly hard - especially in a concurrent environment.
While we will be trying hard to ensure ANI generates fast and efficient assembly code by applying all the popular optimisation techniques, the area where ANIs performance will really shine is in multi core environments. It is very difficult to write both correct and fast parallel code in C. By no means impossible - people do it all the time - but very difficult. That means that if ANI can generate reasonably good parallel code at a fraction of the effort, ANI will win in the general case. You can hand tune any code to run really fast, but that's hardly the languages "inherent speed", so the high performance parallel C versions don't really make the "faster than C" claims false. Furthermore, ANI has some advanced techniques to make sure parallel code is correct - it is very difficult to ensure this in C and an incorrect program can run as fast as you like and it'll still be incorrect.

So, between simple concepts, a strong type system and semantics checker and auto-parallelising code, I think ANI stands a good chance to meet the claims.

After writing that, I have to ask - didn't YOU take computer science? When looking for the retard here, perhaps you should take a look in the mirror?

--
Daniel Kersten.
Leveraging dynamic paradigms since the synergies of 1985.

[phallus99]

lol i troll u. Didn't really troll the other one, but i sure as hell
trolled u.

[Daniel Kersten]

You're an idiot. Now run along and play your childish games elsewhere.

[Daniel Kersten]

Accidentally didn't post this to the list.

Anyway, at some point we should edit the project page to explain these things, since it is an important question to a lot of people.

On 30 July 2010 01:48, Daniel Kersten <dker...@gmail.com> wrote:

On 30 July 2010 01:40, phallus99 <phal...@gmail.com> wrote:

Maybe that was out of line, but in any case this has been building up
for a month.

What has been building up for a month? Your hatred for this language? Why do you care so much about somebody elses language project? Go outside and get over it already! Its _just_ somebodies programming language project.
 

The thing is Ani is restricted in parallelization, meaning that the
compiler decides how it is done and all of that.
It leaves no room for finniking to fit a certain job better.

Also I don't under stand your hate for pthreads. I find it
extraordinarily easy, but that's just me, so whatever.

What is this certain job? Please, tell me. As somebody who (as sad as this sounds..) has a copy of "The Art of Multiprocessor Programming"[1], "Intel Threading Building Blocks"[2] and "Patterns in Parallel Programming"[3] sitting on his desk beside him, I have to disagree with your statements.
 
Pthreads (and similar) ARE hard. Just look at any ACM publication and you're very likely to see mentions of the "multicore problem" or other mentions of how hard multicore is.

Some things _are_ easy in pthreads, and when you find those, by all means, use pthreads! ANI is just a tool. Don't use it when pthreads makes more sense. However, a lot of problems are NOT well suited to pthreads.
Quick example - using pthreads, how to you best partition your work so that it runs as fast as possible on a dual core machine? How about the same code running as fast as possible on a quad core machine? A 64 core machine? An N core machine? The difficulty of multicore programming is making use of FUTURE cores and not hard coding the parallelism for todays machines.

If you happen to use C++, Intel Threading Building blocks makes this a lot lot simpler than using pthreads. ANI tries to elliminate this problem for as many cases as possible (but we never claimed for all).

--

Daniel Kersten.
Leveraging dynamic paradigms since the synergies of 1985.

[phallus99]

Talk about the pot calling the kettle black!

On Jul 29, 5:49 pm, Daniel Kersten <dkers...@gmail.com> wrote:
> You're an idiot. Now run along and play your childish games elsewhere.
>

[Adrian]

On Jul 29, 5:50 pm, Daniel Kersten <dkers...@gmail.com> wrote:
> Accidentally didn't post this to the list.
>
> Anyway, at some point we should edit the project page to explain these
> things, since it is an important question to a lot of people.

Yes, we should. I believe you have the perms for doing so, too -- but
correct me if I'm wrong.

Also, this phallus character should be considered a learning
experience for the project; the next pointless troll that comes around
(there will be another one eventually) can simply be directed to this
discussion. And then, we win, because the troll fails to get what he
wants (to waste our time).

Kudos on handling it, Dan!
Adrian

>
> On 30 July 2010 01:48, Daniel Kersten <dkers...@gmail.com> wrote:

[Daniel Kersten]

On 31 July 2010 05:49, Adrian <ult...@gmail.com> wrote:

On Jul 29, 5:50 pm, Daniel Kersten <dkers...@gmail.com> wrote:
> Accidentally didn't post this to the list.
>
> Anyway, at some point we should edit the project page to explain these
> things, since it is an important question to a lot of people.

Yes, we should. I believe you have the perms for doing so, too -- but
correct me if I'm wrong.

I believe I do, I'll try and write somehting up. You can correct it then if I spread misinformation ;-)
 

Also, this phallus character should be considered a learning
experience for the project; the next pointless troll that comes around
(there will be another one eventually) can simply be directed to this
discussion. And then, we win, because the troll fails to get what he
wants (to waste our time).

True.
 

Kudos on handling it, Dan!

Actually, in hindsight, I didn't handle it as well as I should have. Oh well, live and learn.
 

[3Jane]

Breaking the rule "Don't feed the troll" i'd like to support anic's
chief developers here.

Even when the hardware for massive parallelization (say 256 tasklets
or more) isn't
existing outside the mainframe niche and parallelization might not
play the prominent
rule in future Adrian is hoping for, anic is making sense for two
reasons:

1. There is no living dataflow language existing at all nowadays.

2. And threads as lightweight as possible are a very good companion to
dataflow
anyway.

Besides: The achievements in anic's IR, respective anic's memory
management, might
be paradigmatic for language development at all (from my side this can
be only a
hypothesis though).

[Ultimus Freelance]

Thanks for the encouragement; it means a lot!

I definitely think that a restructuring in how we do languages is in
order. I'm not blind enough to say that ANI/anic is the best and only
way it should be done, but I think things are getting ridiculous with
trying to program multithreading in C/C++, which is the only way to do
it these days if you want good performance.

The problem is that multithreading scale is getting so difficult and
unsafe that nobody wants to do it unless they absolutely have to. And
when they *do* do it, the developper effort to set up the frameworks,
locking policies, and everything else is a nightmare and a huge source
of bugs.

Many people have tried to fix the problem with libraries and language
additions, but the problems are still there and I think that breaking
out of the imperative paradigm entirely deserves a try.

I think that a big thing holding back our use of parellelization isn't
our hardware or our inability to make use of it -- it's our ability to
program it, and that's what we're trying to fix here. C was a great
language for a single-processor terminal-connected mainframe, but
those ideas are so out of tune with the state of the art in processing
today that I think we need to look at the issue from the ground up
(e.g. "why do we need call stacks or function calls at all in a
parallel envoironment?") instead of adding more and more hacks onto
the old languages (e.g. "OpenMP") to ease the pain of tranasition into
the age where we can't boost raw clock speeds any further.

Adrian