1. 16

      Unfortunately, the comparison is written in such a clearly biased way that it probably makes fossil sound worse than it is (I mean you wouldn’t need to resort to weasel words and name-calling if fossil was valid alternative whose benefits spoke for themselves .. right?). Why would anyone write like that if their aim is to actually promote fossil?

      1. 5

        The table at the top is distractingly polemic, but the actual body of the essay is reasonable and considers both social and technical factors.

        My guess is that author is expecting the audience to nod along with the table before clicking through to the prose; it seems unlikely to be effective for anyone who doesn’t already believe the claims made in the table.

        1. 4

          This is what’s turned me off from even considering using it.

        2. 12

          “Sprawling, incoherent, and inefficient”

          Not sure using a biased comparison from the tool author is useful. Even then, the least they could do is use factual language.

          This is always something that gripes me reading the recurring fossil evangelism: git criticism is interesting and having a different view should give perspective, but the fossil author always use this kind of language that makes it useless. Git adapts to many kind of teams and workflow. The only thing I take from his comparison is that he never learnt to use it and does not want to.

          Now this is also a very valid criticism of git: it is not just a turn-key solution, it needs polish and another system needs to put forth a specific work organization with it. That’s a choice for the project team to make. Fossil wants to impose its own method, which of course gives a more architected, polished, finish, but makes it impossible to use in many teams and projects.

          1. 2

            Maybe they don’t care about widely promoting fossil and just created that page so people stop asking about a comparison?

          2. 5

            One of the main reasons for me for not using Fossil is point 2.7 on that list: “What you should have done vs. What you actually did”. Fossil doesn’t really support history rewrites, so no “rebase” which I use nearly daily.

            1. 2

              This is also a problem with Git. Like you, I use rebase daily to rewrite history, when that was never really my objective; I just want to present a palatable change log before my changes are merged. Whatever happens before that shouldn’t require something as dangerous as a rebase (and force push).

              1. 4

                I don’t think it makes any sense to describe rebases as ‘dangerous’, nor to say that you want to present a palatable change log without rewriting history unless you’re saying you want the VCS to help you write nicer history in the first place?

                1. 2

                  Rebase is not dangerous. You have the reflog to get back to any past state if needed, you can rewrite as much as you need without losing anything.

                  Now, I see only two ways of presenting a palatable change log: either you are able to write it perfectly the first time, or you are able to correct it. I don’t see how any VCS would allow you to do the first one. If you use a machine to try to present it properly (like it seems fossil strives to do), you will undoubtedly hit limitations, forcing the dev to compose with those limitations to write something readable and meaningful to the rest of the team. I very much prefer direct control into what I want to communicate.

                  1. 2

                    I think whether rebase is dangerous depends on the interface you are using Git with. The best UI for Git is, in my opinion, Magit. And when doing a commit you can choose from a variety of options, one of them being “Instant Fixup”.

                    I often use this when I discover that I missed to check-in a new file with a commit or something like that. It basically adds a commit, does an interactive rebase, reorders the commits so that the fixup-commit is next to the one being fixed and executes the rebase pipeline.

                    There are other similar options for committing and Magit makes this straight-forward. So much, indeed, that I have to look up how to do it manually when using the Git CLI.

                    1. 4

                      I prefer to work offline. Prior to Git I used SVK as frontend for SVN since it allowed offline use. However, once Git was released I quickly jumped ship because of its benefits, i.e. real offline copy of all data, better functionality (for me).

                      In your linked document it states “Never use rebase on public branches” and goes on to list how to use rebase locally. So, yes, using rebase on public branches and force-pushing them is obviously only a last resort when things went wrong (e.g. inadvertently added secrets).

                      Since I work offline, often piling up many commits before pushing them to a repo on the web, I use rebase in cases when unpushed commits need further changes. In my other comment I mentioned as example forgotten files. It doesn’t really make sense to add another commit “Oops, forgotten to add file…” when I just as easily can fixup the wrong commit.

                      So the main reason for using rebase for me is correcting unpushed commits which I can often do because I prefer to work offline, pushing the latest commits only when necessary.

                      1. 2

                        In addition to what @gettalong said, keep in mind the original use-case of git is to make submitting patches on mailing lists easier. When creating a patch series, it’s very common to receive feedback and need to make changes. The only way to do that is to rebase.

                  1. 1

                    Thinking out loud:

                    Distributing your work across {fnlam}pipes kills productivity.

                    Corollary: one process programming might net you productivity wins.

                    Computers are fast; you can run StackOverflow on a handful of servers.

                    Maybe you shouldn’t switch to a mainframe, but you might want to consider whether better utilizing your hardware might shrink your problem to a “one process” problem.

                    From the mainframe essay linked above:

                    Yet another problem is that many companies don’t want to switch [from mainframes], because it saves them money to run a small, expensive machine instead of a small, expensive cluster. In The Economist article above, Eurocontrol reported saving 50% on software costs. The NYT article reports that Radixx switched from a cluster to an IBM mainframe and saved 50%.

                    1. 9

                      Something that I’ve been thinking about a lot is that the way that most software is distributed is really hostile to modifications - this post touches on that, but doesn’t go very deep into it. A question I’ve been asking recently is - what would a package manger that’s designed with end-users patching software as a first-class concern look like? And a somewhat more challenging version for some systems - what would it look like to allow end-users to patch their kernels as a first-class concern?

                      NixOS has the start to an answer for this (fork the nixpkgs repo, make whatever changes you like), but it still doesn’t seem ideal. I guess maybe gentoo is a sort of answer to this as well, but it doesn’t seem like gentoo answers the question of “how do you keep track of the changes that you’ve made”, which is I think a really important part of systems like this (and the thing that’s missing in most current package managers support for patching)

                      1. 13

                        Note you don’t need to fork nixpkgs to edit individual packages, you can just add them to an overlay with an override eg I was trying to debug sway recently so I have:

                        (sway.overrideDerivation (oldAttrs: {
                              src = fetchFromGitHub {
                                owner = "swaywm";
                                repo = "sway";
                                rev = "master";
                                sha256 = "00sf8fnbj8x2fwgfby6kcrxjxsc3m6w1yr63kpq6hv94k3p510nz";
                              };
                            }))
                        

                        One of the guix devs gave a talk called Practical Software Freedom (slides) where the core point was that it’s not enough to have foss licensing if editing code is so much of a pain that noone does it. It looks like guix has a pretty nice workflow for editing installed packages, and since the tooling is all scriptable I bet you could streamline it even more - eg add a command for “download the source, fork it to my personal repo, add the fork to my packages list”.

                        1. 6

                          I only very briefly used guix, but its kernel configuration system is also just scheme. It’s so much nicer than using any of the kernel configurators that come with the kernel, and I actually played around with different configurations rather than opting to play it safe which is what I normally do since it’s such a faff if I accidentally compile out support for something important.

                          1. 2

                            How often do you find your overlays breaking something in strange ways? My impression is that most packages don’t come with tests or other guardrails to give early warning if I break something. Is that accurate?

                            1. 3

                              I haven’t had any problems so far. I guess if you upgrade a package and it changes the api then you might be in trouble, but for the most part it seems to just work.

                          2. 6

                            One thing this brought to mind was @akkartik’s “layers” script: http://akkartik.name/post/wart-layers

                            The post is short, but the money quote is here:

                            We aren’t just reordering bits here. There’s a new constraint that has no counterpart in current programming practice — remove a feature, and everything before it should build and pass its tests

                            If we then built software such that reordering commits was less likely to cause merge conflicts, you could imagine users having a much easier time checking out a simpler version of the system and adding their functionality to that if the final version of the system was too complex to modify.

                            1. 4

                              I’ve gotten close with rpm and COPRs. I can fairly quickly download a source RPM, use rpmbuild -bp to get a prepped source tree where I can build a patch, track it, and add it back to the spec, then push it to a COPR which will build it for me and give me a yum repository I can add to any machines I want. Those pick up my changed version of the package instead of the upstream with minimal config fiddling.

                              It’s not quite “end users patching as a first class concern” but it is really nice and in that ballpark.

                              1. 3

                                At that point the package system would just be a distributed version control system, right?

                                1. 1

                                  Interesting point! And I guess that’s kinda the approach that Go took from the start, with imports directly from GitHub. Except, ideally, you’d have a mutable layer on top. So something like IPFS, where you have the mutable IPNS namespace that points to the immutable IPFS content-addressed distributed filesystem.

                                  Still, unlike direct links to someone elses GitHub repo, you would want to be able to pin versions. So you would want to point to your own namespace, and then you could choose how and when to sync your namespace with another person’s.

                                  1. 3

                                    This is how https://www.unisonweb.org/ works. Functions are content-addressed ie defined by the hash of their contents, with the name as useful metadata for the programmer. The compiler has a bunch of builtin refactoring tools to help you splice changes into an existing graph of functions.

                                    1. 2

                                      Just watched the 2019 strangeloop talk. Absolutely brilliant. Only drawback I see is that it doesn’t help with code written in other languages. So dependency hell is still a thing. But at least you’re not adding levels to that hell as you write more code (unless you add more outside dependencies).

                                2. 2

                                  what would a package manger that’s designed with end-users patching software as a first-class concern look like?

                                  If you just want to patch your instance of the software and run it locally, it is very straightforward in Debian and related distributions, using apt-src. I do it often, for minor things and pet peeves. Never tried to package these changes and share them with others, though.

                                  1. 1

                                    All the stuff package managers do doesn’t seem to help (and mostly introduces new obstacles for) the #1 issue in modifying software: “where are the sources?” It should be dead easy to figure out where the sources are for any program on my system, then to edit them, then to run their tests, then to install them. Maybe src as the analogue to which?

                                    I appreciate npm and OpenBSD to a lesser extent for this. Does Gentoo also have a standard place for sources?

                                    1. 1

                                      I believe Debian is trying to streamline this with Salsa. That’s the first place I look when I’m looking for source code of any package on my system.

                                    2. 1

                                      what would a package manger that’s designed with end-users patching software as a first-class concern look like?

                                      A DVCS. (It’s Christmas, “Away in a package manger, no .dpkg for a bed…”)

                                      We drop in vendor branches of 3rd party libraries into our code as needed.

                                      We hack and slash’em as needed.

                                      We upstream patches that we believe upstream might want.

                                      We upgrade when we want, merging upstream into our branch, and the DVCS (in our case mercurial) tells us what changed up stream vs what changed locally. Some of the stuff that changed upstream is our patches of improvements on them, so 99% of the time we take the upstream changes, and 0.9% of time take our changes and 0.1% of the time have to think hard. (ps: 99% of stats including this one are made up (from gut feel) on the spot. What makes these stats special is I admit it.)

                                      A related topic is the plague of configuration knobs.

                                      Every time any programming asks, “What should these configuration value be? He says, dunno, make it an item (at best) in the .conf file or at worst, in the UI.”

                                      The ‘net effect is the probability of the exact configuration ever having been tested by anyone else on the planet is very very very low and a UI that you’d either need a Phd to drive (or more likely is full of wild arsed guesses)

                                      A good habit is, unless there is a screaming need, by default put config items in a hidden (to the user) file and that is not part of the user documentation.

                                      If anybody starts howling that they need to alter that knob, you might let them into the secret for that knob, and consider moving it into a more public place.

                                    1. 1

                                      I got a LTO4 tape drive on a whim, but I haven’t had any luck figuring out how to find an appropriate SAS controller to actually use it. Makes me sad looking at it sitting on the shelf.

                                      PS. For the curious, it seems to be a SFF-8482 connection but I’m lost on what to do with this information.

                                      1. 1

                                        Oh wow, LTO4 tapes are cheaper than I thought!

                                        This IEEE piece on tape storage a few months ago made me consider buying a tape drive for the first time, especially after reading about the surprising spec’d failure rates of both spinning disks and SSDs in @dl’s Deconstruct talk on why filesystems are hard to use correctly.

                                        1. 1

                                          The tapes may be cheaper for the capacity but the hardware to read and write to them are still prohibitively expensive for casual users.

                                          1. 1

                                            I will look into cheap SAS controllers from China (ie ebay).

                                      1. 1

                                        Mine is https://distinctly.pink/archive.html, or you might want the atom feed.

                                        I keep meaning to write more and then not doing so. When I do write I don’t have any particular topic list in mind that I try to stick to, but it’s usually going to be things which interest me, so Emacs, Lisp, Plan 9, retro digital typography, music, environmentalism (I’ve got quite a long list of half-written posts, and each of those topics comes up more than once).

                                        There’s no particular reason why you should read it, and checking manually for new updates will probably result in diminishing returns. If you’re marginally interested in anything I mentioned above, the best way is probably to add my feed to your feed reader - that way you can see when I write and ignore it if it doesn’t interest you. That’s what I do, because ultimately it’s a personal site and we should be doing as much as possible to support and promote people who still use them.

                                        1. 2

                                          Such a lovely URL! I look forward to seeing it in my RSS reader :)

                                          1. 1

                                            Nice design! Love minimalism) checkout mine too medv.io

                                            1. 1

                                              Had a lot of fun with that little planes game :)

                                          1. 23

                                            I would maybe use Go/Rust

                                            “Go/Rust” is a great shortcut for “I don’t know anything about programming languages”. ;)

                                            1. 13

                                              I think your average “dark matter” type of programmer isn’t going to have much exposure to these. Of course, I think Go is likely to become one of those dark matter developer languages like Java or VB became.

                                              1. 4

                                                I thought that a) Go is already a dark matter language b) people who think Rust is like Go already know Go and fell victim to the Blub phenomenon. I may be wrong on both counts of course,

                                                1. 9

                                                  Depends on the timeframe. For your typical Bay Area shop, your typical “SRE DevOps Peon” will likely use Go. Outside of the HN bubble, most companies doing line-of-business type stuff that aren’t hopelessly outdated are usually doing it still in Java/C#/PHP, maybe JS.

                                                2. 2

                                                  It could be. I tried to do a project in Go. I couldn’t easily express ideas due to how basic its primitives are. That Rob Pike quote became real for me. I just tossed that entire prototype, kept using Python, and started looking at more expressive languages.

                                                  On the plus side, I can see how its simplicity makes onboarding easier, probably easier to maintain random codebases than C++ or Java/.Net, and dramatically improves ability to make the tooling. It just didn’t fit me. I could see me using a more expressive language that outputs something like Go in human-readable form to keep those benefits, though. I just gotta keep my personal productivity up since it’s scarce to begin with (outside work).

                                                3. 12

                                                  I don’t think this is fair.

                                                  I have to use both Rust and Go at work - compared to other mainstream languages these happen to be two of three that give you automatic memory management and memory safety without outsized and unpredictable latency penalties for typical software.

                                                  I understand where you’re coming from, because the mechanisms they for this are quite different - Rust accomplishes this via stack allocation by default via the borrow checker and RAII and Go accomplishes this via the combination of automatic stack allocation via escape analysis and the core team’s focus on the impact of garbage collection latency - but that doesn’t mean that they aren’t reasonable to group together among other mainstream programming languages in 2020.

                                                  1. 5

                                                    I feel like this is the point of the article, though! OP hasn’t had time to actually put in research about it and won’t have time, unless it becomes a direct part of their job.

                                                    1. 4

                                                      I wouldn’t go that far; while this person is self-admittedly a very average programmer, and while there are some reasons to view Rust and Go as languages that are best suited for two different categories of work, they do share some important commonalities that the author is rightly picking up on. Both of them had the design goals of being immediately, practically useful to mainstream software engineers (rather than being research languages exploring esoteric PL theory features). They were consolidations of a few decades of lessons learned from the flaws of other mainstream programming languages, rather than trying to do anything radically new. They both spent a lot of effort on building practical tooling around the compiler. And they were both developed at roughly the same time. There are quite a few areas of programming where either Go or Rust would be a reasonable choice.

                                                      1. 2

                                                        Disagree, I see quite a few problems and requirements where I’d use one of the two over, say, C++ and with the same reasons I wouldn’t use Python or PHP.

                                                        You’re just as much overgeneralizing as the author did.

                                                        1. 2

                                                          In one of the rule on C / C++, Rust could be an alternative there. I think comparing Rust to C / C++ would be better than Go.

                                                          1. 1

                                                            Ok wait but the rest of the sentence qualifies:

                                                            I would maybe use Go/Rust if I was building a fresh web service where latency, and performance were more important than community/library support.

                                                            Maybe a more precise spelling would have been “Go or Rust” instead of “Go/Rust”, but I think the meaning was clear given the whole sentence.

                                                          1. 4

                                                            This is such welcome knowledge given what I know now about files and the (lack of) durability of traditional disk drives and SSDs after reading https://danluu.com/deconstruct-files/ last year.

                                                            e.g.:

                                                            If we look at SSD datasheets … I think people are often surprised to find that it’s within spec for a drive to lose data three months after the data is written.

                                                            1. 2

                                                              This is a simple prototype that dovetails with many ideas I’ve had about spatial interfaces for thinking; even better, the implementation seems like it’s actually going to be usable enough to critique, assuming you have a Chromebook with a stylus to try it on.

                                                              1. 4

                                                                This looks really neat! Going to give using it a shot this weekend.

                                                                1. 1

                                                                  Thanks! Looking forward to your feedback.

                                                                1. 2

                                                                  Look into Qubes if you’re feeling truly paranoid.

                                                                  1. 4

                                                                    It only runs on backdoored platforms that get a lot of scrutiny from black hats, too. Last I checked, also on a virtualization platform not built for security. So, one must consider who has the backdoors and rate of bugs found in threat analysis. Although paranoids don’t trust computers at all, the safest option is still probably Leon3’s GPL edition since all the hardware was open. One could get silicon, FOSS drivers, etc. Just need one, big fundraiser. :)

                                                                    Note: Alternatively, a recent design like Rocket (RISC-V) or OpenPITON. I like highlighting Leon3 since it’s just been siting there waiting for FOSS to use for years without any action.

                                                                  1. 3

                                                                    Interconnections, by Radia Perlman, goes into some detail about how lower-level network protocols are designed including the tradeoffs and the human issues involved in designing them. You could probably get a sense for tradeoffs that would also apply to higher level protocol design.

                                                                    1. 15

                                                                      I started researching the GitHub APIs that would be relevant to implement something like this a few months ago, but I’m really hesitant to sink a lot of investment into GitHub and its accompanying monopoly in my free time.

                                                                      I’ve moved a bunch of my personal projects over to GitLab, but they’ve been doing stupid stuff like refusing to render static repository content without whitelisting Javascript, or telling my my two-week-old browser is unsupported because it’s outdated, so … not a lot of motivation to invest in that ecosystem either.

                                                                      1. 13

                                                                        This. I noticed the mandatory JS for rendering nonsense too. I really want to like GitLab, and have tried multiple times to use them as my main, but to me the UX is just inferior to GitHub. The UI is sluggish and feels very bloated.

                                                                        It’s been a while since I’ve given up on GitLab for the time being, and have been self-hosting Gitea. Now Gitea uses JS too, but also works quite well without it. And it’s nowhere near as slow as GitLab.

                                                                        1. 5

                                                                          but to me the UX is just inferior to GitHub.

                                                                          Well, GitLab for all its faults doesn’t hijack my Emacs key bindings to do idiotic shit like “bold this thing in markdown” (which was already only two keystrokes to begin with; why are you adding a shortcut for something I never do on ctrl-b that I use all the time?) so I wouldn’t say GitLab has quite sunk to that level yet.

                                                                          1. 3

                                                                            Interesting. That’s a fair point; though GitHub’s editor isn’t the first to do that. I hadn’t noticed it with GitHub mainly because I use Vimium in Firefox, Evil in Emacs, and bspwm; so I rarely use Emacs-style bindings but I agree that could be frustrating.

                                                                            Does exwm’s simulation keys work around the issue, or does GitHub’s in-browser binding take precedence?

                                                                            EDIT: There’s also xkeysnail, though it does require running as root.

                                                                            EDIT2: It seems like running xkeysnail as root may not be necessary if the user has access to input devices. On Arch (or any distro with systemd >= 215) that can be achieved by adding the user to the input group (see here and here).

                                                                            EDIT3: The Emacs-keybinding extension may be another option, though apparently it only works in macOS. There’s also shortkeys but I haven’t tried either one.

                                                                            1. -2

                                                                              If you’re editing text, Ctrl-B for bold (or Ctrl-F if you’re in Germany) should be expected. Editing text means Word keybindings, not Emacs bindings.

                                                                              This also means Ctrl-I for italic (or Ctrl-K in Germany) and Ctrl-U for underlined (this one is actually the same).

                                                                              1. 12

                                                                                I strongly disagree, at least on a Macintosh, where all native text entry widgetsobey the Emacs keybindings. Web garbage that arrogates system functionality to itself, hijacking my chosen platform experience for a poor copy of some other system is noxious, and broken.

                                                                                1. 0

                                                                                  I just tried in the macOS Notes app and ctrl+b makes the text bold. The Pages app does the same, ctrl+b makes the text bold. These are two native text entry applications developed and provided by Apple themselves.

                                                                                  1. 6

                                                                                    No, you are pressing cmd. Control is reserved for motion.

                                                                                    1. 1

                                                                                      That’s the problem of your system then – the browser explicitly exposes Ctrl, Alt, Meta. If your keyboard does not offer these, either your browser, OS, or keyboard has to map between these and the actual keys.

                                                                                      Users on all other systems (aka 99.5% of users) expect Ctrl-B (or Ctrl-F) to create bold text.

                                                                                      1. 6

                                                                                        No, users on Macs expect their modifier keys to respect platform convention – Emacs keybindings for movement, cmd for meta. To assume otherwise is disrespectful.

                                                                                        1. 0

                                                                                          So what do you suggest? Breaking keybindings for all windows and linux users instead?

                                                                                          1. 4

                                                                                            No, use the proper keybindings for the platform that the user is using.

                                                                                            1. 0

                                                                                              So how do you suggest to do that without using heuristics on the useragent?

                                                                                              I’d be interested in your implementation of a JS function that returns the correct set of modifiers and keys to use for the bold shortcut. And which works reliably.

                                                                                              Currently, the browser doesn’t expose this, so everyone gets the most commonly used solution.

                                                                                              1. 3

                                                                                                Currently, the browser doesn’t expose this, so everyone gets the most commonly used solution.

                                                                                                ????

                                                                                                Note: On Macintosh keyboards, [.metaKey] is the ⌘ Command key.

                                                                                                MOD_KEY_FIELD = navigator.platform.startsWith('Mac') ? 'metaKey' : 'ctrlKey';
                                                                                                
                                                                                                // lazy
                                                                                                if (keyEvent.ctrlKey && ...
                                                                                                
                                                                                                // bare minimum for any self-respecting developer
                                                                                                if (keyEvent[MOD_KEY_FIELD] && ...
                                                                                                

                                                                                                What I want to know is how you’re commenting from 1997. Just hang tight, in a couple years two nerds are gonna found a company called Google and make it a lot easier to find information on the internet.

                                                                                            2. 3

                                                                                              Using the proper modifier depending on platform? The browser should expose “application-level modifier” say, for bold, and that would be ^B on X11/Windows and Super-B for Mac.

                                                                                              1. 0

                                                                                                The browser isn’t exposing this, though. The best chance is sniffing the user agent and then using heuristics on that, but that breaks easily as well.

                                                                                          2. 2

                                                                                            100 - 99.5 != 12.8, your assumption is off by a factor of 25.

                                                                                          3. 1

                                                                                            You’re right. Lord I’m an idiot.

                                                                                          4. 4

                                                                                            Ctrl+b on my Mac goes back a character in both macOS Notes and Pages, as it does everywhere else. Cmd+b bolds text (as also it does everywhere else).

                                                                                            In general, Macs don’t use the Ctrl key as a modifier too often (although you can change that if you want). They usually leave the readline keybindings free for text fields. This seems to be by design

                                                                                            The standard key bindings are specified in /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict. These standard bindings include a large number of Emacs-compatible control key bindings…

                                                                                        2. 4

                                                                                          Editing text means Word keybindings, not Emacs bindings.

                                                                                          Those of us who use emacs to edit text expect editing text to imply emacs keybindings.

                                                                                          Some of us expect them everywhere, even.

                                                                                          1. 3

                                                                                            If it was a rich text WYSIWYG entry, I’d be 100% agreed with you. (I would also be annoyed, but for different reasons.)

                                                                                            But this is a markdown input box. The entire point of markdown is to support formatted text which is entered as plain text.

                                                                                      2. 3

                                                                                        It’d be great if we had a language server protocol extension for code review + a gerrit backend. I started taking a look at this a few months ago (I work mostly in Gerrit now) but didn’t have the bandwidth for actually prototyping it. It seems like an obviously good idea, though having to use git hampers some of the possibilities.

                                                                                      1. 18

                                                                                        Slightly off topic: I see people complaining a lot about Electron, with Slack being a prime example.

                                                                                        I think the success of Visual Studio Code means that it is possible to build excellent apps using Electron. And that the performance of Slack app is not necessarily representative of all Electron based apps.

                                                                                        1. 26

                                                                                          I think it’s possible. But VSC is literally the only Electron app that doesn’t blatantly suck performance-wise. Is that because Microsoft just actually put in the effort to make something good? Or is it because Microsoft has built best-in-class IDEs that scale radically better than any alternative for a long long long time?

                                                                                          Now no one get me wrong, I’m a UNIX guy through and through, but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about. C++ as a language is complete bullshit, the most hostile language you can write an IDE for. Building an IDE for any other language is child’s play in comparison, and Microsoft is proving it with VSC.

                                                                                          I don’t think it’s currently possible for anyone besides Microsoft to make an excellent Electron app. They took a bunch of internal skill for building huge GUI applications that scale, and built their own language to translate that skill to a cross platform environment. I think they could have chosen whatever platform they felt like, and only chose to target Javascript because the web / cloud is good for business. We’ll start seeing good Electron apps when Typescript and the Microsoft way become the de facto standard for building Electron apps.

                                                                                          But I also haven’t slept in 24 hours so maybe I’m crazy. I reckon I’ll go to bed now.

                                                                                          1. 7

                                                                                            but anyone who claims there’s anything better than Visual Studio for large scale C++ development has no clue what they’re talking about.

                                                                                            JetBrains CLion might actually be a bit better – but they started building addons to improve development in VisualStudio (e.g. the amazing ReSharper) originally, and only expanded to build their own IDE later on.

                                                                                            I fully agree on all other points.

                                                                                            1. 5

                                                                                              CLion definitely has a great feature set, but I’ve found a lot of it to be unusably slow, at least on our large codebase. Lots of us use Qt Creator even though it’s objectively worse and has some sketchy bugs, because it’s at least fast for the stuff it does do. I look forward to the day I can comfortably switch to CLion.

                                                                                              1. 3

                                                                                                CLion is fantastic, I came to it after a lot of use of PyCharm.

                                                                                            2. 3

                                                                                              Is there a chance that the ill reputation of Electron apps is that Electron itself offers ample opportunity for prime footgunmanship?

                                                                                              I’d argue that yes, it’s quite possible to build a nice simple (moderately) lightweight thing in Electron; it’s just pretty hard in comparison to building, say, a nice simple (definitely) lightweight CLI. Or even a desktop app using a regular graphical toolkit?

                                                                                              1. 10

                                                                                                Visual Studio Code, Slack, Discord, WhatsApp, Spotify all are unfortunately not simple. And while they could be reduced to simpler apps, I kinda feel like we’re all using them exactly because they have all these advanced features. These features are not useless, and a simpler app would disappoint.

                                                                                                It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

                                                                                                1. 4

                                                                                                  I’m a huge fan of CLI software that eats text and outputs text. It’s easier to integrate into my flow, and the plethora of tools that are already available to manipulate the inputs and outputs.

                                                                                                  An example: I’ve written a CLI client to JIRA that I have plugged into the Acme editor. I just tweaked my output templates a bit to include commands that I’d want to run related to a given ticket as part of my regular output, and added a very simple plumber rule that fetches a ticket’s information if I right-click anything that looks like a JIRA ticket (TASK-1234, for example). It’s served me well as a means to not have to deal with the JIRA UI, which I find bloated and unintuitive, and it allows me to remain in the context of my work to deal with the annoyance of updating a ticket (or fetching info regarding a ticket (or listing tickets, or pretty much anything really)). It’s far from perfect, but it covers most, if not all, of my day-to-day interaction with JIRA, and it’s all just an integration of different programs that know how to deal with text.

                                                                                                  [edit: It’s far from perfect, but I find it better than the alternative]

                                                                                                  1. 1

                                                                                                    Is either part of that open-source by chance? I’ve been trying acme as my editor and use JIRA at work. I have a hunch you’re largely describing four lines of plumb rules and a short shell script, but I’m still having trouble wrapping my head around the right way to do these things.

                                                                                                    1. 3

                                                                                                      Full disclosure, the JIRA thing has bugs that have not stopped me from using it in any meaningful way. https://github.com/otremblay/jkl

                                                                                                      The acme plumbing rule is as follows:

                                                                                                      type	is	text
                                                                                                      data	matches	'([A-Za-z]+)-([0-9]+)'    
                                                                                                      plumb	start	rc -c 'jkl '$1'-'$2' >[2=1] | nobs | plumb -i -d edit -a ''action=showdata filename=/jkl/'$1'-'$2''''
                                                                                                      

                                                                                                      It checks for a file called “.jklrc” in $HOME. Its shape is as follows:

                                                                                                      JIRA_ROOT=https://your.jira.server/   
                                                                                                      JIRA_USER=yourusername
                                                                                                      JIRA_PASSWORD=yourpassword
                                                                                                      JIRA_PROJECT=PROJECTKEY
                                                                                                      #JKLNOCOLOR=true
                                                                                                      RED_ISSUE_STATUSES=Open
                                                                                                      BLUE_ISSUE_STATUSES=Ready for QA,In QA,Ready for Deploy
                                                                                                      YELLOW_ISSUE_STATUSES=default
                                                                                                      GREEN_ISSUE_STATUSES=Done,Closed
                                                                                                      # The following is the template for a given issue. You don't need this, but mine contains commands that jkl can run using middleclick.
                                                                                                      JKL_ISSUE_TMPL="{{$key := .Key}}{{$key}}	{{if .Fields.IssueType}}[{{.Fields.IssueType.Name}}]{{end}}	{{.Fields.Summary}}\n\nURL: {{.URL}}\n\n{{if .Fields.Status}}Status:	 {{.Fields.Status.Name}}\n{{end}}Transitions: {{range .Transitions}}\n	{{.Name}}	| jkl {{$key}} '{{.Name}}'{{end}}\n\n{{if .Fields.Assignee}}Assignee:	{{.Fields.Assignee.Name}}\n{{end}}jkl assign {{$key}} otremblay\n\nTime Remaining/Original Estimate:	{{.Fields.PrettyRemaining}} / {{.Fields.PrettyOriginalEstimate}}\n\n{{.PrintExtraFields}}\n\nDescription:   {{.Fields.Description}} \n\nIssue Links: \n{{range .Fields.IssueLinks}}	{{.}}\n{{end}}\n\nComments: jkl comment {{$key}}\n\n{{if .Fields.Comment }}{{$k := $key}}{{range .Fields.Comment.Comments}}{{.Author.DisplayName}} [~{{.Author.Name}}] (jkl edit {{$k}}~{{.Id}}):\n-----------------\n{{.Body}}\n-----------------\n\n{{end}}{{end}}"
                                                                                                      
                                                                                                      1. 1

                                                                                                        Thank you so much! I’ll take a look shortly. It really helps to see real-world examples like this.

                                                                                                        1. 2

                                                                                                          If “jkl” blows up in your face, I totally accept PRs. If you decide to go down that path, I’m sorry about the state of the code. :P

                                                                                                  2. 1

                                                                                                    It also seems like GUI and CLI toolkits are lagging behind the Web by maybe a decade, no joke. I’d love to see a native framework that implements the React+Redux flow. Doesn’t even have to be portable or JavaScript.

                                                                                                    I couldn’t disagree more. Sure, maybe in “developer ergonomics” Web is ahead, but GUI trounces Web in terms of performance and consistency.

                                                                                                    1. 1

                                                                                                      I’d love to see a native framework that implements the React+Redux flow.

                                                                                                      Maybe Flutter?

                                                                                                      1. 1

                                                                                                        Flutter is such a native framework, although only for mobile (i.e. Android & iOS).

                                                                                                      2. 2

                                                                                                        I belive one of the things that gave Electron apps a bad reputation (aside from the obvious technological issuses) were things like “new” web browsers, built with electron, offering nothing practically new, that most people would actually want, such as lower memory consumption, for example.

                                                                                                        1. 2

                                                                                                          Building UIs is hard in general - it seems like electron trades off ease of making UIs performant for ease of building them.

                                                                                                          That being said, it seems like it’s not prohibitively difficult to build a fast UI in electron: https://keminglabs.com/blog/building-a-fast-electron-app-with-rust/

                                                                                                          It seems like most people building electron apps just don’t think about performance until much later in the process of development.

                                                                                                        2. 2

                                                                                                          I think one of the few main selling points of Electron was accessibility. Anybody with solid knowledge of HTML, CSS and JS could find his way around and build the app that was running on multiple platforms. But it wasn’t performant and it was quite resource hog as it turned out. Now why is this not the case with Visual Studio Code? Because it is being written by really good developers, who are working for Microsoft, who worked on creating Typescript, in which is Visual Studio Code written, on top of Electron. Now you can get the sense of things why Visual Studio Code is different case than rest of the Electron apps, people behind it are the reason. And whole story defeats the point of Electron. If Electron as a platform could produce half as good results as VSC in terms of performance and resource efficiency than maybe it would be more viable option, as it is right now, I can see the pendulum swinging back to some other native way of implementing applications.

                                                                                                          1. 2

                                                                                                            I mean, I hate the web stack like few others, but I think the point that ultimately the people are more determinative than the technology stands.

                                                                                                            I just really hate the web.

                                                                                                          2. 1

                                                                                                            I completely agree. I think that a lot of the frustrations with the quality of Electron apps is misplaced.

                                                                                                          1. 2

                                                                                                            Perhaps something like a simple form of codegen for common data structures and algorithms?

                                                                                                            Isn’t go generate exactly this feature?

                                                                                                            1. 4

                                                                                                              Superficially, yes. Realistically, it has usability issues that disqualify it as “simple”. It’s not an integrated part of the build process, so here’s hoping you have a script that you can drop it into, and you’re not in the habit of actually using go build (which falls short of the 40-year-old make when it comes to rebuilding generated files as needed when something changes). If it’s a library you’re using that requires codegen to fit your app, it’s that much worse, since now the library is imposing on your build process. Plus go generate‘s only mode of operation is processing one file with magical comments and generating a different disk file for the build to find later, which you’ll probably be forced to check in whether you like it or not. Compare to macros (any sort), which are processed logically by the compiler without having to plop the generated source down on disk and manage it separately. Or the kind of codegen commonly employed in libraries in dynamic languages, which, hey, it might be string eval, but at least it goes off cleanly without user interaction. And when you consider that 99% of the use of go generate is for stuff that in a sane world wouldn’t require codegen at all…

                                                                                                              I write Go for work, and most of the time I even like it, but sometimes I swear the Go devs are passing off laziness and failure of imagination as wisdom and timeless minimalism.

                                                                                                              1. 1

                                                                                                                I write Go for work, and most of the time I even like it, but sometimes I swear the Go devs are passing off laziness and failure of imagination as wisdom and timeless minimalism.

                                                                                                                This is a great quote and I hope to use it some day.

                                                                                                            1. 5

                                                                                                              I’m not sure if this is a great strategy but it approximates what I actually did over my first four years of programming, mostly because I wasn’t beholden to anyone for the first two and could dabble in whatever I want. I feel like the following effect referenced in the article is one of the biggest advantages, especially at a big company:

                                                                                                              As the popularity of languages ebb and flow, you will have a wider choice of jobs, companies and projects if you’re not limited by language choice.

                                                                                                              I’m at Google now and being free to contribute to any project across the whole company (20% time and all that) has been empowering.

                                                                                                              1. 5

                                                                                                                Is there a place for downvoting something as “not well reasoned?”

                                                                                                                1. 3

                                                                                                                  I don’t think so, because that seems like the purpose of a comment. If someone says “A, therefore not B,” just saying “not well reasoned” is not a valuable downvote. You might say: “I don’t see any connection between A and B, so this doesn’t seem like a sound argument.” The initial commenter might then say: “Oh, I see what you mean…” or they might say “I know it’s not obvious, but please see this paper by Philip Wadler.” Discussion leads to learning opportunities for both parties. A down-vote just leads to the commenter’s frustration.

                                                                                                                  1. 1

                                                                                                                    The only downside of replying with a comment is that you end up with the phenomen of weak top comments on a story, with the top replies being effective takedowns of the ideas in the top comment. Even well intentioned people can miss weaknesses in comments the first time they’re read (and upvote them), so a lot of space is wasted on refutation and other good top-level comments get drowned. A downvote option lets those sink to the bottom.

                                                                                                                  2. 1

                                                                                                                    I think if something is not well reasoned you can either:

                                                                                                                    1. Reply and ask if they can develop their point a bit more
                                                                                                                    2. Ignore them

                                                                                                                    I don’t think writing half-assed comments is a sin and thus it shouldn’t be punished. Just ignore them and let their comments sit with 1 points at the bottom of the page.

                                                                                                                  1. 2

                                                                                                                    They should rename it “rustd”!

                                                                                                                    1. 5

                                                                                                                      With REST, there is a continuous tension between efficiently satisfying the data needs of specific clients, and keeping the number of endpoints manageable. The reason for this tension is that a server defines what data an endpoint returns, and the client merely requests it. Especially in mobile apps, the overhead of performing separate requests or of requesting extraneous data is often unacceptable, so we’re forced to add ad-hoc endpoints with custom response structures.

                                                                                                                      In some cases, yes, this might be true but this usually applies for extremely complex mobile applications that have a very good understanding of the underlying infrastructure. It’s not a big surprise that Facebook came up with this solution as its mobile application is probably one of the most complex apps out there. I don’t think the complexity required by implement a GraphQL-like interface will help a lot of APIs (two high-profile examples might be Twitter and Netflix).

                                                                                                                      Also, if the REST APIs are simple (as in “not complex”) this doesn’t mean that it’s a bad thing. On the contrary, it’s a lot easier to understand and implement a client that’s working with a REST API because the entities are so obvious and the way to query them is also very obvious.

                                                                                                                      1. 4

                                                                                                                        As a counterpoint, Netflix simultaneously invented a specification called JSONGraph that is extremely similar to GraphQL, mostly because of the huge variety of clients that were all being forced to consume the same API, leading to response payloads that were optimal for none of them. The idea of client-driven query endpoints is here to stay, I think.

                                                                                                                        1. 4

                                                                                                                          I think that, contrary to the linked article, both REST and GraphQL are here to stay. I believe that GraphQL might be better suited for complex API interactions while REST has (or could have) a simplicity that can be beneficial for simpler clients.

                                                                                                                      1. 1

                                                                                                                        A transcript of the talk is available here: http://jvns.ca/blog/2016/09/17/strange-loop-talk/

                                                                                                                        1. 6

                                                                                                                          My first response was too much of a troll for sure. Here’s a more detailed and constructive review.

                                                                                                                          “A large class of errors are caught, earlier in the development process…”

                                                                                                                          Caught in an earlier stage, perhaps not earlier in time. Dynamic languages do not have a compile stage. That large class of errors can be caught in different ways with a disciplined interactive dynamic languages methodology.

                                                                                                                          “closer to the location where they are introduced”

                                                                                                                          Again interactive programming provided a means of working “closer to the problem”. Which is closer? There’s no information about how to tell.

                                                                                                                          “The types guide development and can even write code for you—the programmer ends up with less to specify”

                                                                                                                          Which is true of declarative programming of various flavors, even the dynamic kind. Again there’s no comparison with other dynamic means of declarative programming, so again we do not know which lead to less code or less churn.

                                                                                                                          “More advanced dependently typed languages routinely derive large amounts of boring code with guidance from the programmer”

                                                                                                                          Again this is not in comparison to anything. What is the cost in time or effort, and what kinds of problems are most suitable for current dependent tupe systems? Perhaps that boring code is not needed and a little exploration in a rapid prototyping system with a customer can rule out the need for it. Perhaps the code in question has already been developed and validated, and there’s no value in rewriting it in a dependently typed system.

                                                                                                                          I’ve no experience with depended types, but my sense is there’s a cost curve for many situations where Horse Logic semi-formally applied could be more cost effective in practice. But either way there’s no evidence presented.

                                                                                                                          “One can refactor with greater confidence…”

                                                                                                                          Greater confidence than what? The smalltalk refactoring browser was the first, most featured for years. Simple, expressive languages with good tools can be more effective than languages with more rules. So this argument without evidence sounds theoretically true, but there’s sufficient experienced in the field over decades to suggest it’s not necessarily true in practice.

                                                                                                                          “Static types can ease the mental burden of writing programs, by automatically tracking information the programmer would otherwise have to track mentally in some fashion”

                                                                                                                          This is a false dichotomy. Some dynamic languages have very good tools that programmers in some static languages would envy.

                                                                                                                          “Types serve as documentation for yourself and other programmers and provide a ‘gradient’ that tells you what terms make sense to write”

                                                                                                                          These tend not to be sufficient for understanding dynamic systems. And again good tools are able to discover most of this in a dynamic language system. And good practice including documentation can be cost effective. Once again there’s no way to tell from this article, it’s just a proclamation of what the author believes or feels based on whatever experiences they’ve had, but failed to explain.

                                                                                                                          “Dynamic languages executed naively…”

                                                                                                                          Anything done naively will have faults. But there are many situations where a naïve approach can be the most effective overall. And there are many situations where a dynamically typed system can perform close to or better than C. There’s nothing to make of this point in the article.

                                                                                                                          “You often need some sort of JIT to get really good performance…”

                                                                                                                          Some dynamic languages support compile-ahead plus an interpreter for the truly dynamic runtime needs. Also whole-program deployment tools can eliminate many of the costs of an otherwise dynamic runtime.

                                                                                                                          “learning how best to carve a program up into types is a skill that takes years to master”

                                                                                                                          The same is true of dynamic language systems. Yet we take the bad examples as the norm for them. Programming is hard no matter what. It takes a lot of experience and discernment.

                                                                                                                          1. 12

                                                                                                                            A few points in your reply that my experience disagrees with:

                                                                                                                            closer to the location where they are introduced

                                                                                                                            Again interactive programming provided a means of working “closer to the problem”. Which is closer? There’s no information about how to tell.

                                                                                                                            What do you mean here? One can do interactive programming in statically typed languages as well, and statically typed languages will have the opportunity (through using lots of types) to make the problem visible closer to its introduction point.

                                                                                                                            A large class of errors are caught, earlier in the development process…

                                                                                                                            Caught in an earlier stage, perhaps not earlier in time. Dynamic languages do not have a compile stage. That large class of errors can be caught in different ways with a disciplined interactive dynamic languages methodology.

                                                                                                                            IME that discipline looks a lot like one would get “for free” from a statically typed language. What kind of discipline are you talking about?

                                                                                                                            One can refactor with greater confidence…

                                                                                                                            Greater confidence than what? The smalltalk refactoring browser was the first, most featured for years. Simple, expressive languages with good tools can be more effective than languages with more rules. So this argument without evidence sounds theoretically true, but there’s sufficient experienced in the field over decades to suggest it’s not necessarily true in practice.

                                                                                                                            I think the claim is roughly that the more expressive type system one has the more confidence the refactoring will be. FWIW, my experience in the industry has been that this is absolutely true. My career has almost entirely been refactoring existing code to make it a little less worse and the difficulty of the task is proportional to the power of the type system the language has that the refactoring is place in. Refactoring complex business logic in Python is absolutely miserable. I think the nature of refactoring is clearly on the side of static type systems and the only tools that make refactoring more palatable in a dynamically typed language are mimicking what one gets with a statically typed language.

                                                                                                                            1. 1

                                                                                                                              “One can do interactive programming in statically typed languages as well”

                                                                                                                              Agreed. My claim is not that one if clearly superior to the other. Rather my claim is that done well, both can be effective. The article seems to claim superiority but offers no evidence.

                                                                                                                              “statically typed languages will have the opportunity (through using lots of types) to make the problem visible closer to its introduction point.”

                                                                                                                              Again there is an appeal that this would be the case, but it seems there are ample proponents of both static and dynamic that claim a preference for one or the other. Seems based more on personal experience and preference than anything else.

                                                                                                                              “IME that discipline looks a lot like one would get “for free” from a statically typed language.”

                                                                                                                              Nominal checking of syntax is not necessarily free, nor sufficient. Incremental, dynamic, contract-based design and feedback (the hard part) is needed no matter what the implementation language. Again I’m not claiming superiority, rather lack of evidence beyond personal preference for one or the other.

                                                                                                                              “I think the claim is roughly that the more expressive type system one has the more confidence the refactoring will be”

                                                                                                                              I understand the claim in theory. The problem is the Smalltalk refactoring browser has been around longer than any other, and has for decades served as a counter example in widespread use.

                                                                                                                              “Refactoring complex business logic in Python is absolutely miserable”

                                                                                                                              I believe you. I’ve never seen any decent tools for Python.

                                                                                                                              “the only tools that make refactoring more palatable in a dynamically typed language are mimicking what one gets with a statically typed language.”

                                                                                                                              You’re incorrect. The Smalltalk refactoring browser embraces the nature of Smalltalk and pre-dates the implementation of refactoring tools for statically typed languages by many years.

                                                                                                                              1. 7

                                                                                                                                IME that discipline looks a lot like one would get “for free” from a statically typed language.

                                                                                                                                Nominal checking of syntax is not necessarily free, nor sufficient. Incremental, dynamic, contract-based design and feedback (the hard part) is needed no matter what the implementation language. Again I’m not claiming superiority, rather lack of evidence beyond personal preference for one or the other.

                                                                                                                                What does syntax checking have to do with this? Types provide proofs about your program and a checker for them, that is not syntax, that is semantics.

                                                                                                                                I think the claim is roughly that the more expressive type system one has the more confidence the refactoring will be

                                                                                                                                I understand the claim in theory. The problem is the Smalltalk refactoring browser has been around longer than any other, and has for decades served as a counter example in widespread use.

                                                                                                                                Perhaps Smalltalk is a counterexample but it’s quite hard to know. I just don’t see Smalltalk deployed to the millions of lines of code as the Python I’ve had to clean up. But I think you’re conflating a few things here. Even if the Smalltalk refactoring browser is great, types will still give you a more powerful tool to determine the correctness of a refactoring because Smalltalk simply can’t. It is the nature of types that gives this confidence. Smalltalk might be good enough and have other benefits but that is a separate argument.

                                                                                                                                But the real win, that it is unfortunate the link doesn’t go put as #1, is that that the semantics of any dynamic language can be represented in a statically typed language with a sufficiently powerful type system. C# has had a dynamic type for a long time and GHC has recently gotten one.

                                                                                                                                1. 0

                                                                                                                                  “Types provide proofs about your program and a checker for them, that is not syntax, that is semantics”

                                                                                                                                  By and large they are nominal or structural checks of self-consistency. Until you get into dependent types, the semantics are pretty limited. And it’s not clear yet where the cost/benefit is yet for dependent types vs. semi-formal runtime contacts.

                                                                                                                                  “I just don’t see Smalltalk deployed to the millions of lines of code as the Python I’ve had to clean up.”

                                                                                                                                  There’s s lot more Python then Smalltalk, but there are definitely millions of lines of good Smalltalk in production. I’m not here to defend the industry’s track record. Nor am I convinced that legions of bad Python programmers will suddenly create flawless typed FP programs any time soon.

                                                                                                                                  “types will still give you a more powerful tool to determine the correctness of a refactoring because Smalltalk simply can’t”

                                                                                                                                  Your bias is flying in the face of a reality that has been in practice for decades. I’m not intended to fight with people’s belief systems. I’m interested in evidence.

                                                                                                                                  “the semantics of any dynamic language can be represented in a statically typed language with a sufficiently powerful type system”

                                                                                                                                  Agreed, regarding the end result program. The experience of how a team effectively gets to the end result is different based on the language, the tools, and the team. It’s not enough to say that in the end the programs are the same.

                                                                                                                                  Anyway, not interested in high back and forth on this. I’ve been through it with you and others many times.

                                                                                                                                  1. 7

                                                                                                                                    By and large they are nominal or structural checks of self-consistency. Until you get into dependent types, the semantics are pretty limited. And it’s not clear yet where the cost/benefit is yet for dependent types vs. semi-formal runtime contacts.

                                                                                                                                    I’m not exactly sure what you mean here but correct-by-construction and whatever one’s equivalent of newtype is goes very far in helping with correctness. In this case, the constructor acts as a witness that something is correct and it travels around the program. Maybe that is limited but the impact is large.

                                                                                                                                    Your bias is flying in the face of a reality that has been in practice for decades. I’m not intended to fight with people’s belief systems. I’m interested in evidence.

                                                                                                                                    This isn’t a bias, it is a factual statement. The type checker will validate whatever the type system offers. Smalltalk does not have this. So the refactoring tool might be good enough for any programmer to use but it is less powerful than a type system in guaranteeing the correctness of a program.

                                                                                                                                    Thanks for the chat! It was a pleasure.

                                                                                                                                    1. 3

                                                                                                                                      This isn’t a bias, it is a factual statement. The type checker will validate whatever the type system offers. Smalltalk does not have this. So the refactoring tool might be good enough for any programmer to use but it is less powerful than a type system in guaranteeing the correctness of a program.

                                                                                                                                      I don’t disagree that this isn’t a fact, but it’s easy to see how Smalltalk’s refactoring tools might actually do the same kind of thing to make similar guarantees.

                                                                                                                                      There is a JavaScript code analysis system called ternjs, that can do automatic refactoring with confidence, and other truly impressive things. It works, partially, by building a type tree, but at each node there is a possibility of multiple types. I think this post describes the process as of a couple years ago. I am not at all sure how the Smalltalk’s stuff works, but I imagine it’s similar.

                                                                                                                                        1. 4

                                                                                                                                          Thanks!

                                                                                                                                          This looks pretty neat, but it does mention that it doesn’t strive to be automatic all the time. And it doesn’t really seem like it does anything all that special, really.

                                                                                                                                          Parse tree transformations, reflection, and dynamic analysis at runtime, via method wrappers. It also mentions that these capabilities are only as good as your test suite.

                                                                                                                                          While this is pretty much true of every sort of automatic fiddling of code, I can’t see how Smalltalk can make guarantees that are stronger, or even as strong as the refactoring tools @apy suggests. The dynamic analysis looks at actual values via method wrappers, but is there a guarantee that all possible program paths are executed and analyzed?

                                                                                                                                          1. 0

                                                                                                                                            Right, there is s difference between being effective and giving guarantees. It is effective in practice even though Smalltalk is a very simple and expressive language. But a languages like Smalltalk and use tools will no more guarantee success than will a static typed languages and tools. Badly designed systems can type check. That doesn’t make them easy to improve.

                                                                                                                                            1. 5

                                                                                                                                              Badly designed systems can type check. That doesn’t make them easy to improve.

                                                                                                                                              This is not the same argument, however. The claim is that a static type system lets one refactor with more confidence that the outcome is correct. A static type system will guarantee something about your program before you run it, and that something is dependent on how good your types are. A dynamically typed language will not guarantee anything. To reiterate: the refactor browser might be quite high quality and work well, but in terms of guarantees it can give the developer it is clearly less than what a statically typed language can offer.

                                                                                                                                2. 6

                                                                                                                                  “ but it seems there are ample proponents of both static and dynamic that claim a preference for one or the other. Seems based more on personal experience and preference than anything else.”

                                                                                                                                  It’s not a preference: it’s mathematically provable. Programming essentially produces a bunch of state machines interacting with various input and output patterns. Certain patterns or states are a problem. You can detect these at compile time or runtime. You can detect these with analysis or testing. The difficulty of the runtime and testing approaches go up dramatically when complexity increases until they quickly reach combinatorial explosion. Analysis approaches constrain the expression of the program in a way that catches chunks of them before it’s even run (static analysis), spots others quickly with less tests (dynamic analysis), often applies to all executions rather than just test cases you thought of, and with hopefully less work as types & specs become second nature. These checks range in power and complexity as you go up from basic types to interface types to dependent types to whatever else they come up with. And in tooling from basic type checker to static analysis to provers.

                                                                                                                                  Yet, most published evidence in the literature of software verification… academic, commercial, and FOSS… shows stronger guarantees of correctness for more inputs and outputs done in the constrained, static languages. Also easier compiler optimization. There is research and existing tooling on doing such things for dynamic languages. The ones I’ve seen are much more complex and expensive in analysis than, say, Oberon or Design-by-Contract. One day, they might have methods to equal static typing in ease of analysis or correctness. So far, the evidence is against that.

                                                                                                                                  “The problem is the Smalltalk refactoring browser has been around longer than any other”

                                                                                                                                  Smalltalk is an interesting case. It’s exceptional in quite a few ways. The reason it’s easy to do refactoring in Smalltalk is that it’s designed to put stuff like that at a higher priority. Things like dynamic types, extreme decomposition with message passing, reflection, and a runtime for bytecode add up to make it easier. What it traded off was high performance, ease of implementation of compiler, and provable correctness or properties of apps and compiler given it’s more difficult to analyze apps made this way. Languages wanting those + refactoring will likely be statically typed since it’s just easier to build the tooling. That’s the path Eiffel took with better, overall results.

                                                                                                                                  https://en.wikipedia.org/wiki/Eiffel_(programming_language)

                                                                                                                                  Although, Smalltalk probably still has it beat on rapid prototyping and refactoring. My guess. :)

                                                                                                                                  1. 2

                                                                                                                                    “It’s not a preference: it’s mathematically provable.”

                                                                                                                                    A type system can be proven logically. That is a long way from proving an application will be built more effectively (time, budget, quality, features) in practice.

                                                                                                                                    “Certain patterns or states are a problem. You can detect these at compile time or runtime. You can detect these with analysis or testing. The difficulty of the runtime and testing approaches go up dramatically when complexity increases”

                                                                                                                                    This seems to assume there are two ways to solve the problem, type system X or ad hoc. In fact I’ve developed state machine generators and interpreters in Smalltalk and Lisp for things such as multiuser collaborative systems and manufacturing planning.

                                                                                                                                    “There is research and existing tooling on doing such things for dynamic languages. The ones I’ve seen are much more complex”

                                                                                                                                    Complexity is not a stranger to much of the software world. Unfortunately. Typed or not.

                                                                                                                                    As a counter example to your experience, see ObjecTime. A tool for designing realtime, distributed, communicating actors and state machines. Written using Smalltalk, it also supported C, C++, etc. It was eating IBM’s lunch in the realtime market in the day, so IBM bought the company.

                                                                                                                                    https://drive.google.com/file/d/0B0cKsRm-3yprYlJyeTI0dTduTGc/view?usp=drivesdk

                                                                                                                                    “Smalltalk is an interesting case. It’s exceptional in quite a few ways”

                                                                                                                                    Funny that type system proponents tend to position state of the art type systems in theory against average teams with bad dynamic languages such as Python in the field. Bad teams will used good languages poorly, period.

                                                                                                                                    “The reason it’s easy to do refactoring in Smalltalk is that it’s designed to put stuff like that at a higher priority”

                                                                                                                                    Exactly. I’m arguing the best in dynamic language systems and the best in typed languages can be equally effective, and there’s little evidence to show otherwise.

                                                                                                                                    “That’s the path Eiffel took with better, overall results.”

                                                                                                                                    Eiffel was a nice system. It’s arguable about better overall results.

                                                                                                                                    “Smalltalk probably still has it beat on rapid prototyping and refactoring. My guess. :)”

                                                                                                                                    Yes, I don’t recall Eiffel ever having any refactoring or even a good interactive development environment.

                                                                                                                                    1. 5

                                                                                                                                      “A type system can be proven logically. That is a long way from proving an application will be built more effectively (time, budget, quality, features) in practice.”

                                                                                                                                      The published studies in industry always showed the strongly-typed languages with interface checks improved quality and reduced debugging time for modules and integrations. Formal methods did as well. There’s time and quality. The lightweight methods, esp strong typing + design-by-contract, didn’t have significant impact on labor for basic annotations but reduced it for debugging. So, there’s budget. Features require ability to extend or modify the program rapidly and with minimal breakage. Strong, dynamic typing dominates on speed of development with most correctness of new features coming from those using strong, static typing or analysis. So, that’s the field results survying defect rates and such.

                                                                                                                                      I don’t have that many empirical studies on strong, dynamic language’s ability to do affordable development plus prove absence of entire classes of errors. If you have them, I’d appreciate teh the links for further evaluation.

                                                                                                                                      “This seems to assume there are two ways to solve the problem, type system X or ad hoc. In fact I’ve developed state machine generators and interpreters in Smalltalk and Lisp for things such as multiuser collaborative systems and manufacturing planning.”

                                                                                                                                      I’m sure you have. People did in assembly, too. The point of the strong, static types is to ensure guarantees across the software no matter what people are doing with it. So long as the code is type-safe. This can be used to knock out entire classes of problems with no extra work on the developer. You have to manually check for those if its dynamic. Many developers won’t, though, so the baseline will suck in those areas. Hence, standardizing on type systems that force a better baseline.

                                                                                                                                      “This seems to assume there are two ways to solve the problem, type system X or ad hoc. In fact I’ve developed state machine generators and interpreters in Smalltalk and Lisp for things such as multiuser collaborative systems and manufacturing planning.”

                                                                                                                                      Looks neat. We’ve been talking about what one can do with a static or dynamically-typed language. You just introduced a CASE tool whose DSL…

                                                                                                                                      https://www.eclipse.org/etrice/

                                                                                                                                      …looks like a statically-typed language that gets transformed into necessary Smalltalk, etc that gets the job done combined with a runtime. I’m not sure how a CASE tool w/ a static language replacing your dynamic language for model-driven development supports your point thats that (a) dynamic language users have comparable benefits with the language or (b) that statically-typed languages/tools aren’t needed. I could’ve easily linked Ensemble’s protocol composition, Verdi correct-by-construction generators for protocols, numerous works in Coq/HoL that genere real-time software, Atom specification language in Haskell, or Hamilton et al’s 001 toolkit that generated whole systems from static, logical specs w/ OOP and timing info. Tons of third party tools that use DSL’s or MDD for more robust software all written in arbitrary stuff. It might be indicative of something that the most robust ones are done with statically-typed languages. Those using dynamic usually just do thorough testing at best.

                                                                                                                                      “Bad teams will used good languages poorly, period.”

                                                                                                                                      The original studies on quality by Mitre, DOD, SEI, etc compared professionals on various projects using languages like assembly, Fortran, C, C++, Ada, and Java. The last three, due to typing/safety, consistently had more productivity and lower defects than the others. Ada always had least defects due to strongest typing except one study I saw where C++ and Ada projects matched. Anomaly. Also, one of earliest, correct-by-construction approaches that got tested was Cleanroom. People hit very low defect rates on the first try while remaining productive and flexible. The main way it did it was constraining how programs were expressed for easy composition and verification. Like static typing and analysis.

                                                                                                                                      What bad teams do is a strawman I’ve never relied on promoting software, assurance methods. The results of pro’s who got more done told me what I needed to know. The consistent lack of anything similarly achieved on other side outside some verified LISP’s told me some more. This forms a status quo. It’s dynamic side that need to prove themselves with bulletproof code with proofs of properties and/or empirical studies against good, static toolchains.

                                                                                                                                      “I’m arguing the best in dynamic language systems and the best in typed languages can be equally effective, and there’s little evidence to show otherwise.”

                                                                                                                                      Show me an ultra-efficient, dynamic-language, imperative application or component that’s been verified down to assembly to be correct and terminate properly. There’s a bunch of them for strong, statically-typed imperative and a few for functional with caveats. Bring on the evidence that dynamic languages are achieving just as much with proof it works + testing rather than just some testing where it appears to work.

                                                                                                                                      1. 1

                                                                                                                                        The published studies in industry always showed the strongly-typed languages with interface checks improved quality and reduced debugging time for modules and integrations.

                                                                                                                                        I’m always interested in reading good studies if you have 2-3 at hand.

                                                                                                                                        Formal methods did as well.

                                                                                                                                        Of course formal methods can be and have been used in conjunction with dynamic languages.

                                                                                                                                        The lightweight methods, esp strong typing + design-by-contract, didn’t have significant impact on labor for basic annotations but reduced it for debugging. So, there’s budget.

                                                                                                                                        I’d really like to read these studies, especially if they considered lightweight methods, esp. DbC, along with a high-quality dynamic language that has good tool support such as Lisp or Smalltalk.

                                                                                                                                        I don’t have that many empirical studies on strong, dynamic language’s ability to do affordable development plus prove absence of entire classes of errors. If you have them, I’d appreciate the the links for further evaluation.

                                                                                                                                        Here’s at least one study in the following link that puts Smalltalk ahead of Ada, C++, C, PL/I, Pascal, etc. on a significant sized project.

                                                                                                                                        https://drive.google.com/file/d/0B0cKsRm-3yprYTR5YTRaRFBfR28/view?usp=sharing

                                                                                                                                        This can be used to knock out entire classes of problems with no extra work on the developer. You have to manually check for those if its dynamic.

                                                                                                                                        Many of those kinds of problems are covered by tests that would be needed in either case. Some of those kinds of problems can be addressed through tools and metaprogramming, even optional type systems, e.g. Strongtalk. I’ve used that same optional type system a fair bit with Dart.

                                                                                                                                        Many developers won’t, though, so the baseline will suck in those areas. Hence, standardizing on type systems that force a better baseline.

                                                                                                                                        I have doubts that a good type system will make good programmers out of bad ones, just as OOP and dynamic typed FP has not. Bad programs can be type checked.

                                                                                                                                        https://www.eclipse.org/etrice/ …looks like a statically-typed language…

                                                                                                                                        That’s a second, later implementation of the same ROOM methodology. ObjecTime is decades older, implemented in Smalltalk-80.

                                                                                                                                        Show me an ultra-efficient, dynamic-language, imperative application or component that’s been verified down to assembly to be correct and terminate properly.

                                                                                                                                        The closest I can think of off the top of my head is https://en.wikipedia.org/wiki/ACL2

                                                                                                                                        But that’s not really my point. I’m not arguing dynamic languages are the best choice in all cases, but that they can be at least as good of a choice in most cases. Very few software systems need this level of verification. In fact most software systems are more concerned with discovering what the spec should be, and achieving an economical, maintainable implementation of a semi-formal specification.

                                                                                                                                        1. 3

                                                                                                                                          There is a great review of empirical studies of programming here: http://danluu.com/empirical-pl/

                                                                                                                                          1. 2

                                                                                                                                            Appreciate the list. Many of the studies have problems but there’s good information in the overall collection.

                                                                                                                                          2. 3

                                                                                                                                            “I’m always interested in reading good studies if you have 2-3 at hand.”

                                                                                                                                            I just reinstalled my system due to a crash a few days ago. I’m still getting it organized. Maybe I’ll have the links in a future discussion. Meanwhile, I found quite a few of them Googling terms like defects, Ada, study, programming languages, comparison. Definitely include Ada, Ocaml, Haskell, ATS, or Rust given they use real power of strong, static typing. C, Java, etc do not. It’s mostly just a burden on developers that assists the compiler in those languages. It’s why study results rarely find a benefit: they’re not that beneficial. ;)

                                                                                                                                            Thomas Leonard’s study of trying to rewrite his tool in many languages is actually illustrative of some of the benefits of static typing. He was a Python programmer who ended up on Ocaml due to type system’s benefits plus performance gain. On the page below, in Type Checking, he gives many examples of where the static typing caught problems he’d have had to think up a unit test for in Python:

                                                                                                                                            http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/

                                                                                                                                            He doesn’t even have to think about these in the static language. Just define his stuff in a typical way allowed by the language. It knocks out all kinds of problems invisibly from there. That he was an amateur following basic tutorials without much due diligence, but still got the results, supports benefit the static types had. The ML’s also are close to dynamic languages in length due to type inference and syntactic sugar.

                                                                                                                                            “Here’s at least one study in the following link that puts Smalltalk ahead of Ada, C++, C, PL/I, Pascal, etc. on a significant sized project.”

                                                                                                                                            It actually doesn’t since it leaves off data on defect introduction, time for removal, and residual ones. Basically measures speed without quality. In those studies, including some on stijlist’s link, the LISPers have larger productivity boost over C++ than Smalltalk does here. I ignore LISP over strong, static types for same reason: few comparisons on defect introduction & removal during development or maintenance. The studies I saw on Ada showed it way ahead of other 3GL’s on that. Dynamic languages usually weren’t in the defect comparisons of the time, though.

                                                                                                                                            In yours, the Smalltalk program gets developed the fastest (expected) with unknown quality. The Ada95 program… whose compiler catches all kinds of algorithmic and interface errors by default… cost 75.17 person-months over Smalltalk but 24.1 faster than C++. So, it looks good in this study compared to flagship imperative and dynamic languages of the time given it’s a straight-jacket language. Smalltalk’s design advantages mean Ada can’t ever catch up in productivity. Logical next step is redoing the same thing with modern Smalltalk and Ocaml (or something similar). As link above shows, Ocaml has strong-typing with benefits close to Ada but conciseness and productivity more like Python. That would be a nice test against Smalltalk. Actually, the better tooling means Ocaml would be handicapped against Smalltalk. So, maybe not as nice a test but any comparable or winning result on Ocaml’s side would mean more if handicapped, eh?

                                                                                                                                            “Many of those kinds of problems are covered by tests that would be needed in either case. ”

                                                                                                                                            You don’t need the test if the type system eliminates the possibility of it ever happening. Java programmers aren’t testing memory safety constantly. Modula-3 programmers didn’t worry about array, stack, function type, or linker errors. Rust programs that compile with linear types don’t have dangling pointers. Eiffel and Rust are immune to data races. Yeah, go test out those faster than Eiffel programmers prevent them. ;) Annotation method in Design-by-Contract documents requirements in code, catches obvious errors at compile time quickly, supports static analyzers, and can be used to generate unit tests that provably test specs. As code piles up, the kinds of things you have to test go down vs dynamic stuff where you have to hand test about everything. Good annotations, which cover every case in a range, mean the large programs of 100,000+ lines simply can’t compile with the interface errors. Imagine… although you’ve probably done it… trying to code up tests representing every way a behemoth’s software might interact incorrectly plus the runtime they impose after each change.

                                                                                                                                            So, part of the argument is reducing maintenance by balancing QA requirements across static types, annotations, static analysis, and tests. Ensure each property holds by using whichever of them is easiest to do, maintain, and apply to maximum number of execution traces or states.

                                                                                                                                            “I have doubts that a good type system will make good programmers out of bad ones, just as OOP and dynamic typed FP has not. Bad programs can be type checked.”

                                                                                                                                            I’m sure the average Rust programmer will tell you a different story about how many memory errors they experience vs coding in C. They don’t test for them: it’s simply impossible to compile code that has them in safe mode. Same with SafeD and SafeHaskell. Common cases in Ada and the Wirth languages also have checks inserted automatically. If it’s common and should fail-safe, you shouldn’t have to think about it. Pointers, arrays, strings, function arguments, handles for OS resources, proper linking… these things come to mind. Strong, static typing lets you just use them correctly without thinking past the initial definitions. No need to even write tests for that.

                                                                                                                                            “That’s a second, later implementation of the same ROOM methodology. ObjecTime is decades older, implemented in Smalltalk-80.”

                                                                                                                                            I know. My point didn’t change. You supported what Smalltalk can do by using a 3rd party tool whose DSL (ROOM) uses static, strong types that drive the checking and code generation process. The tool supports my argument. Imagine if it let you assign to various variables interfaces, ports, states, and so on without checking or labeling them. I imagine correctness would involve more thought by developers than the constrained process I saw that prevented classes of problems by design through variable types and enforced structuring. Did the ObjectTime not have labels representing types, restrictions on what variables could contain, and similar structure to force sane expression of FSM’s, etc?

                                                                                                                                            “The closest I can think of off the top of my head is ACL2”

                                                                                                                                            I knew you’d go for that. I made same mistake on Hacker News where ACL2 users grilled me. They pointed out that, despite starting with LISP, ACL2 is a heavily constrained version of it because dynamic LISP couldn’t be verified so easily. Further, if you check docs, you’ll see it has all kinds of static types that are used during development. Leave them off and it won’t do much for you at all. Hard to classify ACL2 but it’s more like a statically-typed LISP than a dynamic one. .

                                                                                                                                            “but that they can be at least as good of a choice in most cases. Very few software systems need this level of verification.”

                                                                                                                                            I agree that they can be used and used well. I disagree on the last part given the Github issues and CVE’s indicate the average app needs better built-in support for correct applications. The weak, static languages and dynamic ones seem to catch fewer problems in small and large apps. This results in much time wasted figuring out why or residual defects because they don’t want to invest time in figuring it out. So, even average developer needs a good baseline in their language and tooling. Code away in the dynamic languages if you want but strong, static ones catch more problems you’ll run into. If you’re disciplined and experienced, you might prevent the same ones with you’re strategies of testing and designing safer constructions. Evidence indicates most won’t go that far, though, due to less discipline or experience. Plus, different, average developers rolling their own way of doing basic checks instead of built-in often leads to nightmares in debugging or integrations.

                                                                                                                                            1. 2

                                                                                                                                              OCaml is a nice language. The problem with that anecdote is it compares a really good static typed language (OCaml) with a really bad dynamic language (Python).

                                                                                                                                              [The study I cited] “Basically measures speed without quality.”

                                                                                                                                              True there are no clear citations of defects. But you are reading into that differently than I am. My assumption is if a language is cited as implementing a function point in N time units then that implies the function point is correct as implemented in that time. What would be the point of stating a function point was implemented in N time units but full of bugs? I would give the study the benefit of the doubt but admit the gap. These kinds of studies are always full of questions, which is why I’m interested in any you have available.

                                                                                                                                              “ACL2 is a heavily constrained version of it because dynamic LISP couldn’t be verified so easily.”

                                                                                                                                              Well, right, because one approach is to add some static tools above a dynamic language. If the argument was Lisp or Smalltalk could statically check exactly as OCaml does then you’d be right. But if the argument is there are large categories of applications where simple dynamic languages can be augmented with certain practices and tools, including some optional static checking to great effect, then you’d not be right.

                                                                                                                                              “You supported what Smalltalk can do by using a 3rd party tool whose DSL (ROOM) uses static, strong types that drive the checking and code generation process.”

                                                                                                                                              You are continuing to refer to a specific, second implementation of ROOM that has nothing to do with the original implementation. The original implementation does not use that DSL. The implementation of ObjecTime is almost entirely in Smalltalk. The executable models consist of those built by the tool structurally (graphically) augmented by code written in “any supported” programming language… almost always C but also C++ or Smalltalk.

                                                                                                                                              “I disagree on the last part given the Github issues and CVE’s indicate the average app needs better built-in support for correct applications.”

                                                                                                                                              I for one certainly do not care a zip about the average GitHub project. And I would remain skeptical that OCaml or Haskell or Idris or whatever may come along in the next 10 years would do much of anything for the average GitHub project. A type checked mess is still a mess.

                                                                                                                                              “Logical next step is redoing the same thing with modern Smalltalk and Ocaml (or something similar).”

                                                                                                                                              I agree. As I wrote above, I like OCaml, and would certainly not be unhappy if it turned out to be the best choice for some project I participated in. If you read everything I’ve written under this headline artical, I’ve never claimed the superiority of a dynamic language over a static typed language. I’ve suggested the evidence does not clearly favor one over the other. Good simple languages appeal to me. I’ve used Smalltalk and Lisp a lot and know they fit the bill for the kinds of systems I’ve worked on for 35 years. I’ve done enough OCaml and other ML’s to suspect they largely would meet my needs. Haskell’s another story, personally. I used Haskell 98-era a good bit, but I’m just not interested in the last 10+ years of what’s been going on there.

                                                                                                                                              I appreciate what you are saying about Ada, OCaml, etc. and the benefits of static typing. I am disagreeing with how you are positioning dynamic languages requiring more effort to test, etc. due to lack of type checking. I’ve just not experienced that, but I understand a lot of people have not had the same experiences I’ve had with good languages, tools, and practices. But neither am I convinced those same programmers will end up with significantly better programming effectiveness in a good static language. You think they will, I think they won’t. I’m not sure we’re going to resolve those differences, or need to.

                                                                                                                                              1. 2

                                                                                                                                                I appreciate you clarifying your points. I think its time to tie this one up. Your comments, including the last one, have helped me plenty in understanding how we might better assess the dynamic vs static typing in future studies. I’ll also lean more on Smalltalk and its professional practices in future research for comparisons. The proper comparison will be best practices of it vs something like Ocaml plus considerations for what work static analysis, formal verification, etc required with what results.

                                                                                                                                                Enjoy the rest of your day! :)

                                                                                                                                3. 3

                                                                                                                                  Dynamic languages do not have a compile stage.

                                                                                                                                  This is a major pet peeve of mine; it really bugs me that anyone still believes there is any relation between a language’s type system and whether a language is compiled or interpreted. Can’t we be done with this tired misinformation?

                                                                                                                                  1. 2

                                                                                                                                    Fine. It’s a terminology thing. I misspoke. Clearly statically checked languages have a stage where checks are made prior to running the program. That’s what I meant. I started programming in Lisp in the early 1980s and Smalltalk in 1986. I’m fully aware dynamic vs static has nothing to do with compiler or interpreter.

                                                                                                                                  2. 2

                                                                                                                                    Some dynamic languages have very good tools that programmers in some static languages would envy.

                                                                                                                                    Could you provide some examples?

                                                                                                                                    1. 2

                                                                                                                                      One example, re: semi-formal tools + simple languages vs more complex languages and types… Smalltalk has the best “lint” tool I’ve seen. Combined with other tools and practices, this will go a long, inexpensive way to keeping code clean and well designed (which then makes testing, refactoring, etc. much easier.) The equivalent in a static typed languages would be a kind of “type advisor” which I think would carry those languages a good way into the mainstream.

                                                                                                                                      1. 1

                                                                                                                                        Thanks. I’m especially curious about refactoring. Are you aware of any video showing how to rename a function and add a parameter to a function signature in Smalltalk?

                                                                                                                                        1. 1

                                                                                                                                          “Two Decades of the Refactoring Browser” https://youtu.be/39FAoxtmW_s

                                                                                                                                      2. 1

                                                                                                                                        Dialyzer for Erlang also comes to mind. It catches a lot of bugs that many simplistic static type systems (like Java or Google Go) have no chance at.