willtim

> They add significant complexity to the language and are intended to help with correctness. But are they an effective way to achieve it compared to alternatives?

Python programmers say the same about all static type systems. What alternatives do you have in mind? Are they as generally applicable as dependant types? Dependant types are a simple and unifying way to solve a variety of shortcomings with conventional statically typed systems. For example, dependant types can express first-class modules as simple records, or allow sophisticated record operations like merge to be well-typed.

> [tracking algebraic effects] But is that even a worthwhile goal? Why is it nirvana to more easily do something that might not be worth doing at all?

Given the various hugely expensive bugs I have been involved in (e.g. Java toString on a date reading the system locale). I would say yes. In my industry, reproducable numbers are of vital importance, so much so that the quants use Haskell in preference to something more mainstream and supported.

> imagine an incredibly-detailed computer simulation of a brain, down to the level of individual cells and neurotransmitters. (While this is beyond our current capabilities, it is in principle possible.)

The laws of physics start to become relevant here. It is quite likely that it is not possible to simulate a human brain using a classical computer, at least not at any kind of speed such that it can experience the world as we do.

> We do not observe large differences between and in companies based on language choice.

Hmm, I think it's pretty clear that most folks are far more productive in Python than say C++. But yes, I agree that there's no silver bullet, programming is hard.

> I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money,

Bad language design and semantics definitely costs money in the long term. For example, Tony Hoare refers to Null References as his "billion dollar" mistake. The verbosity of Java before sophisticated IDEs would also have cost significant time and money. Java is improving significantly (and arguably was never as bad as say JavaScript or PHP), but there are some legacy decisions that will be very hard to change; and so improvement can only ever be incremental.

Indeed and Haskell still has this issue today, because member access is a top-level function.

Absolutely, using an integer instead of a static sum type hides the problem and actually makes it harder to solve correctly.

If one doesn't specify a comparator and there is no obvious/sensible default, then an error would be perfectly reasonable.

Most would expect 10 to parse as an integer. To specify a string, most would be happy with putting quotes around it. So I don't think dynamic types fully explains the bizarre behaviour.

Wow, who came up with that idea? And people say Haskell is hard to learn...

Even a foreach loop in e.g. Java or C# bakes in a particular iterator interface into the language. The precedent was set long ago. Languages like Swift and Kotlin are just minor evolutions of these previous OOP languages.

What a fantastic call to arms! I'm tempted to get involved myself after watching this talk. I couldn't agree more with everything SPJ said.

Light modes were arguably worse on CRTs, especially if the refresh was 60Hz or less. I couldn't take Word for Windows at all seriously until Windows NT and 85Hz CRTs appeared.

I currently use both light and dark themes on Emacs, with a shortcut to toggle between them. Solarised is a great theme for this, as the text colours are the same for both modes. I originally started using a light theme during the day, as so many other apps already do and I disliked the sudden change in brightness when for example switching between Emacs and a web browser.

As I said elsewhere, it ultimately affects our pension pots. The "someone" you mention are the executives who take risks at the shareholders expense.

I don't think "no one is being forced to do anything here" is justification for the unprecedented inequality and the existence of billionaires.

The money doesn't come from thin air. If SoftBank paid it out, the shareholders lose out even more so.

Better for our pension funds, yes. The stock price of SoftBank has halved in value over this event. I'm expected to fund my old age using stocks.

Completely agree. I don't know why you are getting downvoted, capitalism in its present form is clearly broken. The payout sum here is ludicrous, it is certainly not justified in terms of value created for society. This money has to come from somewhere and ultimately the common folk will be paying the price.

Wow, that's a huge difference. I'm tempted to try OpenBSD just for those man pages.

Yes those words are too strong, but NixOS has certainly halted my Linux learning over the last few years :) In terms of configuration it's usually just "some.feature = true". Whereas with Debian, I'd go read a blog and cut'n'paste commands out of it and cross my fingers that they'd perform the correct mutations of my own OS.

I haven't tried it, but many are saying the Deepin desktop is better than all of the above.

There are some advantages to this approach that often go unmentioned. Native widgets often have ad-hoc limitations based on their legacy, for example limits on composing/nesting widgets (can a list box contain a list of arbitrary widgets?) and system resource limits (e.g. windows handles). Attempting to build a cross-platform UI that maps to different legacy systems each with their own quirks and limitations, will never produce something better than QT or Flutter IMHO.

Lenses are not necessary to practice FP, just sometimes useful (and Edward didn't invent them). Try updating a deeply nested record in your favourite imperative language without mutating the original (!)

People should learn a functional language, even if they do not intend to ever use it professionally. Languages are tools for thought and if you only know imperative programming, it will limit your thinking (for example, one well-respected OOP programmer on stackoverflow seriously suggested modelling a bank account with a mutable number). Functional programming ideas are gaining traction and have made big contributions to distributed computation, filesystems and databases recently. Don't get left behind by dismissing it all as niche. You'll also get a preview of the upcoming Java and C# features.

> Purely functional algorithms and data structures are typically slower.

Functional persistent data structures bring many advantages, even to imperative programmers. For example, if your text editor used a persistent data structure, it probably wouldn't need to lock you out during a save and would support better undo. Mutation is efficient, but comes with many drawbacks, especially when state is shared or provenance is required. This is why functional data structures and ideas are appearing outside of functional programming, for example ZFS, git, Blockchain, Spark, Kafka etc etc

> Imperative code is also more concise than equivalent functional code.

This couldn't be further from the truth. Just as Fortran liberated arithmetic expressions from the verbosity of imperative programming, FP allows us to move beyond non-compositional word-at-time sequences of mutation commands and build much higher-level abstractions. Modern imperative languages have borrowed many ideas from FP, but are still no way near as expressive as e.g. Haskell. Of course, imperative programming is still very useful and that's why Haskell has good support for it.

If I understand correctly, applying a JavaScript Async function is effectful and starts the background tasks. A better design is for the async function to yield an Async computation when applied. These computations can then be composed and passed around with full referential transparency. Only when we run the final composed Async computation, should the effects happen (threads running our computation). This is how the original F# asynchronous workflows were designed, which predate the C# and JavaScript implementations. Thankfully Rust works this way too!

I'm trying to understand the semantics not the implementation. The semantics are clearly not "let x = .. in .." as anyone familiar with expression let-bound variables would expect. I wish I could avoid Python but sadly it is taking over the world. It's even taught at schools now and my kids will be learning it as their first programming language.

That is really really confusing given that there is lots of prior art for = meaning variable binding and := assignment (Algol, Pascal etc). Using = for assignment was a bad decision and it's coming back to bite.

EDIT: Based the examples given, the Python := operator doesn't appear to behave as a let binding. The scoping suggests it is another form of assignment.

> Go is actually one of the best in terms of design.

I respectfully disagree. Go's primary goal was to be (superficially) easy to use and familiar. Because of this, it fails to tackle the big issue with doing concurrency in most prior mainstream languages. Go has mutable state deeply baked into the language and makes it difficult to work with immutable data. Go is not necessarily easy to use if ones goal is to build correct concurrent software.

Yes, but my point is that it's a flaw in the language to allow this. Not all high-level languages share Go's problems. However, even Go would be a huge safety improvement over C++.

I agree a stale read is bad. And I am surprised that the Go designers have repeated many past mistakes. It is possible to design a concurrent high-level language that does not have such issues, despite the hardware. For example, if all communication is done via channels, then synchronisation can be automatically performed during channel read/write. For shared mutable state, Haskell's software transactional memory and Erlang's Mnesia are both excellent examples of safely dealing with it.