The Next Mainstream Programming Languages

[wtd]

From a game developer's perspective.

http://lambda-the-ultimate.org/node/1277

[rizzix]

How nice, but he fails to mention that, while it is easy to write clean and error-free code in Haskell, writing efficient code is not so easy This would be true for any functional programming languages.

Basically his concurrent programming idea, although true, will in fact reduce productivity. Trying to optimize their functions will simply waste valuable time. Then getting this to work smoothly in a concurrent scenario, where the state of the program "must" change, (which is likely, since it is not purely functional), is going to be a nightmare.

Unless of course he wants to take advantage of concurrency as _only_ a means improving performance, and not as means of doing some things that are virtually impossible in a single-threaded environment.

I've seen some great concurrent programming languages, and not all of them are functional programming languages: JointJava?

But he does have some good points: statically typed array bounds? (Yea I really liked that idea, but it makes tuples a little less useful). Maybe a List/Array <-> Tuple type-conversion would have been a better idea. Nevertheless, this was a good point.

Real Integers. That was a good point too. Arbitrary precision is definitely possible to implement within the language it self, and it should be.

As for his pointer problems, well, I say get rid of pointers all together. The way Java does it is nice and clean. Unfortunately it does not allow for pointer-arithmetic, but if pointer arithmetic is only used when using arrays, then it need not be used at all.

Now over these Java-like references, implement non-null references, something similar to final references in Java.

A Maybe type is very useful type. But in imperative languages, a Maybe type is only useful for primitive types and only if ADTs are always referenced by pointers, since a pointer can be either null or not null. One easy fix to this is to remove the concept of "primitives" and make everything an object. Now everything must be referenced by a pointer.

So,

code:

Int32 i = 1;

would behave similarly to Java's

code:

String s = "abc";

But this might involve a little overhead, since ints are used quite often. One dirty fix to this, is to internally handle all primitive refences as real pimitives, yet mimicing the language's rules over references, thus fooling the programmer. Sometimes such solutions are more efficient than others.

Haskell list comprehension are a very nice thing. Although, I do believe that you can gain the exact functionality through a well defined collections library. The only problem here is that list comprehensions can be statically optmised, i.e, they can be generated at compile time, and not necessarily at runtime, while library calls would practically always be called at runtime.

A nice way to fit list comprehensions into a Java-like language is to implement them as metadata constructs -- annotations. Now you have full control over when the list would be generated: compile time or runtime.

[wtd]

Functional programming languages are not inherently inefficient. O'Caml and some of the SML compilers can rival the best optimizing C and C++ compilers out there.

[rizzix]

That's not the point. I'm not saying they are inefficient. I'm saying that writing efficient algorithms in a functional programming language, requires more thought and work, than writing a similar algorithm in an imperative programming language.

[wtd]

I really don't buy that. All of the stuff you describe involves going to some extra effort and modifying existing imperative languages to achieve.

Such capabilities are much more natural in the various functional programming languages.

[rizzix]

I'm just suggesting ways to improve existing imperative languages.

I'm not suggesting to replace purely functional languages with imperative ones. I love those purely functional languages.

The point of that presentation was improvement wasn't it?

[wtd]

Yes. However the author was fairly blatant about his opinion that solutions to the problem already exist.

Asa Java programmer you must surely respect the notion of not reinventing the wheel?

What's easier: making Haskell fast, or creating a really fast, side-effect free (by default), lazily evaluated Java?

[rizzix]

Yea he wanted a hybrid language. Which as I stated is not going to make things any easier when it comes to concurrency.

For imperative langauges, such concurrency concerns have already been addressed by languages such as jointjava.

For purely functional languages, well it's pretty much quite natural to the language it self.

But a hybrid, is only going to make things very complicated.

[bugzpodder]

i got my hands dirty on a little bit of functional programming and it just felt unnatural to me. I'd rather code up C++ version of quicksort than Haskell's version. But the author does provide good support of functional programming for parallelism.

[wtd]

If I may ask... what in particular felt "unnatural" about it?

Syntax or semantics?

[bugzpodder]

anytime i feel like accessing an array using indices I am forced to deal with those recursions... and i have absolutely no idea how to do some of the things i can do in c++

[wtd]

In many cases, you can find a function in the standard library that will do what you need it to.

Perhaps you can mention some specifics and we can help you understand it better.

[wtd]

See recursion as just another means of accomplishing loops.

What is a loop?

It is a way of controlling flow that is composed of an initialization, a test, and an update.

In C++, we can make this look like:

code:

for (initialization; test; update) {    ... }

So, let's say we want to sum a range of numbers from 4 to 11.

code:

int sum = 0; for (int i = 4; i <= 11; i++) {    sum += i; }

No, how can we replicate this in Haskell? We can't recreate it directly. There's no looping syntax in Haskell. Still, wec can use recursion.

code:

sumFromTo from to =    if from == to then       from    else       from + sumFromTo (from + 1) to mySum = sumFromTo 4 11

So, how does this match upto the C++ example?

Well, we set the initial state by passing the value 4 to the function.

We test with "if from == to then ..." There's no recursion here, so it provides an exit condition for the loop.

The update is provided when we pass an updated value to the same function in a recursive call.

[bugzpodder]

how's this: alternation sum up k-th entries of the array, with k is a fibonacci number...
ie: compute sum = arr[1] - arr[2] + arr[3] - arr[5] + arr[8] - ...

or how about computing a list that is difference of adjacent values in arr:
list = {arr[1]-arr[0], arr[2]-arr[1], ...}

[wtd]

For the first one... keep in mind I haven't written much Haskell in awhile, and this is untested.

code:

-- some List functions import List -- lets generate all fibonacci numbers fibs = 1 : 1 : zipWith (+) fibs (tail fibs) -- lets create our list myList = [34, 56, 12, 19, 53, 76, 89, 114] -- add indices to myList myList' = zip [0..] myList -- find elements in myList' that have indices -- in the fibonacci sequence myList'' = [item | (index, item) <- myList',             findInSortedList index fibs]    where       findInSortedList _ [] = False       findInSortedList v x::xs          | v == x    = True          | v >  x    = False          | otherwise = findInSortedList v xs -- add indices again myList''' = zip [0..] myList'' -- alternate signs alternateSigns [] = [] alternateSigns ((index, item):xs)    | even index =  item : alternateSigns xs    | otherwise  = -item : alternateSigns xs -- sum it all up mySum = sum $ alternateSigns myList'''