1.  

    I don’t think the radiology comparison is a great example

    1. 7

      I wonder what this bodes for the future of the VS Code ecosystem. First there was the Python Language Server (Apache 2 licensed), then there was Pyright (MIT) and now there is Pylance which is based on Pyright but closed source.

      1. 4

        To be fair, JetBrains effectively has their own, closed source, “code intelligence” implementations for basically every language. Even when a good language server exists, they don’t use it. Not that I blame them, I’ve personally found the LSP ecosystem to be pretty disappointing.

        1. 6

          To be fair, JetBrains effectively has their own, closed source, “code intelligence” implementations for basically every language.

          Python stuff is open source and Apache 2.0 licensed:

          https://github.com/JetBrains/intellij-community/blob/master/python/python-psi-impl/src/com/jetbrains/python/psi/types/PyTypeChecker.java

          1. 2

            I always found LSPs kinda flaky from a UX perspective. In my experience, editors with intelligence (i.e VS is what I’m familar with, but Eclipse and Emacs count) are more reliable with “knowing” your code.

            1. 3

              this is a good article on the limitations of LSP with respect to IDEs https://perplexinglyemma.blogspot.com/2017/06/language-servers-and-ides.html

              1. 2

                This article makes little sense to me. The distinction between IDE and editor+LSP is arbitrary: LSP is just a mean of having the semantic part of the IDE be detached in a separate process, so that every language can have their own custom one that works for all compatible editors. The complaints about RLS are just that, complaints about a specific LSP implementation (rust-analyzer is much better). A lot of things have also been added to LSP in more recent versions.

                The only thing IDEs have better than LSP on average is that they’re higher quality. But that’s not the protocol’s fault, it’s because the big IDEs are well funded (jetbrains, microsoft) and a lot of LSP servers are from niche communities and developed by people not experienced with the specifics of IDEs. Some good implementations do exist (thinking of ocamllsp here, which is also better than IDEs by virtue of existing at all for the language.)

                1. 2

                  The complaint is that the LSP protocol is limited about how much it can express about the language; the IDE needs more information than the LSP is able to express to it. Hence serious IDEs end up implementing their own handling of the language rather than use LSP. I don’t think it is a matter of funding so much as a limitation of the LSP itself

                  1. 1

                    That’s exactly what I don’t understand. The LSP server is the IDE, and it communicates with an editor responsible for buffer management and actual edition and absolutely none of the semantics. Or do you mean that in the specific context where an existing IDE (like jetbrains’ suite or visual studio) would use an external LSP? In that case I agree that there’s a strong impedance mismatch.

                    1. 2

                      My understanding is that the LSP itself is limited in terms of what functionality it can implement - I have read that it cannot expose the AST. So Jetbrains can do some crazy refactoring and macros because it has direct access to the Java AST, which the Java language server will never be able to do unless they change how the LSP specification works.

                      1. 2

                        I think a LSP server typically will have trouble refactoring a whole project, because it tends to have access only to the files opened in the editor/client (that doesn’t have to be the case, but it’s what the protocol provides). Within a file, LSP can in theory do anything an IDE can, sending a new buffer back to the editor (typically that’d be a “code action”). Syntactic stuff like reindent, but also rename a variable, extract a method, add an import statement, etc. Again the LSP server is the one in charge of the AST; the editor only needs to know about text.

                        1. 4

                          (Replying to the whole thread)

                          LSP is just a particular RPC protocol. The buitin functionality is indeed pretty limited, but it’s easy enough to add extensions in practice. Even built in functionality is OK to do project-wide refactorings, there’s no “only opened files” limitation.

                          The actual limiting factor in practice is editor APIs. There’s a bunch of stuff I can just do in IntelliJ, which I can’t implement in VS Code (custom ui for ruining cargo commands and linkified backtraces are the two most annoying examples).

                          A good example of what is possible if you actually do powerful protocol and powerful front end is rider: https://www.codemag.com/Article/1811091/Building-a-.NET-IDE-with-JetBrains-Rider. They use a different flavor of the protocol, which is based on state synchronization, rather than request-response RPC, but you can (with a whole lot of pain) do something similar on top of an LSP.

                          What is interesting about IntelliJ architecture is that there’s a single engine for many languages, so cross-language features are much easier, and there’s a pinch (but not to much) of code re-use for code analysis for different languages.

                          1.  

                            Thanks for clarifying this for me

                          2. 1

                            Hmm that makes sense, I need to read more about this. If every possible action an IDE could do can be implemented as a code action they seem equivalent.

          1. 1

            How does this compare with Akka?

            1. 2

              very cool pedagogical technique

              1. 6

                I like lisp but macros should be a last resort thing. Is it really needed in those cases, I wonder.

                1. 18

                  I disagree. Macros, if anything, are easier to reason about than functions, because in the vast majority of cases their expansions are deterministic, and in every situation they can be expanded and inspected at compile-time, before any code has run. The vast majority of bugs that I’ve made have been in normal application logic, not my macros - it’s much more difficult to reason about things whose interesting behavior is at run-time than at compile-time.

                  Moreover, most macros are limited to simple tree structure processing, which is far more constrained than all of the things you can get up to in your application code.

                  Can you make difficult-to-understand code with macros? Absolutely. However, the vast majority of Common Lisp code that I see is written by programmers disciplined enough to not do that - when you write good macros, they make code more readable.

                  1. 3

                    “Macros, if anything, are easier to reason about than functions, because in the vast majority of cases their expansions are deterministic, and in every situation they can be expanded and inspected at compile-time, before any code has run. The vast majority of bugs that I’ve made have been in normal application logic”

                    What you’ve just argued for are deterministic, simple functions whose behavior is understandable at compile time. They have the benefits you describe. Such code is common in real-time and safety/security-critical coding. An extra benefit is that static analysis, automated testing, and so on can easily flush bugs out in it. Tools that help optimize performance might also benefit from such code just due to easier analysis.

                    From there, there’s macros. The drawback of macros is they might not be understood instantly like a programmer will understand common, language constructs. If done right (esp names/docs), then this won’t be a problem. Next problem author already notes is that tooling breaks down on them. Although I didn’t prove it out, I hypothesized this process to make them reliable:

                    1. Write the code that the macros would output first on a few variations of inputs. Simple, deterministic functions operating on data. Make sure it has pre/post conditions and invariants. Make sure these pass above QA methods.

                    2. Write the same code operating on code (or trees or whatever) in an environment that allows similar compile-time QA. Port pre/post conditions and invariants to code form. Make sure that passes QA.

                    3. Make final macro that’s a mapping 1-to-1 of that to target language. This step can be eliminated where target language already has excellent QA tooling and macro support. Idk if any do, though.

                    4. Optionally, if the environment supports it, use an optimizing compiler on the macros integrated with the development environment so the code transformations run super-fast during development iterations. This was speculation on my part. I don’t know if any environment implements something like this. This could also be a preprocessing step.

                    The resulting macros using 1-3 should be more reliable than most functions people would’ve used in their place.

                    1. 2

                      What you’ve just argued for are deterministic, simple functions whose behavior is understandable at compile time.

                      In a very local sense, I agree with you - a simple function is easier to understand than a complex function.

                      However, that’s not a very interesting property.

                      A more interesting question/property is “Is a large, complex system made out of small, simpler functions easier to manipulate than one made from larger, more complex functions?”

                      My experience has been that, when I create lots of small, simple functions, the overall accidental complexity of the system increases. Ignoring that accidental complexity for the time being, all problems have some essential complexity to them. If you make smaller, simpler functions, you end up having to make more of them to implement your design in all of its essential complexity - which, in my experience, ends up adding far more accidental complexity due to indirection and abstraction than a smaller number of larger functions.

                      That aside, I think that your process for making macros more reliable is interesting - is it meant to make them more reliable for humans or to integrate tools with them better?

                      1. 1

                        “A more interesting question/property is “Is a large, complex system made out of small, simpler functions easier to manipulate than one made from larger, more complex functions?”

                        I think the question might be what is simple and what is complex? Another is simple for humans or machines? I liked the kinds of abstractions and generative techniques that let a human understand something that produced what was easy for a machine to work with. In general, I think the two often contradict.

                        That leads to your next point where increasing the number of simple functions actually made it more complex for you. That happened in formally-verified systems, too, where simplifications for proof assistants made it ugly for humans. I guess it should be as simple as it can be without causing extra problems. I have no precise measurement of that. Plus, more R&D invested in generative techniques that connect high-level, human-readable representations to machine-analyzable ones. Quick examples to make it clear might be Python vs C’s looping, parallel for in non-parallel language, or per-module choices for memory management (eg GC’s).

                        “is it meant to make them more reliable for humans or to integrate tools with them better?”

                        Just reliable in general: they do precisely what they’re specified to do. From there, humans or tools could use them. Humans will use them as they did before except with precise, behavioral information on them at the interface. Looking at contracts, tools already exist to generate tests or proof conditions from them.

                        Another benefit might be integration with machine learning to spot refactoring opportunities, esp if it’s simple swaps. For example, there’s a library function that does something, a macro that generates an optimized-for-machine version (eg parallelism), and the tool swaps them out based on both function signature and info in specification.

                  2. 7

                    Want to trade longer runtimes for longer compile times? There’s a tool for that. Need to execute a bit of code in the caller’s context, without forcing boilerplate on the developer? There’s a tool for that. Macros are a tool, not a last resort. I’m sure Grammarly’s code is no more of a monstrosity than you’d see at the equivalent Java shop, if the equivalent Java shop existed.

                    1. 9

                      Java shop would be using a bunch of annotations, dependency injection and similar compile time tricks with codegen. So still macros, just much less convenient to write :)

                      1. 1

                        the equivalent Java shop

                        I guess that would be Languagetool. How much of a monstrosity it is is left as an exercise to the reader, mostly because it’s free software and anybody can read it.

                      2. 7

                        This reminds me of when Paul Graham was bragging about how ViaWeb was like 25% macros and other lispers were kind of just looking on in horror trying to imagine what a headache it must be to debug.

                        1. 6

                          The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it’s considered to be bad style to use them when they’re not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can’t easily do in any other language.

                          It’s such a bizarre argument.

                          1. 3

                            I find it persuasive. If a choice is made by someone who knows better, that choice probably has a good justification.

                            1. 11

                              It’s a terrible argument; it jumps from “it’s considered to be bad style to use [macros] when they’re not necessary” straight to “therefore they must have been necessary” without even considering “therefore the code base exhibited bad style” which is far more likely. Typical pg arrogance and misdirection.

                              1. 3

                                I don’t have any insight into whether the macros are necessary; it’s the last statement I take issue with. For example: Haskell has a lot of complicated machinery for working with state and such that doesn’t exist in other languages, but that doesn’t mean those other languages can’t work with state. They just do it differently.

                                Or to pick a more concrete example, the existence of the loop macro and the fact that it’s implemented as a macro doesn’t mean other languages can’t have powerful iteration capabilities.

                                1. 1

                                  One hopes.

                          1. 3

                            Do you think they will ever let wasm access the dom api

                            1. 6

                              The day WASM can access the DOM directly is the day the last line of JavaScript ever will be written. I kid, but also not totally :-)

                              1. 8

                                I don’t see how they’re going to solve the GC problem. If you have DOM manipulation by untrusted code sent over the network, then you really want GC.

                                And once you add GC to WASM it’s basically like the JVM, and that means that it’s better for certain languages than others. It’s already is biased toward certain languages (C and Rust due to lack of GC), but I think it will be even more so with GC. Because GC requires rich types, knowledge of pointers, etc. and right now WASM has a very minimal set of types (i32, i64, f32, f64).

                                1. 4

                                  Could the browser just kill the tab process if it exceeds some memory threshold? I don’t understand why GC is necessary

                                  1. 3

                                    Unfortunately that would limit the browser to roughly content-only pages, in which case you don’t need WASM. Think Google Maps (and pages that embed Google Maps), Protonmail, games, etc. And anything that uses a “SPA” architecture, which is for better or worse increasingly common.

                                    All those are long-lived apps and need GC. GC is a global algorithm, spanning languages. Web browsers use GC for C++ too, when JS (or in theory WASM) hold references to DOM objects: https://trac.webkit.org/wiki/Inspecting%20the%20GC%20heap

                                    1. 1

                                      I see, so the concern isn’t with a rogue WASM app causing bad performance in the other browser tabs, it is about being unable to write the performant WASM app at all without GC?

                                      1. 1

                                        If you didn’t have GC, a browser tab could allocate all the memory on your computer, and many would! The GC is necessary to reclaim memory so it can be used by other tabs / programs.

                                        It’s very common to allocate in a loop. That’s no problem in Python and JavaScript because the GC will pause in the middle of the loop and take care of it. In C, you usually take care to reuse the allocation, which is what makes the code “more detailed”.

                                        I have some first hand experience with this because I wrote a shell which does not deallocate anything. That’s not good enough! :) It may actually be OK for small scripts, but there are long running programs in shell too. You can write a loop that reads every line of a file, etc.

                                        So I’m writing a garbage collector to fix that: http://www.oilshell.org/blog/2021/03/release-0.8.8.html#the-garbage-collector-works-on-a-variety-of-examples

                                        Right now the practice for WASM is to either write in C or Rust and manually deallocate – or ship a GC over the network with the program, which isn’t ideal for a number of reasons.

                                        1. 3

                                          But you can easily consume all the memory anyway just by making an array and continually growing it, or a linked list, or whatever. So what’s the difference?

                                          Like, wouldn’t it be enough for the WASM code to have some way of telling the browser’s GC its refcount for each object it’s holding on to so it doesn’t get GCed out from under it?

                                          1. 1

                                            That’s done with weak refs for guest objects owned by js objecs, but there’s nothing to handle the other direction afaik.

                                    2. 3

                                      I have noticed recent versions of Safari (at least on arm64) do this. First you get a little warning underneath the tab bar saying “This tab is using significant amounts of memory — closing it may improve responsiveness” (paraphrased). It doesn’t actually go ahead and kill it for you for quite some time, but I’ve noticed that e.g. on putting the computer to sleep and waking it up again, a tab so-marked gets reloaded. It is a little annoying, but it doesn’t come up very often to begin with.

                                    3. 2

                                      Agreed, it’s a tricky thing, particularly given how including a GC or other runtime niceties in compiled code bloats the downloaded asset for each site. So I also can’t imagine that they intend to do nothing.

                                      1. 5

                                        Yeah I haven’t been following closely, but it seems like the WASM GC+types enhancements are bigger than all of WASM itself to date. (e.g. there are at least 2 WASM complete interpreters that are all of 3K lines of C code; that would no longer be possible)

                                        It’s possible to do, but it’s not a foregone conclusion that it will happen, or be good!

                                        I’d also say that manipulating the DOM is inherently dynamic, at least with the way that web apps are architected today. I say that because (1) DOM elements are often generated dynamically and (2) the values are almost all strings (attributes like IDs and classes, elements, contents of elements, CSS selectors, etc.).

                                        Writing that kind of code in a statically typed language is not likely to make it any better or safer. You’d probably want something other than the DOM in a more static language. I’d also go as far as to say that JS is better than most dynamic languages at these kinds of tasks, simply because it was designed for it and has libraries/DSLs for it. Python or Lua in the browser sounds good until you actually try to rewrite the code …

                                      2. 1

                                        Why can’t GC be optional? “You can turn on the GC, but then you have to comply with this additional set of requirements about using rich types, informing the GC of pointers, etc.”

                                        Edit: this actually seems like it must work since it is essentially the existing “ship a GC over the network” solution, except the you don’t have to actually pay the bandwidth to ship it over the network because it’s already in the browser. Unless I’m missing something, which I definitely could be!

                                        1. 1

                                          Here’s an idea:

                                          • you can hold references to DOM nodes. Accessing properties requires going through accessor functions that null-coalesce basically

                                          • if you just have a reference, it can get GC’d out from under you (accessors will guard from the dereference tho)

                                          • however, the reference can be reference counted. You can increment the reference count, decrement it (see the Python FFI). You can of course memory leak like this. But making it optional means you can also try and be clever.

                                          • no handling of cyclical issues. You wanna memory leak? Go for it. Otherwise implement GC youself

                                          Reference counted GC doesn’t involve stop the world stuff, and since you likely won’t be linking DOM elements together cycles would be much rarer.

                                          1. 1

                                            WASM already has a feature called “reference types”, which allows WASM programs to contain garbage collected references to DOM objects. Chrome and Firefox added support for this feature last summer. I don’t know all the details, but you can google it.

                                        2. 2

                                          I thought you could already do this. What about this package https://github.com/koute/stdweb for accessing the DOM using Rust that is compiled to WASM?

                                          1. 3

                                            That basically bridges to JS to do the actual DOM manipulation. I don’t remember the exact details.

                                        3. 2

                                          Misread this as “the doom API”

                                          …I’m fairly sure doom has been ported to wasm, anyhow

                                          1. 1

                                            I mean, you already can? You just have to add the bindings yourself. But that makes sense because not every wasm blob will want the same access or in the same way…

                                          1. 18

                                            A lot of this boils down to the same economic motivation for any kind of outsourcing: if something is not your core competency and is not part of your competitive advantage then you can reduce costs by sharing the fixed overheads with other companies in your market. This is especially true for zero-marginal-cost goods such as software where the only costs are the fixed overheads. The cost of developing a program that has a single user is the same as the cost of developing a program that has a million identical users. For something like a game engine, where the users aren’t identical and have some different requirements, there are some incremental costs, but they’re far lower than the cost of developing the core technology.

                                            This composes with the other broad trend towards complexity in the tech industry. The game engine for Wolfenstein 3D was developed by a couple of people. The team that developed the Quake engine was (I think) about half a dozen people. A modern game engine is many hundreds of person years of development work. Id probably recouped the cost of developing the Quake engine with Quake itself, any other licensing royalties were free money on top. A fairly successful modern game like The Witcher 3, for example, almost certainly didn’t make enough money to fund the development of an in-house game engine and so companies that don’t make the decision to outsource either make massively profitable games or go out of business.

                                            I think it’s going to be interesting to see how things like Godot change the economics here, because it may well be cheaper to pay a couple of in-house developers to add features to an open source game engine (and upstream them, if you don’t want to pay the cost of maintaining a fork) than to pay for an Unreal license. Unreal is trying quite hard to counter this with a pricing model that is very cheap for small studios, which then get locked in (and even when they’re paying more, it’s not a large fraction of their revenue).

                                            1. 3

                                              I thought CD Projekt Red made their own engine

                                              1. 2

                                                They did, but according to Wikipedia it was first used for The Witcher 2, which was released in 2011, which means they probably started engine development back in 2005ish (you hear “it takes 5+ years to make a game engine” a whole lot on e.g. /r/gamedev). They also used a ton of middleware.

                                                https://en.wikipedia.org/wiki/CD_Projekt#REDengine

                                                1. 2

                                                  I worked at the game studio which developed Snowdrop- I can confirm that it’s about 5-7 years for an engine.

                                              2. 2

                                                See, this is the thing. Quake was only 3 programmers, Quake 2 3 programmers, Build engine was one guy (with 1 additional programmer credites on Duke 3D)…and Witcher 3 was an in-house engine.

                                                Modern game engines as easier than you think.

                                                The tricky part is when you want to get into tooling and things to support your artists and designers.

                                                1. 5

                                                  See, this is the thing. Quake was only 3 programmers, Quake 2 3 programmers, Build engine was one guy (with 1 additional programmer credites on Duke 3D)…and Witcher 3 was an in-house engine.

                                                  Modern game engines as easier than you think.

                                                  I’m not sure how that supports your thesis, considering all but The Witcher 3 are games from the 90’s, and id’s games were mostly tech demos post-Doom.

                                                  1. 3

                                                    The Witness is a custom engine, Source and Source 2 were custom engines, Unreal itself was originally a custom engine, Minecraft was a custom engine, Payday and Payday 2 were custom engines…like, it’s a whole thing.

                                                    1. 2

                                                      Witness is a small-scale project, less time pressure.

                                                      Source 2 is derived from Source which is derived from GoldSrc which is derived from Quake. They didn’t start from scratch.

                                                      Minecraft is a bit of an outlier; again, single person, but it’s something you couldn’t really do with Unreal. (But it’s also Java and notorious for its technical flaws, so….)

                                                      I believe Payday’s engine was used for other games by the studio/publisher, which amortized costs.

                                                2. 1

                                                  Godot is likely to fail every time you want to target a console platform :( Or do they have support for any of that yet?

                                                  1.  

                                                    It has been able to target the Xbox for a while. That’s the only console I own, so I haven’t paid attention to whether it can support anything else.

                                                1. 3

                                                  90% of the time is spent in reading code. Maybe we need to optimize for that instead. The indentation syntax chosen by lispers make it difficult to see scope and the 2 space indentation makes me want to stab my eyes. I like the kebab-case though. Long back I tried messing with begin / end instead of parens and found the resultant code much better and ruby-like.

                                                  Lisp sorely needs a coffeescript, an external DSL as opposed to internal macros along with the appropriate tooling. JavaScript is really pragmatic in this regard. Why do lisp programmers hate lexers and parsers ? Until that happens Lisp will never be a real alternative to anything - again, 90% of time is spend in reading code. I have always had a soft-spot for dylan.

                                                  1. 7

                                                    The indentation syntax chosen by lispers make it difficult to see scope and the 2 space indentation makes me want to stab my eyes.

                                                    I feel the same way reading Java. This has everything to do with familiarity and basically nothing to do with any inherent superiority in either style.

                                                    Lisp sorely needs a coffeescript

                                                    These kinds of dialects get created on a regular basis. It’s honestly very predictable if you follow a lisp mailing list. In the end no one uses them because the advantages are not very compelling; they only seem that way to people who haven’t spent much time using lisp.

                                                    1. 1

                                                      In Lisp parens are overloaded to represent

                                                      1. Assignment
                                                      2. Block Scope
                                                      3. Expressions / Statements
                                                      4. Function calls
                                                      5. Function body
                                                      6. Macro body
                                                      7. Data structures

                                                      When looking at a piece of Lisp code how quickly can you tell each of the above apart ?

                                                      Lispers can adopt this style for better representing block scope

                                                      (let [x 5]
                                                          (if x
                                                              (do
                                                                  (print y)
                                                                  (+ x y)
                                                              ) ; end-do
                                                          ) ; end-if
                                                      ) ; end-let
                                                      

                                                      One use of Lisp’s regular parens, it actually makes the code easier to read because you don’t have to remember all the syntax. What I object to is the paren placement. where cuddling them together makes the scope not clearly visible. Can I use 8 spaced indentation in Lisp without the entire lisp community complaining ? I don’t think so.

                                                      Let us look at how absurd the situation is. Because of the paren syntax - people are using XML, python and compiling JavaScript to a lisp like vm bytecode to avoid Lisp. One advantage of XML is the use appropriate beginning and ending tags. which makes it easy to tell things apart. I would bet you that if you take into account the reading time / comprehensibility time as opposed to lines of code in a large piece of code - Python/XML/C-like syntax would win.

                                                      1. 4

                                                        Your list of seven things includes a lot of duplicates. #1, #2, and #5 are just special cases of #6. It’s unclear what #3 “Expressions/statements” means since statements do not exist in lisps. It’s true that for #7 older lisps (CL, Scheme, and Emacs) certainly do have this problem of using parens for too many things, but newer lisps use other types of brackets. In Java, parens are used for two things: calling methods, and grouping operands in math expressions. So it’s not as if overloading the meaning of delimiters is somehow unique to lisps.

                                                        You say that it’s difficult to read, and I say that it’s easy to read once you have experience. One of us has experience, and one of us doesn’t. Not really sure where else the argument can go from there.

                                                        1. 1

                                                          #1, #2, #3, #5 are not special cases of #6 in terms of side-effects they cause.

                                                          1. 1

                                                            FWIW, I believe that define in Racket could be considered a statement since it raises a syntax error if used in an expression position.

                                                          2. 2

                                                            When looking at a piece of Lisp code how quickly can you tell each of the above apart ?

                                                            About as quickly as I can scan it, honestly. The keywords like if, let, and do are more significant in understanding it, but I take your meaning that finding the the close paren can be hard. I have seen Clojure beginners mess up their code by placing the close paren incorrectly. Most good editors have matching paren highlighting to make this easier.

                                                            BTW, an experienced Clojure programmer would code this up more tersely, something like:

                                                            (when-let [x 5]
                                                              (print y)
                                                              (+ x y))
                                                            
                                                            1. 1

                                                              The keywords like if, let, and do are more significant in understanding it,

                                                              Yes thats what I mean. If I look at a blob of any non-lisp code … I can immediately say where the conditionals, loops and function calls are. For lisp I have to go through each line to get the idea.

                                                               // If C programmers wrote like lisp
                                                               for (i = 0; i < 10; i++) {
                                                                   if (i % 2 == 0) {
                                                                       doSomething (i); }
                                                                   else {
                                                                       doSomethingElse (i); } }
                                                              
                                                              

                                                              You can’t add new statements without messing up “{” and “}”. The same happens in lisp if I want to add more statements in cond blocks. Lisp also forces programmers to not use standard control flow and favors recursion all times, all these hinder readability.

                                                              1. 4

                                                                To me this reads like a combination of a lack of literacy in the language (although in Clojure for is a loop keyword and if is a conditional—just like in C) and a mindset favoring imperative programs (based on your use of the term “statement.”) To be clear, I don’t think imperative is a “wrong way” of thinking but it will be an impedance to effectively using a Lisp language where all syntactic forms—including loops and conditionals—are expressions that have some value when executed.

                                                                I’m unsure what you mean by standard control flow but I rarely find myself writing recursive programs on finite data in Clojure or any other language. I agree with you that a recursive program is probably harder to understand vs the the equivalent iterative program in many instances.

                                                            2. 1

                                                              This is also a point where I find C-style syntax lacking. Other languages have for/next, do/od, if/fi or if/endif where the ending bracket must match the beginning bracket. In C, Java, Go, you often just find yourself at a big stack of {{{{.

                                                          3. 5

                                                            Lisp sorely needs a coffeescript, an external DSL

                                                            That wouldn’t be a DSL as it wouldn’t have anything domain specific about it. Quite the opposite.

                                                            Alternative syntaxes do exist and are used by a few. The general consensus over the 50 year old discussion about them, is that the vast majority of lispers do perfectly fine without them.

                                                            I’d say that, as any other language, it rather need practical selling points and marketing by some invested company, rather than theoretical/technical merits.

                                                            1. 4

                                                              The whole point of using Lisp instead of some other modern high level language is that it supports macros and is homoiconic, so you can write macros in Lisp itself instead of in a different macro language. If you get rid of this, why not just use Ruby? I’m not as familiar with Dylan - how easy is it to write macros there vs. in a more traditional lisp?

                                                              1. 3

                                                                90% of the time is spent in reading code. Maybe we need to optimize for that instead. The indentation syntax chosen by lispers make it difficult to see scope and the 2 space indentation makes me want to stab my eyes. I like the kebab-case though. Long back I tried messing with begin / end instead of parens and found the resultant code much better and ruby-like.

                                                                IME reading more code and becoming more familiar with the style makes different formats easier to read. In any case, there’s no requirement that Lisp use 2 spaces.

                                                                Personally, I use the default Emacs indentation for everything, and don’t have any problems reading Lisp, C++, Javascript, Python, or any of the other languages I have to use.

                                                                Lisp sorely needs a coffeescript, an external DSL as opposed to internal macros along with the appropriate tooling. JavaScript is really pragmatic in this regard. Why do lisp programmers hate lexers and parsers ? Until that happens Lisp will never be a real alternative to anything - again, 90% of time is spend in reading code. I have always had a soft-spot for dylan.

                                                                To be blunt, I suspect JavaScript programmers are quick to use non-Javascript whenever they can because Javascript is unpleasant to work with.

                                                                As far as why Lisp programmers prefer using macros and DSLs, it’s mainly because it’s so convenient to use one language and set of tooling for everything. Why complicate things with five different tools when one can do the job equally well? And it means anybody who knows the language can jump to the source code and see what’s going on.

                                                                As you said, reading code is the important thing, so why not spend your time reading and understanding one language instead of a bunch?

                                                                1. 1

                                                                  It’s also worth pointing out that by far, the most commonly-used “Javascript+” language is Typescript… which is just Javascript with types. Same syntax.

                                                                2. 1

                                                                  I was going to mention Dylan here until I saw your ending paragraph.

                                                                  1. 1

                                                                    90% of the time is spent in reading code. Maybe we need to optimize for that instead … The indentation syntax chosen by lispers make it difficult to see scope

                                                                    I agree about the importance of optimizing for readability. I’m not sure exactly what you mean re: “indentation syntax”, but one of the things I absolutely love about programming in Racket (a lisp) is how lexical scope is handled with parenthetical blocks, and how easy it is to move lexically scoped blocks around in the editor.

                                                                    Readability is very subjective, so I’m not trying to invalidate your view of lisp readability, but having scope neatly contained in the structure of the code is a very nice feature for me.

                                                                  1. 2

                                                                    What are the biggest draws to use Kotlin instead of Java in 2021, from a feature perspective?

                                                                    1. 3

                                                                      The biggest two things that will (likely) never come to Java are nullability baked into the type system and extension methods. There are a lot of smaller things that are nice, like operator overloading, multiplatform support, lambda shorthand syntax, etc. that are nice as well. With the rate of recent progress in Java, given the choice I’m honestly not sure which I’d pick for a greenfield server project.

                                                                      1. 1

                                                                        Less boilerplate.

                                                                      1. 22

                                                                        i think the most effective thing linux laptop producers could do to increase adoption is to improve the touchpad drivers and make it as nice an experience as Mac. As a non power user of the Mac specific software this was the biggest downside of other laptops I have tried.

                                                                        1. 5

                                                                          I second this, I use a Mac at work and an xps13 otherwise and this frustrates me so much.

                                                                          The second point is wifi and Bluetooth stability that is completely unreliable compared to macOS…

                                                                          1. -2

                                                                            You use a touchpad when you’re at work?

                                                                            1. 12

                                                                              questions like this make me not want to participate in this website.

                                                                              1. 3

                                                                                I use a Magic Trackpad on my stationary computer. It’s better for everything except precision pixel painting, especially for your body.

                                                                                1. 3

                                                                                  Not the parent poster, but yes. I do a modest percentage of my work using a laptop as a laptop.

                                                                                  In pre-pandemic times, I had frequent in person meetings. In pandemic times, I sometimes have to be where I can see/hear the kids.

                                                                                  With a Mac, I just use the trackpad. It’s not something I’d do 8 hours a day, but I have zero problems using it when I’m mobile. On linux, I either schlep around a mouse, which is inconvenient, or use the trackpad, which is also frustrating.

                                                                                  1. 2

                                                                                    Many prefer to cyble between multiple mouse inputs to combat carpal tunnel and other strain related injuries. I much prefer a touch pad myself.

                                                                              1. 5

                                                                                I didn’t think anyone use Arc besides Paul Graham

                                                                                1. 2

                                                                                  my day job is writing python developer tools, and i found this article really inspiring. in particular i would love to explore the ideas behind reflexion models more - has anyone done related work in a dynamic language like python?

                                                                                  1. 2

                                                                                    It seems more difficult to do in a dynamically typed language or a statically typed language with access to something like Java reflection because you don’t have all of the class information before runtime.

                                                                                    1. 2

                                                                                      i have already written a tool that uses type information inferred by pytype to index and cross reference code, so i’m optimistic that that can be extended to reflexion models once i understand more about the latter.

                                                                                      1. 2

                                                                                        I just mean that you will never get full coverage due to things like eval and exec.

                                                                                        1. 2

                                                                                          ah, right you are. yeah, that might be insurmountable for the general problem, but most code doesn’t use those constructs so there is still value in static analysis tools for “well-behaved” python code.

                                                                                      2. 2

                                                                                        Doop does pretty well with reflection. http://yanniss.github.io/reflection-aplas15.pdf

                                                                                    1. 27

                                                                                      I always suggest Go. If this is a project that will be “complete” soon, then you have good chances to release your code after years, compiled with newer versions of Go, without the need to rewrite it. (If you used standard library packages.)

                                                                                      Unfortunately, writing CRUD in Go can be tedious because there are no generics, but this is fine. Later, when you realize that your abstractions where wrong, you will thank Go for the lack of generics anyway.

                                                                                      1. 5

                                                                                        If this is a project that will be “complete” soon, then you have good chances to release your code after years, compiled with newer versions of Go, without the need to rewrite it. (If you used standard library packages.)

                                                                                        I’m sure this is more true today, but when I wrote a few Go projects several years ago, it sucked trying to compile them again on a new machine because the dependencies were all screwed up. I can’t believe Go went so long without good dependency management. Well, I guess I shouldn’t be surprised because there’s Python…

                                                                                        In any case, Go-the-language was pleasant to work with. I hope the recent work on dependency management has made it much smoother to actually compile an older project.

                                                                                        1. 2

                                                                                          Funny, I haven’t felt the pain of no generics when writing Go CRUD apps, but rather I’ve felt the pain of writing out a bunch of SQL queries and getting a nice “get all” endpoint for each object with filtering. I know ORMs are a thing, but I feel like they’re (almost) an anti-pattern in Go - at the very least I never see them recommended.

                                                                                          1. 2

                                                                                            sqlc is pretty great https://github.com/kyleconroy/sqlc

                                                                                          2. 2

                                                                                            JVM backwards compatibility is great too.

                                                                                          1. 1

                                                                                            Has anyone here used Akka? Curious about the Erlang concurrency model running on other VMs.

                                                                                            1. 2

                                                                                              What is stopping the US or China from doing a 51% attack on network, not to steal coins but to put doubt in the system and discourage people from using it? They could easily pay for enough liquid compute to do it.

                                                                                              1. 2

                                                                                                Only desire. The US has seized Bitcoin successfully - such that they could do transaction volume attacks - but there’s a lack of desire to destroy bitcoin.

                                                                                                I put this down to a lack of honest desire to truly quash money laundering. Bitcoin isn’t the biggest vector, but it’s one expression of a lack of real policy commitment in this area.

                                                                                              1. 5

                                                                                                Aren’t interviews fundamentally about putting a person on the spot? And by all means I agree that it’s not ideal, but joining a new work environment is precisely that. I don’t see why the discussion is centered on the “why would you ask me to reverse a binary tree” type problems.

                                                                                                Applicants that can do well under pressure and/or have time and energy to prepare well to answer questions about obscure algorithms will likely continue to do so. On a large enough scale, a firm can exploit this to drastically cut out false positives.

                                                                                                This is indeed inefficient, but more so in the economic sense. Applicants will spend hours of productive work preparing for their expectations of what will be asked. Secondly, it risks excluding individuals on the basis of their material conditions; who in our society does better under pressure (definitely not oppresed minorities), who can afford to “grind Leetcode” for months prior to the interview?

                                                                                                1. 26

                                                                                                  Aren’t interviews fundamentally about putting a person on the spot?

                                                                                                  Interviews are fundamentally about learning more about the candidate (and giving the candidate an opportunity to learn more about the company and team).

                                                                                                  Putting them on the spot is not the point, unless it’s a specific type of interview for a very high-stress, split-second industry like EMT or air traffic controller. Software developers don’t code “on the spot”, unless the company culture is pathological. Instead, they code in ways sustainable in the long term, or during a crunch. Even in the latter, they’re not expected to solve data structure puzzles within the hour or lose their employment.

                                                                                                  The goal of an interview is to determine how well a candidate will do in a given role. The more we make interviews about “putting a person on the spot” instead, the more we make the company culture about firefighting and crunch.

                                                                                                  1. 5

                                                                                                    If you are a company that has oncall and need engineers to be able to fix something in an emergency, then testing for ability under pressure is not a bad thing. In that case maybe the test should be for under pressure debugging instead of memorizing algos, though.

                                                                                                    1. 7

                                                                                                      I don’t think you can set an artificial fire and put it out with any meaningful output - every company has unique practices, tooling, playbooks, etc.

                                                                                                      When I’ve sat in on SRE/ops interviews I’ve seen good outcomes from describing a hypothetical environment - web server and DB, your web server is throwing a 503 error - and walking through the troubleshooting steps. It can be relatively low pressure, but I’ve seen good signals: experienced ops people talk about remaining calm, surveying the landscape with familiar tools (ping, dig, etc), and build up a very quick mental model of the problem.

                                                                                                  2. 16

                                                                                                    I won’t join companies that think day to day programming work should be a high-stress environment. Especially not the ones that do it on purpose to maximize exploitation of their work force.

                                                                                                  1. 4

                                                                                                    This took out the puzzle server on Lichess

                                                                                                    1. 2

                                                                                                      Perhaps, Mozilla Hubs? https://github.com/mozilla/hubs

                                                                                                      1. 3

                                                                                                        This is a VR app - are there any of the features there that OP asked about?

                                                                                                        1. 1
                                                                                                      1. 7

                                                                                                        I haven’t seen very many good arguments against what Moxie has said with regards to competing on features. Comparing this with countries - even in a representative democracy like the United States, our military is a strict hierarchy. This is despite the democratic principles of the country. The reason? There is an evolutionary pressure on militaries to find the most competitive structure - those who have tried other things (as Orwell talks about in revolutionary Catalonia) failed in part due to the structure they adopted. Moxie has noticed the loss of open source projects to these closed companies due to their insistence on a more virtuous structure and has decided that the perfect is the enemy of the good. To me this seems analogous to the arguments between pure utopian anarchists and more pragmatic people (considering Moxie’s political orientation he is probably intimately aware about the tradeoffs here).

                                                                                                        1. 7

                                                                                                          Since reading Moxie’s polemic against federation (I assume you’re talking about the “Ecosystem is Moving” essay, though Moxie has repeated the idea elsewhere), I’ve slowly come to the understanding that the only way to win this competition on features is to not play at all. After all, there’s almost always someone out there with more money/determination than you, which I guess is especially true in terms of open/community-owned projects vs. more commercial endeavors.

                                                                                                          Part of what I’ve come to dislike about these more boxed platforms (to borrow a term from the linked article) is how they’ve made online discussions more ephemeral, both in terms of owning one’s archive, and in terms of being able to stay part of a community regardless of which device/system I happen to be participating from. For most of these platforms, clients running on “legacy” systems (be it older devices or devices on non-mainstream operating systems) are routinely dropped or not developed for in the first place; some platforms place constraints on participating over multiple/alternative devices, such as a mobile device and a desktop device (ostensibly because of E2EE concerns).

                                                                                                          This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.

                                                                                                          Conversely, platforms such as IRC and XMPP continue to be useful even on ancient or under-powered devices, albeit in a perhaps degraded capacity, and allow for the sort of mixing-and-matching of use-cases made harder by their boxed counterparts. This, to me, is a more user-friendly and inclusive approach to building communication tools; unfortunately, being more inclusive means taking the foot off the pedal, or at least taking a more mindful approach in rolling out features.

                                                                                                          1. 9

                                                                                                            This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.

                                                                                                            Communication (like most human endeavors) is constantly changing. Language changes, communication methods change, speakers change (including marginalized groups into conversations), and expectations around media change. This isn’t “progress” in the Baconian sense but it is change. IRC and XMPP (along with their technical issues which others in this thread have covered in great detail) just hasn’t been able to keep up with changing expectations of communication. Realistically, the general population sends pictures of computer monitors to their friends over Snapchat. Sticking to IRC just codifies a different set of social norms into place.

                                                                                                            1. 5

                                                                                                              Disagree.

                                                                                                              Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.

                                                                                                              Featuritis causes these changes more often than change causes featuritis. Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.

                                                                                                              1. 10

                                                                                                                Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.

                                                                                                                You’re taking too short of a view of this. Humanity used to send smoke signals and use oral storytelling to communicate. In the meantime, we seem to have invented writing, paper, printing presses, newspapers, telegraphs, radios, and all sorts of other manners of communication. Whenever I see folks say things like change is driven by featuritis, I invite folks to tell me where they draw the line between essential change and featuritis change and to justify why this line is valid.

                                                                                                                Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.

                                                                                                                Right but what about folks that are hard of sight? Folks that are dyslexic? People that comprehend things through image better than text? Traditionally these folks have been excluded from the conversation. In fact, the history of communication has largely followed the democratization of communication to new actors. Why is plaintext encodable written language the point at which we must draw our line in the sand?

                                                                                                                EDIT: I also want to point out that there are people that enjoy change. They enjoy learning new slang, they love participating in new memes, trends, conversations, and ideas. This isn’t to say that new is inherently better, but nor is it to say that new is inherently worse. But there is a contingent of people out there that legitimately enjoy change. If you want to include folks in the conversation (which is the whole point of creating open communication platforms, right, to enable humanity to communicate), you need to account for folks that will change their colored contacts on a whim as much as the person who is fine using their 20 year old laptop to view plain text.

                                                                                                                1. 1

                                                                                                                  Right but what about folks that are hard of sight? Folks that are dyslexic?

                                                                                                                  Dictation does not require creating a new protocol; that’s a client-side feature.

                                                                                                                  Why is plaintext encodable written language the point at which we must draw our line in the sand?

                                                                                                                  Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.

                                                                                                                  there are people that enjoy change

                                                                                                                  Client-side change is fine as long as that change doesn’t devolve into a boxed platform. Nobody’s stopping you from switching out themes or clients when you feel like it.

                                                                                                                  1. 10

                                                                                                                    Dictation does not require creating a new protocol; that’s a client-side feature.

                                                                                                                    What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity? What about folks that are blind and deaf, or who don’t know a certain language?

                                                                                                                    Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.

                                                                                                                    Citation needed. We communicated without written language for a very long time. Why do we need to use written language now? How is it the minimum of anything? We don’t even have a universal theory of human semantic processing, so how can we prove that written communication is the minimum?

                                                                                                                    But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer? Why is the implementer more important than the user? Why is an open protocol more important than the act of communication itself? When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.

                                                                                                                    This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality. If you want to communicate with your fellow FOSS-natives on Freenode and grumble about the kids on TikTok be my guest, but others will not be willing to make that choice. If FOSS actually wants to enable end users and not technical FOSS-natives, then FOSS needs to prioritize users just as much if not more than its principles. In the meantime, others will explore other tradeoffs. Like Moxie with Signal, Element with Matrix, and Gragon with Mastodon. I can tell you that IRC hasn’t changed much and FreeNode hasn’t gone anywhere in the last several decades, yet the mindshare has very much moved away from FreeNode, and that’s because users have put their “money” (or time or effort or whatever) where their mouth is and have voted with their feet.

                                                                                                                    For me a good metric of success with a communication protocol/product will be when you observe average teenagers in the developed and developing world organically using your product to communicate. They use things like Instagram and WhatsApp but they probably don’t use IRC. I did use IRC when I was a teenager, but there were fewer options then and IRC mirrored the cultural context of online communications at the time much more than IRC does now. I think you’d be hardpressed to get any teenager these days to use IRC.

                                                                                                                    1. 3

                                                                                                                      What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity?

                                                                                                                      Use the right tool for the job. A VOIP protocol would work well for sending voice. You could make a meta-client that combines a VOIP client and an instant-messaging client if you want to do both at the same time. There are better ways to do this than making the protocol more complex.

                                                                                                                      What about folks that are blind and deaf, or who don’t know a certain language…why do we need to use written language now?

                                                                                                                      People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.

                                                                                                                      But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer?

                                                                                                                      Yes. I explained my rationale for simplicity in the previous post, Whatsapp and the domestication of users. When complexity grows past a certain point, implementers need to spend more working-hours and need more funds to create a viable implementation; requiring too much funding can encourage dark patterns and conflicts of interests (e.g., investor money). I’d recommend checking out the article if you’re interested in this topic.

                                                                                                                      Why is an open protocol more important than the act of communication itself?

                                                                                                                      Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.

                                                                                                                      When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.

                                                                                                                      Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.

                                                                                                                      This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality.

                                                                                                                      Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used).

                                                                                                                      In the meantime, others will explore other tradeoffs. Like Moxie with Signal

                                                                                                                      I’ve explained why I find Signal problematic in the previous post. I don’t think one org should own a communication platform.

                                                                                                                      I think you’d be hardpressed to get any teenager these days to use IRC.

                                                                                                                      I was a teen on IRC until last year when I turned 20. There are dozens of us!

                                                                                                                      Also, a quote from this article:

                                                                                                                      I’m not arguing that average users are doing something “wrong” by doing otherwise; expecting average users to change their behavior for the greater good is naive. This advice is targeted at the subset of users technical and willing enough to put some thought into the platforms they choose, and indirectly targeted towards the people they can influence.

                                                                                                                      I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.

                                                                                                                      1. 4

                                                                                                                        People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.

                                                                                                                        Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about. If anything, that sounds like prioritizing the freedom of the able over the freedom of anyone else.

                                                                                                                        Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.

                                                                                                                        For me communication is not worth gimping for the sake of being minimal or implementation-friendly. I am fine accepting complexity in client, protocol, and server to enable users to communicate in novel, ergonomic ways. Communication is much more important to me than implementer ease. I’ll go further and say, given a choice between implementer ease and rich communication, almost everyone would pick rich communication. Only a minority will be so motivated by the spectre of lock-in that they will reject attempts to broaden the platform.

                                                                                                                        Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.

                                                                                                                        This is part of your personal “house spec” of course. I think you’re going to have a really hard time finding everyone agree on a “house spec”, and in practice you see folks with very different types of living domiciles based on their preferences. In college, I had friends who lived without central heating and wore thick jackets to use the bathroom. This was their choice.

                                                                                                                        Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used). I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.

                                                                                                                        For me and many other technologists, technology is primarily about the user and the human component, only secondarily about protocols, implementer ease, ideology, or anything similar. I view technology as slave to the human, not human as slave to the technology. I think you’re going to have a hard time convincing tech users like us otherwise. After all, we’ve had decades of IRC, and even among technologists IRC has lost ground, not gained it. I’m sad to say I don’t think this viewpoint has any bite except among a dedicated few, who will continue to stick to IRC and grumble about new protocols and their freedoms.

                                                                                                                        “Man is born free, yet he is everywhere in chains”

                                                                                                                        1. 1

                                                                                                                          Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about.

                                                                                                                          I agree, and this is the reason why I think we should build everything we can from plaintext. Audio excludes the deaf, visual excludes the blind, but plain text includes the largest possible audience. Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.

                                                                                                                          I view technology as slave to the human, not human as slave to the technology.

                                                                                                                          Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.

                                                                                                                          A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses. The benefit of open platforms is that you get that choice without excluding users on low-end devices who can’t afford to run a fancy Electron app. Open platforms are a means to include everyone and serve the human rather than the platform owner. If your use-case isn’t met, you can build an implementation that meets it.

                                                                                                                          Minority users matter too.

                                                                                                                          1. 7

                                                                                                                            Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.

                                                                                                                            I just don’t agree, and without studies to back this viewpoint up, I’m going to take this as an ideological viewpoint.

                                                                                                                            Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.

                                                                                                                            Indeed, but I think you and I have different definitions of ownership. Simplicity and ease of implementation are not prerequisites for ownership in my mind. That simply passes the buck to the technologists, of which ideally we wouldn’t force the entire population to become, much in the same way the entire population does not fix cars and build houses because they are not interested in those things.

                                                                                                                            A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses.

                                                                                                                            They aren’t. I want protocol level affordances for things like emoji reactions, custom emojis, threads, and such. On top of that I want the protocol to change as folks want to experiment with new things. Extensibility is a feature for me, not a bug. Also, I don’t really think a world where the UX is left in the hands of “interested” is realistic. Gemini still doesn’t have a rich client because technologists aren’t interested in one, and no surprise, the users are almost all technologists or their close, nerdy friends.

                                                                                                                            Regardless I think you and I won’t really see eye-to-eye on this issue, so I wish you the best.

                                                                                                              2. 3

                                                                                                                Whether communication itself changes is perhaps debatable – my understanding is that, at least in the technological realm, the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.

                                                                                                                Sometimes, the constraints of a system determine the patterns of communication, which are then codified into social norms, as you say (IRC favours shorter, plain-text messages, email has “etiquette”, etc.) As more people take part in a platform, it’s inevitable that more and more of these constraints, justifiable as they may be, will become issues that require solutions, features. If the platforms don’t evolve, people will look to move elsewhere, naturally.

                                                                                                                The issue here isn’t the features or the changing expectations or even boxed platforms themselves, but rather that extending a platform with no regard for backwards compatibility tends, in the long term, to exclude people from being able to participate as freely as possible, or at all.

                                                                                                                Even more so, these “moving” platforms impose their own constrains, which in turn become social norms; people don’t expect to have access to their archive, nor are they expected to be able to see out the lifetime of their devices (though this is an issue way beyond communication platforms.)

                                                                                                                Federated or community-owned platforms are better in that regard since interoperability concerns will typically govern their evolution, and thus ensure at least some form of long-term viability and graceful degradation. Extending these platforms with additional features entails more effort, but it does happen – modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set (not everyone has the resources to own a recent, or any, smartphone, and there’s workable XMPP and IRC clients all the way down to J2ME.)

                                                                                                                It basically comes down to this: for me, being able to communicate without fear of falling out of some compatibility cliff is more important than chasing new forms of expression; in lieu of not being able to say anything, I’d rather not be able to express myself in full colour.

                                                                                                                1. 4

                                                                                                                  the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.

                                                                                                                  I would like to push back on this but have run out of time to offer some examples. At the risk of being hasty, take a look at Sea Shanty riffs on TikTok. That form of cultural expression isn’t happening on IRC that’s for sure. (In fact, the image of someone trying to sing or rap on IRC reminds me of NWA and their entry into mainstream music, but that’s too off-topic to be more than an aside on Lobsters.)

                                                                                                                  But I agree with the rest of your post. I also think that community owned communication platforms have a greater incentive to respond to and support members of the community because their incentives are not driven by investors or customers in the same sense. I’ve watched the Fediverse take shape in a very community-oriented way and have had my heart warmed by watching folks organize in a multitude of ways (from mods having fun, to co-ops, to corporations) to enable their users to communicate.

                                                                                                                  1. 1

                                                                                                                    modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set

                                                                                                                    imagine the following situation:

                                                                                                                    • you use an xmpp client that is very simple, it only supports plaintext
                                                                                                                    • you send a question to someone
                                                                                                                    • they send their answer as an animated gif
                                                                                                                    • your xmpp client does not support animated gif, you are not able to read the answer.
                                                                                                                    1. 2

                                                                                                                      This does, of course, happen all the time, as people participate with less featured clients, or clients that do not support much more than text communication (e.g. terminal clients).

                                                                                                                      XMPP is actually a good example of how clients are able to fall back to at least a workable baseline, despite any new protocol-level features or changes. For example:

                                                                                                                      • For P2P file-transfers (e.g. Streams, Jingle), feature negotiation takes place and the sender is required to ensure that the recipient supports the method used. If not the method will not be offered in the first place, which is arguably better than sending into the void.

                                                                                                                      • For client-server file-transfers (e.g. HTTP upload), the recipient will generally see an incoming HTTP URI as a text message, if no other support exists (e.g. for inline display, etc.)

                                                                                                                      • For things like threads, reactions/message attachments and the like, context is usually collapsed and the messages will appear as they would normally in the course of discussion.

                                                                                                                      Ideally, all clients would be able to support all features and these sorts of ambiguities would not exist, but it’s clear that some people aren’t able or willing to participate in the same way as everyone else. And though part of communication is in its intent (after all, a thumbs-up emoji attached to a message is not the same as one posted inline ten messages below), at least these additional features don’t form an “invisible” layer of communication above the baseline.

                                                                                                              3. 3

                                                                                                                I think Matrix is a good attempt at pushing an open product first and an open protocol second. TFA notes that Element is wedded extremely closely to the Matrix spec, which makes it hard to implement, but I think this prioritization of product over protocol is necessary to deliver actual, sticky value to users. Open, federated software needs to enable users firstly; Matrix does document its decisions and open up its spec, but features are driven through the Element experience, which is where the real value for the user comes from.

                                                                                                                1. 2

                                                                                                                  I think there is a lot of truth to what you’re saying, but only up to a point. It’s fine to go the Matrix route as long as there’s a point at which the organization hits the brakes, slows down rapid iteration, and focuses on helping the rest of the ecosystem catch up.

                                                                                                                  I think that Matrix is at a good point for the feature-slowdown to begin.

                                                                                                                  1. 2

                                                                                                                    I’ve tried to onboard friends onto Matrix and they still would like to see more features. Threads come up frequently, and so do custom emojis. We are starting to see more care toward stability in the ecosystem but I think it’s a bit early yet for feature development to stop. Protocol documentation is improving and alternate servers are being birthed (like Conduit). I think client complexity is not explicitly a concern of Matrix, so slowing down now would not help the project achieve it’s goals.