GHC 7.10.1 Brings New Compiler Features

[rdnetto]

There is always the problem with compiled languages that compilers are much more complex than interpreters for dynamic languages. Rust compiler is new, buggy and the language seems hard (my thoughts). For example most people nowadays want classes and objects.

A simple compiler and a simple interpreter are of similar complexity, and almost no-one uses either. People want performance, which either means an optimizing compiler or a JIT (which is just a time-constrained optimizing compiler). Even Javascript, which isn't normally associated with performance, has V8.

In my experience, the Rust compiler is no buggier than GCC. (I think the backend is based on LLVM anyway, which is pretty mature at this point.)
I agree that rust is a harder language to get started with, but it's a false economy to say it's harder in general, because what we're really interested isn't how easy it is to write hello world, it's how easy it is to write a bug free program, and that's actually easier in languages like Rust which allow the compiler to enforce constraints like memory safety and types, because otherwise you need to manually test for all these issues. The comparison isn't between Rust and GC'd languages, because it's designed to be used in contexts where a GC would impose an unacceptable overhead; the comparison is between Rust and languages with manual memory management like C and C++.

The problem with Haskell is that it takes so much time to learn it that most people don't want to invest the time. If you learn OOP, you can easily switch between PHP/Python/Ruby/Java/C#/Groovy and many other mainstream languages. It's a really good investment to learn OOP. With functional mindset you get F# (closed Microsoft alternative), Swift (closed Apple alternative), some legacy compilers nobody uses, Haskell and maybe some research stuff nobody uses outside academia. Haskell might have web support, but nowadays most app development is for mobile and the cloud. Haskell generates 2 MB binaries (hello world). It's a big issues with mobile development. Without proper JS backend it's also difficult to consider it on the cloud.

First of all, it's not functional vs OOP, it's functional vs. imperative. OOP is a paradigm, not a language type. e.g. the Linux kernel uses it a lot in its file system layer, though I will admit that it tends to be easier in languages which provide features to facilitate it. Procedural languages are also imperative, FWIW.

I agree that pure functional languages aren't as popular as imperative ones, but it is worth noting that both pure functional and pure imperative languages are generally perceived as quite limited. Most of the new languages are mixed-paradigm, where they resemble an imperative language but have functional features. This is true of D (std.functional, pure keyword), C# (LINQ is just functional programming with SQL-like syntax), Python (map, reduce, zip, etc. are built-in functions), Java 8 (Java 7 was pure OOP), Groovy, PHP, etc. Seriously, just look at the Wikipedia article on any recent language - they'll usually have functional, imperative and OOP listed under Paradigms.

And this is precisely why it's important to learn a functional language - not because you're likely to use it directly, but because it shows you a completely different way of programming. Consider the case of a Python programmer who is asked to implement sum() - depending on whether they have a background in functional programming, it could be written as one of two ways:

def sum(list):
	x = 0
	for x in list:
		res += x
	return x

def sum(list):
	return reduce(lambda a, b: a + b, list, 0)

The functional approach results in a solution that is 1 line long, instead of 4. (It would also be half as long if Python supported using + as the name of a function.) Understanding functional programming also gives one an understanding of what side-effects are and how to avoid them, and that can result in significantly simpler and easier to debug programs.

EDIT:
Now, I should add that OOP does have some very useful aspects. For instance, it's great for GUI development (which is what it was designed for originally). But it's just one paradigm, and like procedural and functional, it has areas its good for and areas it sucks in. Java 7 was a testament to this - they had to add features like anonymous subclasses because that was the only way to pass a function to another function, instead of just allowing higher-order functions and lambdas.

[caligula]

The functional approach results in a solution that is 1 line long, instead of 4. (It would also be half as long if Python supported using + as the name of a function.) Understanding functional programming also gives one an understanding of what side-effects are and how to avoid them, and that can result in significantly simpler and easier to debug programs.

Here are few issues. The "higher order" functional stuff involves lots of boilerplate and bloat. The compilers have a hard time optimizing it. For example in C++ there are now rvalue move semantics. In D the lambdas as strings. There are really good reasons why the functional approach is bad for performance and thus destroys the whole point of using functional programming.

EDIT:
Now, I should add that OOP does have some very useful aspects. For instance, it's great for GUI development (which is what it was designed for originally). But it's just one paradigm, and like procedural and functional, it has areas its good for and areas it sucks in. Java 7 was a testament to this - they had to add features like anonymous subclasses because that was the only way to pass a function to another function, instead of just allowing higher-order functions and lambdas.

But many GUI toolkits don't even use OOP? JavaFX uses some DSL, Qt uses signals and slots and MOC, E17 has some custom GUI configuration format. JavaScript folks use asynchronous callback style. Everybody seems to hate Java's OOP Swing GUI toolkit. It doesn't seem convincing that OOP is that good for the GUI.

[Ropid]

