http://www.infoq.com/interviews/paul-hudak-haskell-Qcon-SF-08&language=en

http://www.infoq.com/interviews/F-Sharp-Don-Syme

http://www.infoq.com/interviews/LINQ-Erik-Meijer

Programming with a Mainstream Language

Track: Functional and Concurrent Programming Languages Applied

Time: Thursday 17:15 – 18:15

Location: Abbey Room

Abstract:

Using functional programming (FP) in enterprise software development is often quite a challenge. In this presentation, Sadek Drobi will talk about his experience of applying functional programming principles on a real-world project in relation with existing non-functional frameworks.

In the year 2008 and just on the release of C# 3.0 and Linq, which is basically several FP concepts implemented on C# language, Sadek Drobi worked as a tech lead on a project where functional programming approach was used to meet performance requirements and to achieve desired response time. Facing similar issues, a mainstream architect would strive to instantiate less objects and to use mutation for optimization. Considering the big amount of data that had to be processed on each request, Sadek chose to do it otherwise: no mutation, used memorization, laziness, recursion, functions, curry, monads, list comprehensions and, then, parallelization to yield an almost purely functional core domain model.

Sadek Drobi will talk more about this experience and elaborate on the good and the bad of going almost extreme through a functional programming approach from different perspectives.

Participants don’t need to be functional programming experts even if having some knowledge about LinQ will spare you too much hard thinking during the session. Each new concept will be briefly introduced and the structure of the talk will be as non-sequential as possible so that its parts can be understood and analyzed separately.

http://www.infoq.com/news/2009/01/rwh-book-interview

originally posted on http://www.infoq.com/news/2009/01/pl-predictions-2009

In the beginning of the last year, Ehud Lamm launched a thread on Lamba the Ultimate inviting other bloggers to submit their predictions for 2008 in fields relative to programming languages (PL).

Concurrency was one of the first topics to be defined as an upcoming theme of the year even though it was argued that it “won’t go anywhere because the current paradigms […] and architectures […] can’t deal with it very well”. Many equally ambivalent predictions concerned functional programming languages. Haskel was supposed to “rock the blogosphere” without being widely used as such, but rather becoming an inspiration for new features in more mainstream programming languages. More generally speaking, some expected that “no functional language [would] become significantly popular”, while several other bloggers had far more optimistic prognoses for F# and Scala that were to “enjoy large uptakes”, at least through the development of "multi-language" projects“ in some combination of F#/C# or Scala/Java”.  As far as other languages were concerned, Java was supposed to become “more entrenched”. And the same was to happen to Ruby that would be undermined by the downtrend of Rails. On the contrary, C++ with its new ISO standard for 2009 was expected to “become the language-of-the-year in 2008” and Javascript to gain more momentum.

As an echo to this tread, James Iry asked bloggers at the end of 2008 to share their opinion on “what was noteworthy about 2008 as far as programming languages were concerned”.

Trying to assess the validity of last year predictions, Key Schluehr believes that concurrency was far from being the theme of the year. And, if there were one, it was, in his opinion, “cloud computing”, even though he considers that “this had little to with computing at all”. He also asserts that, just like Morris Johns expected, no functional language became significantly popular, which many other bloggers disagree with.

James Iry argues indeed that even though no functional language is at Java or even Ruby level of popularity, “the fact that languages like these popped up so brightly on the mainstream radar last year is not just significant, but huge.” Eli Ford highlights that “F# got its own CTP in September, and is now slated for a supported release as part of Visual Studio 2010, alongside C# and VB”. And Sean McDirmid argues that “as far as specific languages go 2008 was a good year for Scala”. “Clojure”, that was not at all mentioned in the last year discussion, is considered to be the discovery of the year by Chris Rathman who believes that it is a good example of how “to go about integrating existing concepts into a programming language”.

Along with Scala, Sean McDirmid mentions Objective C “as the real hot language of 2008 thanks to the iPhone SDK” and believes that 2008 was also the year of C vengeance with various forms of it being “used to program GPU hardware (HLSL, CUDA, OpenCL…)”.

