To borrow your video game analogy. F* is the dwarf fortress of programming languages. Screenshots are only going to confuse anyone who isn't ready to take a significant mental journey.
This is needless fearmongering. F* looks a lot like F# code with semantics you should be familiar with if you've worked with other proof oriented languages. The website design is dated is all. The book gives exactly what the OP wants in the introductory chapter.
Fearmonger is a little heavy handed but the comparison to Dwarf Fortress is probably too strong.
I don't find F* syntax anymore intimidating than Haskell, Scala, Mercury, Prolog, etc. aka the hard languages. I love Ruby and I didn't find it intuitive when I first began learning it (specifically, the block/lambda passing mechanism).
Meanwhile I'm sure there's people out there baffled that anyone finds dwarf fortress challenging to get into.
I'm old enough that I've had the pleasure of handholding software engineers through their first anonymous function usage. Effect system, refinement types, totality checker? The best I get is blank stares before they go back to C# and JavaScript. These days I'm just glad they tolerate linq expressions and typescript.
It matters where you're standing for what feels incomprehensible. But then again, you can say the same thing about dwarf fortress.
I'm the opposite: when landing in a programming language site I want to know the user case the authors had in mind, the memory model, the type system, the compilation targets, the data layout, the control structures, and only at the end just check that the syntax is not indentation based.
Indentation based is a pain when copy-pasting between contexts with different indentation levels, as you have to fix it up manually, which is error-prone. In languages without it, you can just auto-format. (And even in an editor that doesn't support that, having a second indicator makes it less error-prone to fix manually)
But that doesn't work if the indentation carries semantic meaning; you can't change the indentation without changing the meaning. Maybe you can correct syntactically-incorrect spacing (e.g. change 3 spaces to 4 spaces), but not much beyond that.
No indeed I'm not a fan. I find it brittle and arbitrary for data values especially; that also makes automatic code generation and edition harder, for no good reason.
But that's not an important consideration either way.
For what it's worth, I love the semantics of many indentation based languages (F# for example) but really dislike editing them. Visually scanning is much easier with braces (imo) and it's much easier to navigate braced languages when using a vim-like editor
For somebody unable to empathize with the "braces are easier to scan" part, could yiu explain why?
I find it easy to see if things are on the same indentation. I find it much harder to visually scan for opening and closing braces unless syntax highliting makes them scream at me or they are accompanied by ...indentation.
I don't mind indentation based languages. I used to hate them, but they've grown on me after using python, Haskell, Idris, Agda, etc. And I ended up making my own language indentation based (it is similar to Idris).
That said, it is hard-mode:
- You'll have to figure out how to parse it.
- If you want editor support, it's a pain to get tree-sitter to handle it.
- You may not be able to pull off editor operations like "rename" without implementing a pretty printer (a rename might affect indentation).
I think it is helpful for crude error recovery. On parse error, my language will simply skip to the next column 0 token and parse another declaration.
I did not do this (hindsight), but I would recommend arranging the grammar so you only get indented blocks in cases where the previous line ends in a keyword that introduces it. I think python has a trailing `:` every time indentation is introduced, and
Elm does this too - in statements like `let` you need a newline after the `let` to get the multi-declaration version. (This addresses the rename issue.)
and click on the image below the text "You probably want to read it while trying out examples and exercises in your browser by clicking the image below.".
In the section of (1) also the PDF version is linked:
I wonder why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app" that you can just click and it shows the code for how you'd make it in that language.
It matters a lot how the syntax looks IMO and seeing how, say, an API is scaffolded, helps understand a lot about the language in one glance
Edit: Page 18 of the PDF. That's the first time I found what the code looks like, thanks for sharing!
> I wonder why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app" that you can just click and it shows the code for how you'd make it in that language.
Often the reason is that the value that the programming language brings is thinking very differently about how to write code - the examples how to write something in it are merely the "more boring" consequences of this different way of thinking.
--
If you want a programming language that "just" enables you to write something well-understood (in particular in the area of web development) like your suggested
> "HTTP server", "hello world", "todo list app"
in a perhaps just a little bit more elegant/concise way, just look at which web development language/framework is currently fashionable on HN.
I imagine the quick project showcase would be different for Swift or for Rust.
Would be nice to have something like that for this Fstar or any language I haven’t heard of - or maybe have but never looked into so I see why people are using it.
Like what kinds of things i can even think of writing with it - an implementation example
> I imagine the quick project showcase would be different for Swift or for Rust.
> Would be nice to have something like that for this Fstar or any language I haven’t heard of - or maybe have but never looked into so I see why people are using it.
I suggest simply having a look at the table of contents of
This in my opinion gives you a first rough idea for what kind of problems people are using F*.
Spoiler alert: these are not the kind of problems which are related to ["HTTP server", "hello world", "todo list app", ...].
This is exactly the reason why I wrote further above:
> Often the reason [why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app"] is that the value that the programming language brings is thinking very differently about how to write code - the examples how to write something in it are merely the "more boring" consequences of this different way of thinking.
> And ideally - what does a simple solution look like in F-star?
RTFM
Or to explicate on this point: find a section in the table of contents that looks interesting to you, go to the respective section, and look at a code example.
> Set me on the path to installing the thing (ideally above the fold)
The OP doesn't want encompassing, they want the following example from the tutorial on the front page:
type vec (a:Type) : nat -> Type =
| Nil : vec a 0
| Cons : #n:nat -> hd:a -> tl:vec a n -> vec a (n + 1)
let rec append #a #n #m (v1:vec a n) (v2:vec a m)
: vec a (n + m)
= match v1 with
| Nil -> v2
| Cons hd tl -> Cons hd (append tl v2)
This is a completely reasonable thing to want and expect.
personally i think you should just have a separate proof language that doesn't also try to be a programming language and build a bridge between them (ideally as a compilation target). anyways im working on this with my spare opus tokens.
> But it doesn’t lead to confusion when doing mathematics in a theorem prover.
This is demonstrably untrue.
In any case that post is pretty unpersuasive. Basically saying it's too tedious to do it right, in a language whose whole purpose is tediously doing things right!
Probably the better conclusion is that more proof automation is needed for simple things like "this number is not negative" so it is less tedious.
(I'm not a Lean expert but I was totally put off by it happily accept a uint8 with value 300.)
Clicked like 5 pages and never found 1 code example.
Idk why languages don't have their syntax in a sandbox front-and-center on the home page.
It's like a video game site with zero screenshots or videos (also rampant).
New programming languages I want 2 things:
1. What does the syntax look like
2. Why would I use this language
Talk about the proof logic, show the syntax, thank you
To borrow your video game analogy. F* is the dwarf fortress of programming languages. Screenshots are only going to confuse anyone who isn't ready to take a significant mental journey.
This is needless fearmongering. F* looks a lot like F# code with semantics you should be familiar with if you've worked with other proof oriented languages. The website design is dated is all. The book gives exactly what the OP wants in the introductory chapter.
Fearmonger? Me? Well I never.
Also
> if you've worked with other proof oriented languages.
That's doing a lot of heavy lifting.
Fearmonger is a little heavy handed but the comparison to Dwarf Fortress is probably too strong.
I don't find F* syntax anymore intimidating than Haskell, Scala, Mercury, Prolog, etc. aka the hard languages. I love Ruby and I didn't find it intuitive when I first began learning it (specifically, the block/lambda passing mechanism).
Meanwhile I'm sure there's people out there baffled that anyone finds dwarf fortress challenging to get into.
I'm old enough that I've had the pleasure of handholding software engineers through their first anonymous function usage. Effect system, refinement types, totality checker? The best I get is blank stares before they go back to C# and JavaScript. These days I'm just glad they tolerate linq expressions and typescript.
It matters where you're standing for what feels incomprehensible. But then again, you can say the same thing about dwarf fortress.
I'm the opposite: when landing in a programming language site I want to know the user case the authors had in mind, the memory model, the type system, the compilation targets, the data layout, the control structures, and only at the end just check that the syntax is not indentation based.
So I'm very seriously considering making my language indentation based. You're saying you wouldn't like that?
Indentation based is a pain when copy-pasting between contexts with different indentation levels, as you have to fix it up manually, which is error-prone. In languages without it, you can just auto-format. (And even in an editor that doesn't support that, having a second indicator makes it less error-prone to fix manually)
> have to fix it up manually
Any editor written or actively maintained in the current century does this automatically for you. (Yes that obviously includes Emacs and Vim).
But that doesn't work if the indentation carries semantic meaning; you can't change the indentation without changing the meaning. Maybe you can correct syntactically-incorrect spacing (e.g. change 3 spaces to 4 spaces), but not much beyond that.
No indeed I'm not a fan. I find it brittle and arbitrary for data values especially; that also makes automatic code generation and edition harder, for no good reason. But that's not an important consideration either way.
What is code edition?
> What is code edition?
I think rixed means "code editing" (I guess that rixed is simply not a native (L1) or excellent L2 English speaker).
For what it's worth, I love the semantics of many indentation based languages (F# for example) but really dislike editing them. Visually scanning is much easier with braces (imo) and it's much easier to navigate braced languages when using a vim-like editor
For somebody unable to empathize with the "braces are easier to scan" part, could yiu explain why?
I find it easy to see if things are on the same indentation. I find it much harder to visually scan for opening and closing braces unless syntax highliting makes them scream at me or they are accompanied by ...indentation.
I don't mind indentation based languages. I used to hate them, but they've grown on me after using python, Haskell, Idris, Agda, etc. And I ended up making my own language indentation based (it is similar to Idris).
That said, it is hard-mode:
- You'll have to figure out how to parse it.
- If you want editor support, it's a pain to get tree-sitter to handle it.
- You may not be able to pull off editor operations like "rename" without implementing a pretty printer (a rename might affect indentation).
I think it is helpful for crude error recovery. On parse error, my language will simply skip to the next column 0 token and parse another declaration.
I did not do this (hindsight), but I would recommend arranging the grammar so you only get indented blocks in cases where the previous line ends in a keyword that introduces it. I think python has a trailing `:` every time indentation is introduced, and Elm does this too - in statements like `let` you need a newline after the `let` to get the multi-declaration version. (This addresses the rename issue.)
I think this falls under "[wanting] to know the user case the authors had in mind"
There is no "user case", it's called use case.
> There is no "user case", it's called use case.
Perhaps English is not a native language for zlsa?
I love that people hate indentation based so I show them a poorly indented C style languages codebase to see how they feel about indentation.
Isn't it easy to just auto format it?
Use case. Not “user case”.
> Clicked like 5 pages and never found 1 code example.
But I clicked one (1) link to the online book and found a thousand?
Should be on the home page of any programming language site.
Is there actually any difference when it's just one (1) link away? Are most of us seriously this busy that we cannot spend even half a minute on this?
There's a difference, yes. How big it is isn't really relevant question cause its simply an unnecessary tax on visitors.
https://fstar-lang.org/tutorial/
I guess it's a bit popular right now
> https://fstar-lang.org/tutorial/
FYI: The link to this tutorial is unluckily a little bit obscured on the F* website: Go to
> https://fstar-lang.org/index.html#learn (1)
and click on the image below the text "You probably want to read it while trying out examples and exercises in your browser by clicking the image below.".
In the section of (1) also the PDF version is linked:
> https://fstar-lang.org/tutorial/proof-oriented-programming-i...
I still don't see any code examples!
But I do see the editor to try it.
I wonder why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app" that you can just click and it shows the code for how you'd make it in that language.
It matters a lot how the syntax looks IMO and seeing how, say, an API is scaffolded, helps understand a lot about the language in one glance
Edit: Page 18 of the PDF. That's the first time I found what the code looks like, thanks for sharing!
> I wonder why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app" that you can just click and it shows the code for how you'd make it in that language.
Often the reason is that the value that the programming language brings is thinking very differently about how to write code - the examples how to write something in it are merely the "more boring" consequences of this different way of thinking.
--
If you want a programming language that "just" enables you to write something well-understood (in particular in the area of web development) like your suggested
> "HTTP server", "hello world", "todo list app"
in a perhaps just a little bit more elegant/concise way, just look at which web development language/framework is currently fashionable on HN.
> just look at which web framework
See, by listing those, you can tell what it is.
I imagine the quick project showcase would be different for Swift or for Rust.
Would be nice to have something like that for this Fstar or any language I haven’t heard of - or maybe have but never looked into so I see why people are using it.
Like what kinds of things i can even think of writing with it - an implementation example
> I imagine the quick project showcase would be different for Swift or for Rust.
> Would be nice to have something like that for this Fstar or any language I haven’t heard of - or maybe have but never looked into so I see why people are using it.
I suggest simply having a look at the table of contents of
> https://fstar-lang.org/tutorial/proof-oriented-programming-i...
This in my opinion gives you a first rough idea for what kind of problems people are using F*.
Spoiler alert: these are not the kind of problems which are related to ["HTTP server", "hello world", "todo list app", ...].
This is exactly the reason why I wrote further above:
> Often the reason [why more languages don't have a few simple examples of: "HTTP server", "hello world", "todo list app"] is that the value that the programming language brings is thinking very differently about how to write code - the examples how to write something in it are merely the "more boring" consequences of this different way of thinking.
> these are not the kind of problems which are related to ["HTTP server", "hello world", "todo list app", ...].
Ok, what kinds of problems are they?
And ideally - what does a simple solution look like in F-star?
Set me on the path to installing the thing (ideally above the fold)
> Ok, what kinds of problems are they?
> And ideally - what does a simple solution look like in F-star?
RTFM
Or to explicate on this point: find a section in the table of contents that looks interesting to you, go to the respective section, and look at a code example.
> Set me on the path to installing the thing (ideally above the fold)
How to install this thing:
1. Read https://fstar-lang.org/index.html#download
2. Go to the GitHub page linked there: https://github.com/fstarlang/fstar/releases
3. Download F* for an operating system of your choice there.
just click the screenshot
Takes you to an empty editor with still no code examples
That’s because syntax is the least interesting part of F*.
Then why are we all so interested?
Examples provide more than syntax. It's the semantics that we care about most.
> Examples provide more than syntax. It's the semantics that we care about most.
... and this semantics is explained in a quite encompassing way in the introductory notes "Proof-Oriented Programming in F*":
> https://fstar-lang.org/tutorial/proof-oriented-programming-i...
> https://fstar-lang.org/tutorial/
The OP doesn't want encompassing, they want the following example from the tutorial on the front page:
This is a completely reasonable thing to want and expect.I clicked on 2 links on the main page in the Learn F* section...
Thank you ! I just had the absolute same experience and was about to write a similar comment - take my upvote instead !
What? There’s literally a completely interactive book linked right from the home page.
https://fstar-lang.org/tutorial/
I liked being able to express calling external libraries while incrementally migrating existing C codebases to F*. Very solid language.
What do you mean "express calling"? You mean calling the former C versions of the functions not yet ported, while asserting their behavior?
I like Haskell, and to me this seems really useful as a kind of "noob" to functional languages.
Is this used in the industry ? And for what kind of software ?
I found these links in the F* book
https://www.microsoft.com/en-us/research/blog/everparse-hard...
https://lwn.net/Articles/770750/
https://project-everest.github.io/
Looks very very interesting and exciting! Key question: is anyone using it anger and has experience to share?
I guess responsive stylesheets can't be implemented without side effects...
Would this language be useful for implementing compilers and formally proving things about them?
personally i think you should just have a separate proof language that doesn't also try to be a programming language and build a bridge between them (ideally as a compilation target). anyways im working on this with my spare opus tokens.
yes thats the main reason, agda , coq similar ideas
F* seems to be a collection of like five different languages and proof systems. Honestly I never figured it out.
Does it get basic stuff like subtraction and u8 right, unlike Lean?
https://xenaproject.wordpress.com/2020/07/05/division-by-zer...
> But it doesn’t lead to confusion when doing mathematics in a theorem prover.
This is demonstrably untrue.
In any case that post is pretty unpersuasive. Basically saying it's too tedious to do it right, in a language whose whole purpose is tediously doing things right!
Probably the better conclusion is that more proof automation is needed for simple things like "this number is not negative" so it is less tedious.
(I'm not a Lean expert but I was totally put off by it happily accept a uint8 with value 300.)