Tomas Petricek

mainly talking about f# here... this looks like the classic example for f# type providers. there are a few talks tomas petricek[1] has given on that topic. the relevant talk is one of the skillsmatter talks[2] i'm not sure if they're all publically available, but they used to be at least. edit: but basically the summary is that you can do really cool things with type providers and have your ide(visual studio) give you full completion on parts of data you want to analyze. kinda like re# but without having to generate half a million lines of xml for web services. there's also book coming up with chapters about it from tomas [3] [1] http://tomasp.net/ [2] https://skillsmatter.com/members/tomasp#skillscasts [3] http://www.manning.com/petricek2/

You'd probably like the work of Tomas Petricek: https://tomasp.net/ He does research in "the history and philosophy of programming", amongst other things.

This old obscure blog post about framework patterns has resonated with me throughout my career and I think it applies here too. LLMs are best used as "libraries" rather than "frameworks", for all the reasons described in the article and more, especially now while everything is in such flux. "Frameworks" are sexier and easier to sell though, and lead to lock-in and add-on services, so that's what gets promoted. https://tomasp.net/blog/2015/library-frameworks/

I keep reading good things about F# but at the same time it seems to fly under the radar, with not enough learning material out there I did love this one article http://tomasp.net/blog/2018/write-your-own-excel/ EDIT: Submitted the link here https://news.ycombinator.com/item?id=24980325

In my mind, there are three really great little languages: * datafun - attempt to extend datalog to more generic computation. http://www.rntz.net/datafun/ I liked simillar exploration of computing with latices with the concept of propagators: http://web.mit.edu/~axch/www/art.pdf * dhall - configuration language that has user defined functions, but is total :) https://github.com/dhall-lang/dhall-lang * the gamma - a visualization/data query language : http://tomasp.net/blog/2017/thegamma-getting-started/

I hadn't heard of that phase, but that's great touch point. It reminds me of http://tomasp.net/coeffects/.

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/

You might be interested in coeffects. Just like monads can be used in a language like Haskell to model effectful operations, you can use the dual of monads, comonads, to model the dual of effects, coeffects! Coeffects can be used to represent the "context" of a program, which includes things like permissions or capabilities that the program may have access to. They provide a fascinating way of modeling all kinds of information that is traditionally not handled by even powerful type systems like OCaml's or Haskell's. You can read a lot more about the topic on Tomas Petricek's website: http://tomasp.net/coeffects/ I especially recommend this short article from 2014: http://tomasp.net/blog/2014/why-coeffects-matter/

It'd be great if the authors now compared TDD/TLD with TFD (Type First Development). Side reading: http://tomasp.net/blog/type-first-development.aspx/

> it's my understanding Go exists as a simple language on which to build larger programs, not as a "one true way" language with everything included. I agree. However, there is a big difference between libraries and frameworks. I believe frameworks are an antipattern in any language, not just Go, but Go's emphasis on simplicity makes frameworks for it especially grating to me. Rather than poorly summarize, I'll link two of my favorite articles criticizing frameworks; one is humorous [1] and the other is more serious [2]. [1] http://discuss.joelonsoftware.com/?joel.3.219431.12 [2] http://tomasp.net/blog/2015/library-frameworks/

I would much prefer the coeffect system for managing different platforms and capabilities: http://tomasp.net/blog/2014/why-coeffects-matter/ It would be so amazing to be able to take all of those ifdefs and turn them into type variants and have the compiler enforce the safety and semantics of the system. And it would be phenomenal for old code to break at compile time when the environment changes, instead of waiting for a bug report to roll in. So, paging T. Petricek...when are we gonna get it in F#? :) Even better if someone can get it into Rust! That is the perfect type of feature for a systems programming language.

Why is it not working for me: C# = language and tools. Where is my ReSharper/Roslyn for F#? No, I am not going to use a plain text editor like nix guys. No, I am not going to contribute to the open-source F# tools (Microsoft has some spare cash I think). I don't care that "dude, F# compiler is already written in idiomatic F# in 10x less code"! Maybe I am one of those lazy enterprise programmers, but how come do I love immutability, actor model and monads? I'll have my tools today and better language tomorrow with C# than exactly the opposite with F#. PS: check this blog post to learn the full extent of the evangelistic lower-back burn (why, why aren't they coming to our elegant almost-purely-functional language !?): http://tomasp.net/blog/2014/csharp-6-released/index.html

