1. 33

  2. 14

    I find that I treat programming languages the same way. If it compiles and runs quickly without eating up resources, I feel like the language is higher quality. It’s why I keep coming back to C and Lua despite their many issues. It’s why I can never get into Haskell or Rust despite agreeing with many of the design decisions.

    1. 5

      Guess then you should give OCaml a try, for a language pretty similar to Haskell overall and the one that has inspired Rust and compiling fast with low overhead.

      1. 3

        I would likely be still using OCaml if the compiler was slower (good incremental compilation support makes it much less of an issue anyway), but it’s one of the things keeping me there for sure.

        If it can compile itself under 10 minutes using a single CPU, the only question about beta compilers and experimental variants is whether I want to try it or not, and opam makes it dead simple to keep multiple versions on the same machine.

        1. 1

          If you’re on the .net platform, F# is a nice sister language to OCaml. Frequently valid OCaml is valid F#.

          1. 3

            Nothing against F#, if I find myself using .Net, I’ll sure go for it. However, I find the decision to remove modules really strange.

            OCaml’s object system clearly had to be removed for interoperability with other CLR languages. I suppose the reason to drop decidable type inference was the same. But why remove the second most important feature of ML? :)

            1. 1

              For the most part we have clr friendly ways of doing the same thing already through generics and SRTP. There is a long term community goal of supporting them however the need is less strong due to the current clr approaches. So it falls on the back burner. To be precise we do have modules, they just aren’t parameterized modules, which is I presume what you’re referring to. Yeah for many OCaml natives, it’s use it if you’re in .NET :) I wouldn’t blame you for sticking with OCaml outside of it.

              1. 1

                If I remember correctly, F# has no signatures and structures in the usual ML sense, not just functors. If I’m behind the times, that’s great.

                Also, is there a GUI builder that targets F# in VisualStudio or elsewhere now?

                1. 1

                  We have signatures but they go in a signature file, inline signatures are the subject of many years of debate that you’re free to join :). As I understand it structures are sidestepped in how we do things a little differently, I don’t know if you’ll enjoy it but it is comfortable for us.

                  As for GUI builder, most people don’t use wsiwyg but there’s strategies for making GUI apps for android, ios, apple, windows, and linux, as well as a way to do F# to Javascript and react/preact based approach for building web-ui. The popular approach for most of these is to use an “elm-like” library. The space is maturing and is very usable but of course isn’t going to be as feature rich as something like C#.

                  1. 1

                    Signatures are there in the form of .fsi interface files but I don’t think I’ve ever used them over the C#y class system.

                    Modules are basically static classes that are presented as namespaces you can put let bindings in. They’re lexically extensible, which is neat (i.e. you can add a new function to the List module by defining a new module called List and putting it in there). It sometimes confuses VS though.

          2. 2

            Sincere question: what’s the advantage of OCaml over Haskell and Rust? (I do Haskell.)

            As far as I am concerned, OCaml isn’t faster than any of those at runtime (e.g., OCaml vs. Haskell) but has the advantage (at certain perspectives) of strict evaluation.

            Is it compilation time? Memory footprint? Or is it even faster in runtime?

            1. 3

              I think I wouldn’t really put Rust and Haskell/OCaml in the same niche since Rust is useful where you have to avoid GC for reasons of limited memory or consistent reaction times but otherwise I would about always choose Haskell.

              OCamls advantage is that it compiles very fast and runs pretty fast often without having to spend much time for optimizations. I heard anecdotal experience that the performance of Haskell code tends to be hard to estimate and hunting for space-leaks time consuming. The OCaml on the other hand is rather simple and predictable in what code it will generate, which is why it is even possible to write allocation-free loops. OCaml used to be written more imperatively but over time has evolved into a more Haskell-ish way of writing (but without the operator forest).

              So yeah, if you’re already happily using Haskell then there is not much reason to switch, similarly the other way. But if you come from e.g. C, Lua or Python there are a lot of benefits.

        2. 7

          Just as an additional example, I switched to using JetBrains IntelliJ IDEA a few years ago and was happily working in that application for a few years for a variety of languages and project types. But it got to the point where typing was just painful. On a fairly high end desktop at the time, my typing would lag and I could watch the cursor try and catch up. It drove me insane, I tried all the recommended tweaks and changes, but ultimately I abandoned IntelliJ and went back to vim and haven’t gone back since. I was willing to give up all the bells and whistles of IntelliJ, the project view, refactor tools, debugger, etc… purely because the typing was just so bad, it just couldn’t keep up with my typing speed at all even with a minimal footprint of plugins installed. Maybe they’ve since fixed it, but it was frustrating enough that I haven’t really gone back to check.

          1. 3

            I use CLion every day for $WORK. It doesn’t get in the way of typing much. When I’m on the go, I put power save mode, which disables all of the semantic analysis that can eat battery.

            I prefer lighter weight editors for projects at lower levels of complexity. There, I tend to build by writing some code, running it, and tweaking. As projects grow larger, so do your needs, and integrating things like type checking, linting, and automated refactoring start to become worth something. A specific example: I often don’t discover the real name of a module until some time after I’ve implemented a majority of it. However, you usually need to specify said name at least once, if not multiple times (file name). So, it imposes a cost to choosing said name, and makes it more onerous to change it. Having a tool do that for you safely and quickly is a great asset to evolving a codebase.

            There definitely isn’t a perfect editor. Whenever I use vim, I want more semantic information available. Whenever I use an IDE, I wish they prioritized the typing experience to the same extent that vim does.

            1. 1

              That’s a good point about the power-saving mode actually, I might try that if I come back to IntelliJ again at some point.

              In the cases where I got fed up it was a fairly sizeable monorepo python/react application and I just found it easier (for me) to use tmux and vim at a given point. I started to feel like the IDE was getting in my way a lot and I was under such severe time crunches that the typing lag was getting to the point at times where I wanted to throw a keyboard. For instance, debugging something, finding the issue, quickly swapping to the editor, typing to fix… wait for typing to catch up, ah type, backspace lag, fix, restart debugger. It was a loop where the editor was dragging me down quite badly and it was getting really frustrating.

              I have a variety of ways that I get around the lack of the features in the IDE and in some cases I just realized I didn’t need something I was using, I mostly use command-line utilities and debuggers, etc…

              Also it’s worth noting that this was in IntelliJ IDEA with the python plugin loaded into it and the nodejs/javascript plugins loaded into it and most Java stuff unloaded. So it may have been that IDEA had a hard time running as basically PyCharm and WebStorm at the same time.

              I honestly have nothing against the IDEs either, I loved using them and I use DataGrip religiously, it was literall just down to typing lag and the frustration it was causing that got me.

            2. 1

              I’ve heard the same thing from other folks who’ve used it in the past. I’ve been using CLion and other IDEs for the last two years with no issues. It’ll eat processor time when it’s indexing a project for the first time though.

              1. 1

                I could handle the indexing, that was sort of inevitable for an IDE that does the fairly advanced things it does, but the indexing was predictable to an extent. You could sit there and go “well I’m going to go make a coffee while this runs”. It’s worth saying I didn’t get the typing lag as much (or at all) in the individual IDEs like CLion, PyCharm and DataGrip, it was mainly in IntelliJ with support plugins installed when I was working on a large monorepo project with multiple build configs, etc… I also found myself hopping to other editors a lot or to vim for quick edits and then just one day I went to edit something with vim, and just, didn’t go back to intellij.

            3. 3

              This is a pretty haphazard essay as far as they come, but I’m still saving it for capturing into words something I already believed, but had not found a way to describe.

              1. 3

                Wasn’t aware that there is a nice and fast client for Simplenote, I am definitely trying nvALT for my notetaking.