The docs directory happen to be missing, therefore the links to the quick guide and to "thinking in bonsai" pages from the readme are broken.
Also, I'm wondering how does bonsai-web update the DOM, is it via direct modification of the changed elements, or via some DOM differ? I'd say from direct update from a quick look at the source, but I'm unsure.
I wouldn't use gmap as a benchmark for up to date POIs, at least in some European countries. And I'm not talking about inaccurate opening times; but about places that closed during Covid but are still on the map.
I think it's meant to be parsed as "I liked being able to (express (calling external libraries))", not "I liked being able to (express calling) (external libraries)"
Yes. Probably could’ve written it better but I’ve not poked around F* in a while and I was writing on my phone.
Say you’re calling an external function implementation in hardware, being able to express those interfaces as external makes it viable to use F* vs assuming everything is open source and introspectable.
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.
The Vim I use increases the indent of a code block when I ask it to. Just like it places a closing curly brace at the point where I tell it to. I don't see the fundamental difference between these two things.
But you have to ask it to, and by the right amount for every line/sub-block. If you accidentally get one line wrong, it could be a silent bug. In a language without significant indentation, as long as braces are preserved, once you are done moving code around a single autoformat will fix everything including nested blocks. And if you forget a brace, it's an error instead of a silent bug
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.
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.)
It happens when the indentation is established on the same line as other code, so having a rule that you need a newline to start indentation will avoid the issue. Examples from haskell:
foo x y = do a <- something
pure somethingElse
Renaming `x` to `xxx` would push the indented block in and the subsequent lines would have to be indented too.
Similarly:
foo x y = let a = something
b = anotherThing
in somethingElse
Elm avoids this by requiring an newline after the `do` and `let` (if the `let` has multiple assignments).
Edit: This was brought to my attention by an Idris style guide that said: "Indent so that alpha conversion always works with a simple search and replace. In general this would mean starting a new line when starting a new level of indentation."
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.
Honestly, I wouldn't worry about this. Indentation never got in the way of Python's success. There are plenty other things to worry about besides this.
I just find it funny that the auto formatting adds the spacing to a very specific style, but requiring spacing is too much for some, readability is much richer in most Python projects I've opened (I can't think of one where it was terrible) compared to Java and C# projects I've opened due to people in Python following coding style standards more frequently, PEP-8 is king.
> 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.
And I love that people love indentation based languages so I show them a file with some spurious tabs to see how they feel about indentation causing silent errors.
Sure but even with no code indentation at all, an auto-formatter can easily indent everything for you because of the braces. If you have poorly indented code in a language like Python, you're on the hook for indenting everything yourself. And as a bonus, the code won't even run until you do.
"Bureaucracy" has been an entire field of study for more than a century at that point. But WMF is not bureaucracy any more than the FIFA is bureaucracy. It is curruption; That of the stated ideals of the origin: non profit, decentralisation and democracy.
Technical merit is not correlated to popularity, after all.
reply