----------------------------------- wtd Thu Feb 02, 2006 6:49 pm The Next Mainstream Programming Languages ----------------------------------- From a game developer's perspective. http://lambda-the-ultimate.org/node/1277 ----------------------------------- rizzix Sat Feb 04, 2006 1:56 pm ----------------------------------- 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, Int32 i = 1; would behave similarly to Java'sString 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 Sat Feb 04, 2006 2:14 pm ----------------------------------- 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 Sat Feb 04, 2006 2:18 pm ----------------------------------- 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 Sat Feb 04, 2006 2:24 pm ----------------------------------- 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 Sat Feb 04, 2006 2:31 pm ----------------------------------- 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 Sat Feb 04, 2006 2:33 pm ----------------------------------- 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 Sat Feb 04, 2006 2:39 pm ----------------------------------- 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 Sun Feb 05, 2006 10:02 pm ----------------------------------- 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 Mon Feb 06, 2006 3:12 am ----------------------------------- If I may ask... what in particular felt "unnatural" about it? Syntax or semantics? ----------------------------------- bugzpodder Mon Feb 06, 2006 7:14 pm ----------------------------------- 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 Mon Feb 06, 2006 9:51 pm ----------------------------------- 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 Tue Feb 07, 2006 12:22 pm ----------------------------------- 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: for (initialization; test; update) { ... } So, let's say we want to sum a range of numbers from 4 to 11. int sum = 0; for (int i = 4; i 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''' ----------------------------------- wtd Tue Feb 07, 2006 7:32 pm ----------------------------------- The second question is delightfully simple when pattern matching comes into the picture. myOtherWeirdFunc (x:lst@(x':xs)) = x' - x : myOtherWeirdFunc lst myOtherWeirdFunc _ = [] ----------------------------------- bugzpodder Tue Feb 07, 2006 9:37 pm ----------------------------------- if anything, writing haskell programs is much more fun than writing c++ ones! I'll give that for sure! ----------------------------------- wtd Tue Feb 07, 2006 9:48 pm ----------------------------------- Excellent. There's hope for you yet. :)