I've got a safaribooks online account, and found "Real World Functional Programming with examples in F# and C#" the most useful of the f# books I've read. The author has a blog, http://tomasp.net/ But I got something out of all of the books.

This looks like a great resource for people new to functional programming. One thing that I wish more F# web sites would look into, though, is using Tomas Petricek's awesome formatting tools [1][2], which give you tooltips for F# code on the web. This makes reading F# code on the web a lot more like reading F# code in an IDE, and makes it much easier to understand what's going on in some examples. [1] Formatting F# code for the web - http://tomasp.net/blog/fswebsnippets-intro.aspx [2] Announcing - Literate programming tools for F#

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;…

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/

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 think it was the first language to specifically introduce the async and await keywords, but it wasn't even the first language on the .NET platform to support the programming model - that honor goes to F#. See https://tomasp.net/academic/papers/async/async.pdf

To be fair, he wrote a spreadsheet engine that could run one particular spreadsheet. Admittedly a complex one, but it was a fixed set of functions that he needed to implement and not and endless tail of things that people expect Excel to do. I think I'd probably have argued more about the UI spec and down some Excel behind the scenes but it is a familiar UI if you've got lots of number inputs all over the place. I've always enjoyed this article about building a spreadsheet in 100 lines of F#: https://tomasp.net/blog/2018/write-your-own-excel/ The expansion from that to the feature set needed here is manageable.

This whole discussion reminds me of http://tomasp.net/blog/2015/failures/ . What I’ve noticed is that programmers are largely divided into camps based on the cost they’re willing to pay to avoid runtime errors: Haskell/Rust developers tend towards one side while Erlang/CL/Clojure tend to the other. My experience is that if you make the edit->run->edit loop tight enough, you can recover a lot of the guarantees available through static checks via a couple of alternate techniques and, for some of us, the resulting workflow is a lot more pleasant way to spend the day than tweaking the code up front until the compiler accepts it.

> A major purpose of DI is that dependencies should be declared in the signature Yes, and a coeffect system would cause dependencies on dynamic variables to be declared statically, even if they're provided by "the environment" at runtime. Tomas Petricek's PhD project page is a good introduction to coeffect systems, and it illustrates dynamic variables as an example. http://tomasp.net/coeffects/

At first I thought the “libraries, not frameworks” mantra* was silly for drawing an arbitrary line in the sand. Over time it’s lined up well with my experiences though. * e.g http://tomasp.net/blog/2015/library-frameworks/

See also literate programming, in which the source code is contained inside some kind of prose and the entire file is a valid program: https://en.wikipedia.org/wiki/Literate_programming It seems that the computational essay is a step higher than ordinary literate programming, as the code is executable in the format being used to present the document. Reading this submission reminded me of this interactive article on coeffects, which fits the description of a computational essay: http://tomasp.net/coeffects/

They have different design goals. Async in F# works better for F# applications. Tomas Petricek wrote a couple good articles [1][2] comparing both approaches to async computations. [1] http://tomasp.net/blog/csharp-fsharp-async-intro.aspx/ [2] http://tomasp.net/blog/csharp-async-gotchas.aspx/

Cool, now go and read this C# horror story: http://tomasp.net/blog/csharp-async-gotchas.aspx/

I didn't find a Vim scheme for you for certain, but take a look at http://tomasp.net/custom/tooltips.css to grab the color values. It does sort of resemble 'koehler' from the color schemes that shipped with my copy of Vim. Certain details are different, but it may be a good one from which to start.

I found Tomas Petricek's essay on "Against a universal definition of 'Type'" very informative. He argues that the word 'type' has shifted shape many times since Frege/Russel, in that the intuition behind them is different. He also argues that multiplicity of definition is a good thing. http://tomasp.net/academic/papers/against-types/

http://tomasp.net/coeffects/ http://www.scottaaronson.com/blog/?p=2741