willtim

Firefox on mobile has improved enormously since Quantum. It works well enough to ditch Chrome.

Yes it seems strange to me that a Java developer is willing to learn Spring, a massive ad-hoc framework which exists in part because of Java's weaknesses, rather than functional programming and Clojure (a lifelong skill that will benefit their Java programming).

> Many static languages have no dynamic types, I think that's worse.

I can't think of a static language that doesn't support a dynamic type, it's just that most require explicit casts or unpacking to use with existing typed interfaces, e.g. "Object" in Java.

> Strongly typed used to mean safe

It still does, it's just that type theory doesn't distinguish between a runtime failure with a nice error message versus a segfault, both are programs that "go wrong".

I would be in favour of "strong dynamic types" instead of "strongly typed".

Hopefully carefully considered and well-designed technology will prevail. In this industry we are often too eager to endorse the first-mover as the standard.

It's easy to forgot the benefits of laziness: http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev...

Laziness is a good default for declarative programming. Nix from NixOS is an example of a recent lazy language and benefits greatly from it.

Even in strict languages, lazy behaviour is often added, for example iterators and streams. Mixing effects and mutation with such constructs is also problematic.

History is littered with purpose built languages and notation for mathematics, logic, music and law etc. A language guides (or limits) one's thoughts, offering a particular set of abstractions. Functional programming is very close to logic and particularly amenable to mathematical reasoning and static analysis - exactly what one needs in order to safely compose large programs from small ones.

By "major options", I guess you mean popular/mainstream options?

Haskell is an excellent example of a community-driven language. It's more mature and advanced than most commercial offerings too, offering a superior type system, fast and efficient executables, lightweight fiber concurrency, software transactional memory, higher-kinded parametric polymorphism and many more features.

Intel certainly does not know how to build a secure CPU.

> That's true (and will be addressed)

Glad to hear it! It's probably the biggest issue trying to do functional programming on the JVM.

> There is no difficulty supporting that. In fact, the Java language is about to get that without JVM changes.

The technique to implement ADTs in functional languages on the JVM has often been to add an integer tag to every subtype and switch on that, but it's ugly enough for interop that IIRC Scala doesn't do it (and is thus less efficient).

> What are the restrictions on F# that were posed by them?

It does make it harder to add features to the language that do not map to the current reified "generics" spec, for example higher-kinded polymorphic types.

Of course, the JVM has plenty of issues supporting alternative languages too, for example lack of tail-call optimisations, or switch-on-type, for functional languages.

I was not comparing Flash to the JavaScript of the era, just pointing out that, as an end user, Flash didn't seem "fast" to me (on Linux, Android and OSX). Performance on a desktop-class CPU is also only one metric. Flash was clearly inefficient, it didn't use multicore, GPUs or hardware decoders. Was your Quake2 demo above using even OpenGL? Java applets could do that since well before 2008. The original Quake2 could do that in 1997.

> Care to guess why it was a flash-based game and not an HTML5 based game?

Anything would have been better, even bare HTML tables with no animations. The user experience of Facebook Flash Scrabble was awful (at least on OSX).

All good points. But I'm still struggling with the idea of using the word "fast" to describe a technology that brought a 2GHz GPU-accelerated machine to its knees with Scrabble. Perhaps "sucked less than JavaScript"?

Which bit was fast? My wife's MacBook sounded like a jet engine whenever she would play the Facebook flash-based Scrabble. Eventually the machine died of fan failure and I had to spend an entire afternoon doing brain surgery on it. I wasn't surprised when Jobs subsequently banned it from the iPhone!

Bazel has not "been stable for years", perhaps you are thinking of "Blaze"? Bazel is full of brand new code and recent bugs (such as not releasing file handles) suggest it is not yet fully ready for mass adoption.

Google the "Out of the Tar Pit" paper by Moseley and Marks. After incidental complexity, Accidental complexity is the all remaining stuff. It's the complexity you wouldn't have to deal with in an ideal perfect world. For example: manual memory management, performance optimisations, JavaScript equality semantics, aspect-oriented programming, dependency injection frameworks or any other ad-hoc technology to work around issues further down in the stack.

It's one of my all-time favourites too. The Criterion Collection edition I believe contains the final directors cut. The ending is superb, it beggars belief that Hollywood tried to butcher it.

Yes I like Dhall, I also had a go at my own one a while ago: https://github.com/willtim/Expresso

In my opinion, a statically typed config file would be preferable.

Congratulations and a huge thank you to all those involved! Emacs is a truly remarkable piece of software. I started using it for text editing over 20 years ago, now I use it pretty much as an operating system!

IMHO the windows phone live tiles made the static iPhone icons look very dated (they are essentially unchanged from 1980's NeXTStep). Even now I believe the iPhone clock and calendar icons require privileged hacks to show the correct date and time.

It's certainly not as readable as the Haskell version, despite the claim to the contrary in the comments. But it's nice to see them supporting this style of programming.

> Hmmmm, I wonder how a subscription can cause side effects?

A subscription is a side effect.

IIRC they are essentially Monads, but someone decided that was too scary a name. The result is confusion for experienced programmers, ironically the ones more likely to use F# (!)

The monad does enable imperative programming in Haskell, yes. But it is not needless complexity. It enables an imperative program to be assembled using a pure functional program. Imperative statements become first class values, control flow constructs can be just user-defined functions, no macros needed. Monads, of course, also allow us to change the meaning of a semi-colon. This can be used, for example, to implement lightweight fiber threads with custom schedulers, again all without macros.

It has been said that Haskell is the world's best imperative programming language: https://stackoverflow.com/questions/6622524/why-is-haskell-s...

> And since FP is a style, it can be followed quite effectively in almost any language.

It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised.

It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.

Well if it was a MacBook, everything would be glued-in or soldered, but yes the trend is worrying. I guess the popularity of MacBooks, despite their form-over-function, is what is driving this. But surely they could have kept the T490 like the T480, especially as the T490s exists.

You never defined what you meant by a "good concurrent GC", only now are you asking for "performance" numbers.

My point is that writing a GC for Java has in fact proved very difficult. It took Sun and Oracle many man years and different GC designs to get where they are today. So it seems Java also needs a "good" concurrent GC. With both functional and OOP languages generating a lot of garbage and sharing language features, I don't see a big difference in requirements in practice. And sure enough, Clojure/Scala seems to work well using the JVM GC and F# seems to work well with the .NET GC too.

I think the burden of proof rests with you and your statement that the concurrent GC situation is somehow more challenging for an FP language.

> I only accept CS papers about it

Me too

There are a few papers about Haskell's GC by Simon Marlow where this is discussed. The absence of mutable references is a big win for writing a concurrent collector.

I'm not a web developer, but I don't think the OOP features of JavaScript are really used much. I once saw some jQuery code and it looked pretty functional to me.