Here are few issues. The "higher order" functional stuff involves lots of boilerplate and bloat. The compilers have a hard time optimizing it. For example in C++ there are now rvalue move semantics. In D the lambdas as strings. There are really good reasons why the functional approach is bad for performance and thus destroys the whole point of using functional programming.

The higher-order stuff is for you. For your work, the bloat and boilerplate is stripped away. For example that Design Patterns book, the majority of the patterns that are discussed turn into something simple. The book perhaps wouldn't have existed in a world where everyone knew how things work in Lisp etc. People would just be able to pull from their experience instead of the book when designing their Java code. That's why I suggested perhaps learning it for your "toy" projects. Especially for those, because the usual boilerplate is missing nearly completely from the code, it makes it fun to experiment and do massive changes to your design decisions so you'll perhaps get more out of your research.

The performance of the thing is actually impressive for what you can do with the language, and sometimes feels like magic to me. If everything goes right, your code will be fast enough that you can't really beat it with other languages... except of course C++ (or something else that can be as fast as C).

[rdnetto]

Here are few issues. The "higher order" functional stuff involves lots of boilerplate and bloat. The compilers have a hard time optimizing it. For example in C++ there are now rvalue move semantics. In D the lambdas as strings. There are really good reasons why the functional approach is bad for performance and thus destroys the whole point of using functional programming.

I agree that under some circumstances, functional approaches can result in worse performance, but the same is true of all paradigms. Similarly, whether the compiler performs poorly is a question of how heavily it has been optimized for it. (Which creates a chicken and the egg problem, since it only gets optimized for it if it gets used). So that's not so much a criticism of functional programming in general, as the languages which tack it on without sufficient optimization.

I know that in D using functional style code on ranges performs significantly better than imperative style code as it results in fewer memory allocations that need to be GC'd. (src - one of the language's creators)

Now, if your higher-order functions are implemented as templates which result in code generation (C++), I can definitely see that causing problems.

But many GUI toolkits don't even use OOP? JavaFX uses some DSL, Qt uses signals and slots and MOC, E17 has some custom GUI configuration format. JavaScript folks use asynchronous callback style. Everybody seems to hate Java's OOP Swing GUI toolkit. It doesn't seem convincing that OOP is that good for the GUI.

While I don't know about the others, Qt definitely uses an OOP approach - it's just complemented with events, same as .NET. And while the general trend today is towards declarative approaches (QML, XAML), whenever code needs to interact with those widgets it invariably uses an OOP-style approach to do so.

I don't see any reason to say something isn't OOP simply because it includes elements of other paradigms as well. Mixed paradigm languages are more powerful and expressive, so why wouldn't you mix and match as necessary?

[caligula]

The higher-order stuff is for you. For your work, the bloat and boilerplate is stripped away. For example that Design Patterns book, the majority of the patterns that are discussed turn into something simple. The book perhaps wouldn't have existed in a world where everyone knew how things work in Lisp etc. People would just be able to pull from their experience instead of the book when designing their Java code. That's why I suggested perhaps learning it for your "toy" projects. Especially for those, because the usual boilerplate is missing nearly completely from the code, it makes it fun to experiment and do massive changes to your design decisions so you'll perhaps get more out of your research.

The performance of the thing is actually impressive for what you can do with the language, and sometimes feels like magic to me. If everything goes right, your code will be fast enough that you can't really beat it with other languages... except of course C++ (or something else that can be as fast as C).

I'm fully aware of the thunks and additional bloat a lambda produces. All compilers cannot optimize it away. For example in D language std library recommends string lambdas. http://dlang.org/phobos/std_algorithm.html
a single predicate function could be easy to inline and optimize away, generating specialized code for that use case. However functional programming tends to encourage point-free mechanisms and more complex lambdas that deal with local stack allocated variables with varying lifetime and a thunk has to be created on heap. Those are expensive. Another example is Scala. People complain that standard map/fold methods are slow and resort back to while() loops if they need performance and deterministic heap allocation behavior in inner loops. So tough luck but functional programming won't really cut it this time. Maybe in 2050 if they manage to optimize things better.

[caligula]

Now, if your higher-order functions are implemented as templates which result in code generation (C++), I can definitely see that causing problems.