On the other hand, several bloggers highlight that last year was not that good for Java. Sean McDirmid asserts that “JavaFX was late and didn’t make the splash it needed to make”. If it is true that bloggers express some concerns about Java’s future, Daniel Weinreb stresses that “it’s used in so many places now that we’re very unlikely to see it disappear” and, according to James Iry, “it is still and will remain for quite awhile one of the a handful of "safe" choices for an IT manager”. Others question however the capacity of Sun to survive the current crisis and speculate about the future of JVM expecting IBM or Google to step in.

The discussion moves from 2008 to 2009 and a number of new predictions are made. In the field of functional programming, James Iry expects great things from both Clojure and Scala teams while Falcon argues that “2009 will be a year of clojure rather than scala” and expects F# to be finally brought “to the attention of mainstream .NET developers.” Ross Smith, however, reiterates the prediction of last year that functional programming will enter the mainstream rather “by being incorporated into pre-existing procedural and OO languages”. He also believes that “the new C++ standard will become official”, “concurrency, including GPGPU applications, will continue its rise in importance”, “Python will start to bleed users specifically because of [its] lack of good support for concurrency” while “JavaScript’s star will continue to rise”.

Xscott goes along the same lines about JavaScript predicting that it “will eventually become the popular server and application scripting language – mostly because of it’s various JIT compiling implementations”, whereas Kay Schluehr believes that it “will not expand on its niche”. On the other hand, he thinks that “one of the great-future-of-programming hopes like Perl 6, Rubinius or PyPy [will] finally [reach] a state where programmers other than core developers start to show interest.”

Kaveh Shahbazian believes that “one thing [that] is going to happen [in 2009] is finding new approaches to employ scripting” and names Lua as a successful example. And, last but not least, Sean McDirmid predicts that “no progress will be made on the static/dynamic debate.” :)

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

Yet another clueless manager

Nov 17, 2008 9:33 AM by Ilya Sterin

First, methodologies are only as good as the people that apply them. I hate the thought of process over people. Intelligent people will find a way to produce good software, agile or not. Morons will fail even with the process. Software development is more art than it is science, though I wish the people that never made it as software developers would stop trying to pile process on top of process and think that engineers are code monkeys that can develop good software by following some process. Process is good, but smart people are better.
Also, it’s not that agile is failing, software projects are failing and have been failing before agile and will be failing after. Again, this is art and creativity is required not process.

Thanks Ilya for the comment!

Originally posted on http://www.infoq.com/news/2008/10/scalable-datamining-alternative

On his blog, Dan Pritchett suggests an alternative solution to data warehousing applications. Although reluctant about “solutions that can only be implemented in a single address and storage space”, he acknowledges that sometimes data needs to be aggregated in order to be analyzed. This is precisely what data warehousing applications do offering the possibility to aggregate information along a variety of axis and to invert relationships in the data. Their usage, however, has significant downsides according to Pritchett. Not only are data warehousing applications expensive and “often out of the reach of smaller organizations”, but the way Extract, Transform and Load software (ETL) functions induces costs in terms of scalability and reactivity:

First, the ETL places a significant load on your production databases. If your business has nice offline windows for the ETL, that’s great, but if not, managing the scale becomes a challenge. Second, the freshness of the warehouse is typically 24 hours behind or more. As your business grows this lag will grow as well.

Dan Pritchett believes that there could be a solution that would be less expensive and more scalable: processing streams of events using an Event Stream Processor (ESP) solution.

ESP analyze streams of events using a language similar to SQL. In the same manner that databases and data warehouses use SQL to perform analysis of data tables, ESP use their query language to analyze streams of events. The simplest way to understand ESP is to think of events as rows in a table and the attributes of an event as the columns. Each event type is the equivalent of a table.

[…]

[ESP analyzes] the changes to your data as it occurs. Rather than doing batch ETL’s, you stream business events as the state of your data changes. This creates a more manageable scaling model for your production system.

[…]

ESP can also be horizontally scaled, providing a more cost effective solution for your business. And since ESP is performing the analysis in real time, the business metrics can be current and remain that way as the business grows.

Dan highlights however that this approach does not allow performing historical analysis in order to get on the business activity a perspective that is different from the one considered at real time. A solution Pritchett mentions could be a framework for capturing and replaying transactions, which would however be rather costly. Commenting on the post, Tahir Akhtar suggests another possible solution: replacing ETL by ESP but continue using data warehousing applications in order to preserve the ability to do historical analysis while taking advantage of ESP scalability and reactivity.