Right. This would conflate, e.g., the British and American editions of books published in both countries in the same year; and they are frequently different, as might be different editions of a book published in the same year.
Loreline transpiles to Java, but from the diagram it looks like that only works with Android. Is it possible to use Loreline with Java on other platforms?
I love the Leuchtterm 1917s. They've got everything you say, and they hold up under daily use without falling apart.
As for pens, I use the Uniball Jetstream 0.38 ballpoint--fine point, doesn't skip, and I prefer ballpoints. I used a Coleto Hitec C multi-pen for a while, but the refills are skinny and run out of ink quickly, and I like the feel of the Jetstream ballpoint better. (The refills for the regular Coleto Hitec are much thicker and last a lot longer...but skip horribly. Life is too short.)
I keep notes in Obsidian...but when I'm genuinely studying a text I write out a precis as an outline in my bullet journal, and later transcribe it. That means that I engage with the material at least twice: once when I first read it, and once when I transcribe it. And yes, writing it by hand genuinely does help. And then, when I want to look at it later, my original notes are in my journal, and my transcription is available digitally.
If they wanted to broaden their brand association beyond the legacy product they should have dropped “book” to become Face. A bit of a stranger name than Meta I guess but it’s more historically explainable and doesn’t tie it to any specific new product that could fail.
Face would be an absolutely awful name. Though, interestingly, that's what people in (at least some) Latin American countries (inexplicably) call Facebook.
Why would Face be an awful name? To me it feels similar to “Apple”, which might also sound like a stupid name for a computer company if it wasn’t established already.
In almost forty years of experience, the fraction of developers I've known who read in the field beyond what's strictly needed for their task is very small. I'm always delighted when I find one.
Yes I've been exploring both while writing about the idea. Not sure yet how complex we need the spec. to be in the end - but definitely more to explore on the area
Semantics are where the rubber meets the road, certainly; but syntax determines how readable the code is for someone meeting it the first time.
Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.)
To put it another way, syntax is the notation you use to think. Consider standard math notation. I could define my own idiosyncratic notation for standard algebra and calculus, and there might even be a worthwhile reason for me to do that. But newcomers are going to find it much harder to engage with my work.
> Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.)
For what it's worth, Python has been moving away from this, taking advantage of a new parser that can implement "soft keywords" like 3.10's "match" statement (which I'm pretty sure was the first application).
Believe it or not, the motivation for this is to avoid reverse compatibility breaks. Infamously, making `async` a keyword broke TensorFlow, which was using it as an identifier name in some places (https://stackoverflow.com/questions/51337939).
In my own language design, there's a metaprogramming facility that lets you define new keywords and associated control structures, but all keywords are chosen from a specific reserved "namespace" to avoid conflicts with identifiers.
I don't have any real problem with words that are reserved absolutely and words that are reserved just in particular places. My point was more that in Algol-derived languages control structures look like control structures. And even in languages that implement `map()` and other higher-order functions, you can tell that it's a method/function call and that these things are being passed to it and those other things are not without going and looking up what `map()` does.
I absolutely agree about Haskell (and also OCaml). They both suffer from "word soup" due to their designers incorrectly thinking that removing "unnecessary" punctuation is a good idea, and Haskell especially suffers from "ooo this function could be an operator too!".
> In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like.
All control structures are reserved as keywords in Haskell and they're not extensible from within the language. In C I can't tell that an if(condition) isn't a function call or a macro without searching for additional syntactic cues, or readily knowing that an if is never a function. I generally operate on syntax highlighting, followed by knowing that an if is always a control structure, and never scan around for the following statement terminator or block to disambiguate the two.
I've found in general programmers greatly overestimate the unreadability they experience with the ISWIM family to be an objective property of the grammar. It's really just a matter of unfamiliarity. Firstly, I say this as a programmer who did not get started in the ML family and initially struggled with the languages. The truth of the matter is that they simply engage a different kind of mental posture and have different structural lines you're perceiving, this is generally true of all language families.
Pertinant to that last point and secondly, the sense of "well this is clearly less readable" isn't unique when going from the Algol family to the ISWIM family. The same thing happens in reverse, or across pretty much any language family boundary. For example: Prolog/Horn clauses are one of the least ambiguous syntax families (less so than even S-expressions IMO), and yet we find Elixir is greatly more popular than Erlang, and the most commonly cited preference reason has to deal with the syntax. Many will say that Erlang is unintuitive, confusing, strange, opaque, etc. and that it's hard to read and comprehend. It's just the same unfamiliarity at play. I've never programmed Ruby, I find Elixir to be borderline incomprehensible while Erlang is in the top 3 most readable and writable languages for me because I've spent a lot of time with horn clauses.
I think there's a general belief programmers have where once you learn how to program, you are doing so in a universal sense. Once you've mastered one language, the mental structures you've built up are the platonic forms of programming and computer science. But this is not actually the case. More problematically, it's propped up and reinforced when a programmer jumps between two very similar languages (semantically and/or syntactically) and while they do encounter some friction (learning to deal without garbage collection, list comprehensions, etc), it's actually nothing that fundamentally requires building up an entirely different intuitive model. This exists on a continuum in both semantics and syntax. My Erlang example indicates this, because semantically the language is nothing like Prolog, its differentiation from Elixir is purely syntactic.
There is no real universal intuition you can build up for programming. There is no point at which you've mastered some degree of fundamentals that you would ever be able to cross language family boundaries trivially. I've built up intuition for more formal language families than is possibly reasonable, and yet every time I encounter a new one I still have to pour a new foundation for myself. The only "skill" I've gotten from doing this ad nauseum is knowing at the outset that mastery of J does not mean I'd be able to get comfortable reading complex Forth code.
> There is no real universal intuition you can build up for programming. There is no point at which you've mastered some degree of fundamentals that you would ever be able to cross language family boundaries trivially.
I don't really agree with you on this, even though I agree with everything else here. Then again, I am an outlier where I've used ~40 programming languages in my career. There are a couple of language families (array languages like APL, exotics like BF) where I cannot read it because I've had no real opportunity to learn them, and there's a significant difference in being able to read a language and use a language (I can read, but not really use Haskell -- although I have shipped a couple of patches to small libraries).
I despair at the number of developers in the profession who understand only one or two programming languages…and badly at that.
(It's worth noting that I wholly disagree with the original post. 24 years ago I chose Ruby over Python because of syntax. Ruby appealed to me, Python didn't — purely on syntax. I never pretended that Python was less capable, only that its syntactic choices drove me away from choosing it as a primary language. I'm comfortable programming in Python now, but still prefer using most other languages to Python … although these days that has more to do with package management.)
> its differentiation from Elixir is purely syntactic.
Well, there's also standard library, Erlang one is very messy while Elixir one is very consistent (and pipe operator - `|>` - enforces order of arguments even in low-quality 3rd party code as well, making whole language more pleasant to work with. Same goes for utf8-binary string everywhere and other idiomatic conventions
> All control structures are reserved as keywords in Haskell and they're not extensible from within the language. In C I can't tell that an if(condition) isn't a function call or a macro without searching for additional syntactic cues, or readily knowing that an if is never a function. I generally operate on syntax highlighting, followed by knowing that an if is always a control structure, and never scan around for the following statement terminator or block to disambiguate the two.
Any Haskell function can serve as a control structure in the Algol sense, not so? As for `if(test)` that could indeed be a macro if the programmer’s a durned fool; but absent macros I don’t believe it can be a function call.
Mind you, I take your point about language familiarity; obviously people manage it.
Sounds very cool. I've dabbled with Lisp on and off since the mid-80's, starting with a text adventure in LISP-80 on a Kaypro 4, and though I've never written a serious project in Lisp I've learned a great deal from it. (Wrote a lot of TCL code once upon a time; I've always thought of TCL as a Lisp in which you do a lot of things backwards.)
reply