Actually there are quite many optimizations in place (e.g. http://en.wikipedia.org/wiki/Return_value_optimization ) and e.g. expression templates and rvalue move semantics are really powerful and do the job much faster than naive functional compilers.

While I don't know about the others, Qt definitely uses an OOP approach - it's just complemented with events, same as .NET. And while the general trend today is towards declarative approaches (QML, XAML), whenever code needs to interact with those widgets it invariably uses an OOP-style approach to do so.

I don't see any reason to say something isn't OOP simply because it includes elements of other paradigms as well. Mixed paradigm languages are more powerful and expressive, so why wouldn't you mix and match as necessary?

How I see it is that many languages might use objects and classes, but they're more like namespaces. The inheritance is overrated and rarely needed. What is OOP anyways? Are namespaces and members & member functions enough? Do you need inheritance and subtyping support? I think the solution people are often looking for is something semi-OOP. Even gobject style C supports OOP to some extent.

Another example of OOP dying is Rust language. They don't have objects at all. And they're planning to make graphical user interfaces like browsers with it.

[jagd]

To each their own, I guess. I'm just wondering why people keep improving C++14 and Haskell when obviously most people are focusing on more modern languages like: Python, JavaScript, CoffeeScript, Clojure, Groovy, PHP, Hack, Rust, Swift, Dart.

Is there really anything to achieve with these legacy languages? Especially statically typed languages seem obsolete now that people do continuous integration and run test suites. Static typing won't mix well with BDD and TDD.

For Web/Mobile apps, yes Python/Ruby/PHP are popular and enough. For scientific programming, there is no other choice than C++ if you don't want to code in FORTRAN or plan C (sure, I know numpy/scipy, for small experiments they are quite good, but not easy to scale to real cases). Most supercomputers in the world accept only MPI program in FORTRAN/C/C++, even no Java.

On the other side, C++11/14 can already do a lot high-order functional tricks. Practical features like regex, asyncs and threads are parts of the language. Comparing to C++ habits, doing things in some language without RAII is sometimes hard for me, because I'm not sure, when will the GC close a file/socket/memory, if I don't do it explicitly.

Haskell is definitively a pure "functional" language, if you wondering why, just learn and apply it. I believe that the knowledge from Haskell will improve your Python and (especially) Javascript skills.

In a very-strictly statically typed language like haskell, once your program get compiled, it will probably run correct.

Generally I didn't feel any difficulty in Testing or TDD with C++/Haskell.

However, the fact is that there is no actually modern IDE for Haskell; whereas on the C++ side Visual Studio and CLION are arising (but not good enough), QtCreator/Kdeveloper are trying to embed CLANG. The world of JVM-languages is more advanced at this point.

As I've already mentioned IDEs, statically typed languages are more IDE-friendly. It's inconvenient when Jetbrain's IDE cannot figure out the type of a variable in Python.

[jagd]

To each their own, I guess. I'm just wondering why people keep improving C++14 and Haskell when obviously most people are focusing on more modern languages like: Python, JavaScript, CoffeeScript, Clojure, Groovy, PHP, Hack, Rust, Swift, Dart.

Is there really anything to achieve with these legacy languages? Especially statically typed languages seem obsolete now that people do continuous integration and run test suites. Static typing won't mix well with BDD and TDD.

For Web/Mobile apps, yes Python/Ruby/PHP are popular and enough. For scientific programming, there is no other choice than C++ if you don't want to code in FORTRAN or plan C (sure, I know numpy/scipy, for small experiments they are quite good, but not easy to scale to real cases). Most supercomputers in the world accept only MPI program in FORTRAN/C/C++, even no Java.

On the other side, C++11/14 can already do a lot high-order functional tricks. Practical features like regex, asyncs and threads are parts of the language. Comparing to C++ habits, doing things in some language without RAII is sometimes hard for me, because I'm not sure, when will the GC close a file/socket/memory, if I don't do it explicitly.

Haskell is definitively a pure "functional" language, if you wondering why, just learn and apply it. I believe that the knowledge from Haskell will improve your Python and (especially) Javascript skills.

In a very-strictly statically typed language like haskell, once your program get compiled, it will probably run correct.

Generally I didn't feel any difficulty in Testing or TDD with C++/Haskell.

However, the fact is that there is no actually modern IDE for Haskell; whereas on the C++ side Visual Studio and CLION are arising (but not good enough), QtCreator/Kdeveloper are trying to embed CLANG. The world of JVM-languages is more advanced at this point.

As I've already mentioned IDEs, statically typed languages are more IDE-friendly. It's inconvenient when Jetbrain's IDE cannot figure out the type of a variable in Python.

[caligula]

As I've already mentioned IDEs, statically typed languages are more IDE-friendly. It's inconvenient when Jetbrain's IDE cannot figure out the type of a variable in Python.

You could use hungarian notation and match the prefixes of variable names with ctags like functionality. It's really not a problem.

[DanLamb]

To each their own, I guess. I'm just wondering why people keep improving C++14 and Haskell when obviously most people are focusing on more modern languages like: Python, JavaScript, CoffeeScript, Clojure, Groovy, PHP, Hack, Rust, Swift, Dart.

Is there really anything to achieve with these legacy languages? Especially statically typed languages seem obsolete now that people do continuous integration and run test suites. Static typing won't mix well with BDD and TDD.

Wow...

Static types are still preferred by many developers. Ideally, your static type system does some application verification for you, and your unit tests test higher level logic. Without static types, your unit tests have to do more.

C/C++ is obviously important for low level software, like device drivers, OS level stuff, embedded software, etc. It's the dominant language for writing game engines and is usually paired with a higher level "scripting" language like Lua/UnrealScript/JavaScript/C#.

Haskell is very elegant, high level language. Scala is highly influenced by Haskell, with a trade off of loss of purity and elegance for practicality and much better interop with other developer products and a richer ecosystem.