F#, Enterprise JavaScript at QCon London

The best sessions here at QCon London have been the small ones, not the big ones. Yesterday the slot I enjoyed most was from Attila Szegedi on JavaScript in the Enterprise. He uses Mozilla Rhino for server-side development. It’s not a mainstream choice; but he made a case for it, saying that continuations in JavaScript bring huge benefits, that there is a ready supply of developers with JavaScript skills (albeit mostly browser-based), and JavaScript is so flexible that he can work around any limitations.

One example is that JavaScript has no namespaces; but it does support function pointers, so he adds a bunch of function pointers as members of an object, and then that object works like a namespace.

Szegedi says he has little interest in ECMAScript 4.0 – once thought to be the future of JavaScript – because there is no community consensus around it.

Today I’ve just attended a session on Microsoft F# given by Amanda Laucher. F# is a functional language that will be released as part of Visual Studio 2010. I knew little about it until today. Laucher gave a code-heavy presentation looking at how the ease of concurrency in F# can greatly increase speed of execution, using an example from the car insurance industry.

Laucher said that threading in C# is horrible in comparison.

Developers are not going to abandon C# or Visual Basic in favour of F#. Rather, they will encapsulate pieces of functionality in F# where they can get benefit, and call them from their C# or VB application.

Technorati Tags: ,,,,,
VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. QCon London 2009
  2. QCon London
  3. QCon London 2010 report: fix your code, adopt simplicity, cool .NET things
  4. Sold out QCon kicks off in London: big data, mobile, cloud, HTML 5
  5. Microsoft’s platform nearly invisible at QCon London 2012

2 comments to F#, Enterprise JavaScript at QCon London

  • zorg

    Hi Tim,

    I’ve read your article “Mind your language” in the guardian. I’ve found a few inaccuracies I would like to point out :

    > The recent trend is towards dynamically typed languages, which use inference to reduce the amount of code to be written.

    I think inference is actually used in the context of static languages which infer the types of your programs at compile-time.

    > In static languages, the programmer must declare each variable’s class (such as string, integer, or list) before the program runs;

    This is not true for the ML family of programming languages (SML, OCaml, Haskell) which can infer (nearly all) your types at compile time without requiring any declaration. This is what inference is. (http://en.wikipedia.org/wiki/Type_inference)

    > Relying on inference is arguably more error-prone, but developers overcome this by creating tests while programming that verify the correctness of their code

    you probably mean : dynamic languages are more type-error-prone

    It’s important to note that testing cannot “overcome” program errors, you might well have introduced an error in your test for all I know ! As the quote goes : “Program testing can be used to show the presence of bugs, but never to show their absence!”

    To have guarantees you need : http://en.wikipedia.org/wiki/Formal_verification

    > Advocates of dynamic languages also argue that their code is easier to follow, making errors less likely.

    what is known is:
    - no moderately complex program is bug free
    - the fewer lines of code the less bugs are likely to be found.

    So expressive languages (which allow to mean more by writing less) should lead to fewer bugs.

    > In static languages, such errors are caught by the compiler before the program runs, which is why some developers regard static typing as safer and more reliable.

    I find this misleading : yes, a whole class of errors get caught at compile time with strongly-typed static languages. But there are a lot of other errors a programmer can make beside typing errors and some are more critical than others…

    For instance following your previous statement, would you say that C, a static language is safer than say, Python, a dynamic language ?

    Also, is you language built for fault tolerance (where some errors can be recovered) ?
    Erlang another dynamic language, has achieved a 99.9999999 reliability (that’s 31 milliseconds down time
    a year) !!!

    > Also, today’s computers have multiple processors, which means that software has to be able to split tasks into several threads that can execute simultaneously if it is to work at the greatest efficiency. “After working with C# threading, I never wanted to do threading again,” said Microsoft’s Amanda Laucher at QCon, explaining why her company has developed a new language called F# that is optimised for the purpose.

    F# is a port of Ocaml to .Net. It is a new effort but Ocaml started in the early 90′s.
    Ocaml was not designed with concurrency in mind.

    I believe F# gives you the possibility to use 2 sane alternatives to threads (shared state concurrency) :

    1) nothing-shared-message-passing a la Erlang
    2) Software transactional memory (which is nice because you can still think sequentially) and which first appeared within Haskell.

    And that’s about it.

  • tim

    Hi Zorg, thanks for your comments.

    The problem here is how to convey something about the nature of dynamic languages to a general reader without losing them. I’m not sure how well we succeeded but I hope the piece communicated some of the reasons for increasiing use of diverse languages.

    Tim