Tomas Petricek

I'll try to answer your questions best I can.

1. Yes, as long as there are new machines that need programming, new programming languages will be needed. Today's top languages were built for the machines of the 1970, 80s, and 90s. Tomorrow's languages will be built for machines of today and tomorrow. As Alan Kay put it, if you want to invent a new language, first invent the machine of the future and then build a language for it.

2. No, you cannot. First of all, PL devs are cats, it's very difficult collecting them without financial compensation. So if your plan is to post a language and hope that people will come help you, you'll likely be disappointed. The problem is that everyone else interested in building PLs has their own itch to scratch, and they're not going to scratch yours without some compensation.

You might think "Well I can just raise money to do this", and you would be wrong. First, it's very hard to raise money for PLs. Usually you have to have come sort of cred to do it. I know of only 3 projects to have raised VC money for a PL project, and they each had some success before they had done so: Chris Granger (Light Table), Paul Biggar (CircleCI), and Chris Lattner (Swift/LLVM). Granger's project Eve raised $2M and ran out of money after 3 years; Biggar's project Dark also raised money, then fired all the devs when he realized he was burning cash too fast, then he slow-burned development for years, then he gave up and handed development over to someone else;…

Like every language I learned to program in I had a project and then decided to use that language with that project. I have to admit the first project was killer, it took me a long time to even get the code compiling. But once I had finished and looked at the lack of code I was sold that this was the way to go.

There is a really cool tutorial on writing the game of life in 32 lines of F# or writing the game of life that executes on the GPU using a similarly small amount of code.

http://tomasp.net/blog/accelerator-life-game.aspx

Start with a small project and learn the language, once you have a quite specific 'How do I do X?' question there are plenty of examples. I've never been the type person who could pick up a language from a book.

If you're doing ASP.NET google for F# + MVC + NHAML. There is a great tutorial for getting an ASP.NET project going in F#.

I'd say the primary thing that you need to learn for F# is how to convert loops to recursive functions and vice-versa. Also, look into the pipe operator, and figure out how to abuse the hell out of Seq.reduce and Seq.scan.

If you like LINQ and lambda's in C# you'll probably like F#, I'd say that's what really got me interested, I ended up loving LINQ and lambdas and wanted to know more about this whole F# deal. Using the pipe operator makes the whole thing look much more pretty IMHO.

[0..10]
|> List.map (fun x -> x*x)
|> List.reduce (fun a b -> a + b)

vs.

Enumerable.Range(0,10)
.Select(x => x*x)
…

I like this and have a similar frame of mind. I wish more languages would make their sum types true duals of their structs (with a single payload datum - instead we have tuple variants and structure variants and so-on complicating matters for at best a character of syntax (but careful design could eliminate even that).

The author may be interested in coeffects as the dual of effects. They are pretty much as stated: coeffects are the context environment the that program executes in. This link has some prototypes of languages that let you create coeffects in your code: https://tomasp.net/coeffects/

I was going to bring up covariance vs contravariance but the author mentions they were skipped for brevity.

Finally I really think simplifying to the point we ignore the idea of consumed-produced values is unfortunate. Consider how “inout” parameters aren’t too much different to a mutable reference (though the change in binding may be more explicit in a pure functional language). From the article it’s pretty clear why inout/reference parameters need to be invariant (both covariant and contravariant). And there is a whole lot that this kind of reasoning can bring to understanding Rust’s borrow checker and possibly how to create something simpler with the same strengths. But for that we’d need to model immutable references, unique mutable references and dare I say also volatile references (the environment IS volatile, whether it’s your physical peripherals or your application…

"Agile" is, as best as I have been able to tell, defined as "anything not waterfall."

The line "The IT industry today treats waterfall as something old while agile is cool" reflects more the lack of general understanding people have of software engineering and history.

"Not waterfall" was as a common theme in the famous 1969 NATO conference which kicked off 'software engineering'. For example, (quoting http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ):

> The need for feedback was stressed many times. ...

> Fraser: (from The nature of progress in software production) »Design and implementation proceeded in a number of stages. Each stage was typified by a period of intellectual activity followed by a period of program reconstruction. Each stage produced a useable product and the period between the end of one stage and the start of the next provided the operational experience upon which the next design was based. In general the products of successive stages approached the final design requirement; each stage included more facilities than the last. On three occasions major design changes were made but for the most part the changes were localised and could be described as ‘tuning’. ...

> The use of feedback from a partly designed system to help in design, was discussed at length.

Of course, "waterfall" as a development model wasn't even formally described until a year later, or coined for another 7 or so years.

I like the description from…

The developers I've encountered that use F#'s Async get confused at first mainly because they are used to C#'s Tasks being started upon creation. I personally think the F#'s model conceptually is better and I've seen more surprises with the C# one from dev's I've worked with (e.g. which SynchronizationContext is set and why does it work in my test but not in the app, why is there no trampolining and I'm deadlocking here, why do I need to pass around CancellationTokens everywhere, etc). There are benefits to the F# async model (execution) such as implicit cancellation token parsing from the root task which is much harder to implement if the Tasks are already started before you finish the root, that they are re-runnable, they can run on whatever context you want easier at the composed root level, and the fact that it uses a more generic feature in the language (which usually comes with a slight performance overhead). Both F#'s Async's and Tasks aren't the best for CPU parallelism IMO anyway - my impression is that they are for using up idle IO time across a number of threads more efficiently. An article which I think compares the two despite it being biased a little to F# rightly or wrongly: http://tomasp.net/blog/async-csharp-differences.aspx/

A Science of Operations by Mark Priestley (http://www.springer.com/gb/book/9781848825543)

This is cheating a bit, because the book is history of computer science rather than computer science, but I think anyone interested in programming should read it. We often think about history of computing (and what it teaches us) in a retrospective way (we see all the amazing totally revolutionary things that happened), but it turns out that if you look deeper, there is often a lot more continuity behind key ideas (and we just think it was a revolution, because we only know a little about the actual history). This book goes into detail for a number of major developments in (early) programming and it makes you think about possible alternatives. It was one of the books that inspired me to write this essay: http://tomasp.net/blog/2016/thinking-unthinkable/