Threads for roxma

  1. 5

    I still use vim because it doesn’t spam dropdowns and auto completions at me, bouncing around like a puppy on crack, while still letting me enter text efficiently.

    Performance is nice, but it’s a bonus over the editor just letting me type.

    1. 2

      I still use vim because it doesn’t spam dropdowns and auto completions at me, bouncing around like a puppy on crack, while still letting me enter text efficiently.

      What if the auto completions are useful, and make you more productive than without them?

      What if the completions would also reduce the need for bouncing around your code like a puppy on crack, looking for the name of a variable or function you’re supposed to use?

      1. 5

        What if the auto completions are useful, and make you more productive than without them?

        If you feel that way, you can use them. Please don’t tell me what I find distracting.

        Dropdowns and bounciness are available in vim too, if you like things to work that way. YouCompleteMe is an example of it. But I can’t stand using it. Maybe one day I’ll hook it into the quickfix window, where the suggestions and documentation stay nice and static.

        1. 0

          Please don’t tell me what I find distracting.

          I didn’t.

          I suggested that auto-completions might make you more productive than without them, which would actually probably be the case.

          Whenever people vehemently defend their choices of sticking with Vim or Emacs despite the fact that JetBrains has been producing IDEs for a long time, I suspect it’s because they have trouble entertaining the notion that their choices might be “wrong”.

          I mean, you’re not harming anyone else by using Vim, but you’re probably accumulating a vast mound of opportunity costs that could be avoided by adopting an IDE.

          You might even be aware of it subconsciously, considering the “hostile” way you characterized auto-completions.

          Granted, you may genuinely be a special snowflake that finds them unbearably distracting, but it’s just not very likely, and sounds like a rationalization for acting against your self-interest by continuing to accumulate those opportunity costs.

          1. 7

            Whenever people vehemently defend their choices of sticking with Vim or Emacs despite the fact that JetBrains has been producing IDEs for a long time, I suspect it’s because they have trouble entertaining the notion that their choices might be “wrong”.

            I spent the last 6 months in a jetbrains ide. It sucked. I’ve tried setting up the ide-like popups and completions in vim. It sucked. The hostility is from experience. But thanks for the smug condescension.

            1. -1

              But thanks for the smug condescension.

              You’re welcome :)

            2. 2

              I’m sure this can vary by field (I’m a CS academic, not a full-time programmer), but I’ve personally never found any of this tooling choice to make a meaningful difference to long-term productivity one way or another, as long as you pick something vaguely sorta working. That depends far more on other features, like coming up with good ideas on paper first, keeping motivated, even getting a good night’s sleep. So I choose programming environments mostly by whether I subjectively enjoy working in them. Given that I spend a decent portion of my life working in them, I think it’s reasonable for this to be a primary concern—life is too short to be primarily worried about “productivity”, anyway.

              At least when I have a choice of course. When I program iOS apps I use XCode, even though I don’t think it’s either a very good text editor or very good IDE, because doing anything else is an uphill fight against Apple.

              1. 0

                I’ve personally never found any of this tooling choice to make a meaningful difference to long-term productivity one way or another, as long as you pick something vaguely sorta working

                Even if the differences in productivity between various tools are small, they compound over time. That’s certainly meaningful.

                If you save 10 minutes per day, that adds up to around 60 hours per year. That’s a significant chunk of the working hours in a month, for example.

        2. 1

          Why not try an auto completion plugin with popup delay option? You won’t get distracted unless you stop the cursor at the midle of a word.

        1. 4

          I get using vim on machines were Neovim is not installed, same way I use vi when vim is not installed. But why switch between the two on your personal machine?

          No-Config neovim works preetty much the same as vim, except with better defaults.

          1. 4

            Neovim doesn’t have :smile.

            1. 1

              I switched to neovim before vim8 came out, mostly due to async support.

              And after a while I ended up with building an async code completion plugin - nvim-completion-manager

            1. 3

              Dont really have the time to try this out untill the next few days, but I’m interested in seeing how well it fares against Deoplete. Especially in terms of completion source support, as I’ve found deopletes speed to be more than enough.

              1. 1

                It should be easier to install NCM than you thought.

                Code completion source support is way fewer than deoplete’s. Since I have very limited tmie, I might consider simply support some of deoplete’s sources.

              1. 3

                The title is slightly misleading - it supports Vim 8.x and later too: …

                Requirements

                Neovim.

                Or vim8 with has(“python”) or has(“python3”)

                I’m still using Vim as I haven’t found a Neovim GUI that quite matches MacVim (sad, I know).

                1. 2

                  Yep.

                  It works on vim8 via vim-hug-neovim-rpc. But vim8 support is still experimental, sice the compatible layer vim-hug-neovmi-rpc is not mature.

                  1. 1

                    Have you tried VimR?

                  1. 2

                    See also: deoplete.

                    1. 2

                      There’s a why section at README.md explaining some differences between deoplete and this plugin.

                    1. 1

                      Seemless is “not proper or appropriate for the situation : not seemly”, Seamless I think is probably the word you were looking for?

                      1. 1

                        how about decent?

                      1. 17

                        if err != nil { gets old even faster.

                        I just started using Go recently and really find this to be annoying.

                        1. 6

                          I remember reading (on the Go blog maybe?) about doing a small “assert” function for things that can fail (like command line utilities), it’s been one of my favorites since then:

                          func assert(err error) {
                              if err != nil {
                                  log.Fatalf("Fatal error: %s\n", err.Error()) //or panic(err) if you want the debug info
                              }
                          }
                          

                          then you can just do something like:

                          func readConfig(path string) (cfg Config) {
                              file, err := os.Open(path)
                              assert(err)
                          
                              err = json.NewDecoder(file).Decode(&cfg)
                              assert(err)
                          }
                          

                          Of course, if you’re doing web services or any sort of daemon you’d want to handle errors gracefully, without having them kill your app (unless you’re doing startup)

                          1. 4

                            I felt the same way for a while but eventually you get over it. There are other things that in other languages would take a lot to express but are short in Go (e.g., interface behavior).

                            1. 4

                              Personally I prefer this feture than exception, it’s more explicit than exception, and not that cubersome. Exceptions always make me worried that there may be some unhandled mess deep down the function call so I have to wrap the call with try catch block and finally it indents the main logic futher and gets ugly.

                              EDIT: Besides, It’s extremely terrible to mix return error and throw exception in the same application, which is very common if you use different libraries with different error handling styles, while golang makes it consistent.

                              1. 7

                                Personally I prefer this feture than exception, it’s more explicit than exception, and not that cubersome.

                                But it’s not a binary choice of nullable error types versus exceptions. Sum types solve this problem quite elegantly, especially combined with some facilities to ‘unwrap’ instances of such types safely (e.g. try! in Rust or the Maybe/Either monads in Haskell).

                              2. 5

                                A lot of Go’s features are slick, but this error handling is indeed pretty ugly. I wonder what the underlying reasons were for them to implement it like this.

                                1. 19

                                  Explicit over magic.

                                  1. 5

                                    This, so much this.

                                    It’s ugly, but it’s clean enough that I miss it when working with other languages. I always find myself having to deal with C++ functions that might throw exceptions, PHP functions that either use exceptions or have their own get_last_error() function. Haskell which has just about a bajillion ways to do errors (and this 15 pages guide only covers some of them).

                                    Go’s error handling is one of those things that make it boring as hell, but also what makes it so easy to be productive at. I just never overthink stuff as much as I do with other languages.

                                    1. 4

                                      What about error handling in Rust? It’s basically unwrap() if you want to ignore the error or propagating it (via try!). Other things like ignore and use default value X are also possible.

                                      The main benefit over Go is that you have to handle the error somehow. You can’t forget to ignore it, and you have to ignore it explicitly if you want to.

                                      1. 2

                                        Haven’t had to deal with Rust yet, so I really don’t know what you’re talking about, sorry!

                                        Maybe I should try it again at some point (never seriously considered in the past due to the constantly changing API).

                                        1. 3

                                          The API has been stable for over a year now, so if you’re interested, now would be a good time to try it out!

                                        2. 1

                                          Don’t forget that Rust still has panics, which for me show up most commonly on array and Vec indexing when I’ve got a bug. Granted, this kind of exception almost always shows up in testing for me, and I rarely encounter libraries which panic on their own, but it’s worth remembering that Result<T, E> isn’t the only way that Rust handles error conditions. I personally don’t worry nearly as much about panics as I do unchecked exceptions in Java or Python, but nonetheless it’s worth noting that Rust doesn’t offer a panacea here, just different tradeoffs (which I’m quite happy with).

                                          1. 1

                                            Go also has panics though, so it’s not really a differentiator.

                                            1. 1

                                              I wasn’t attempting to differentiate Rust vs. Go though. If I wanted to differentiate Rust and Go re: error handling, I would point out that the Rust Result<T, E> type issues compiler warnings if you neglect to use it, whereas Go doesn’t appear to do that (although I haven’t written more than hello world in Go). I was pointing out that Result isn’t the whole error handling story in Rust.

                                      2. 1

                                        arguably the key aspect of djb’s coding style that leads to fewer bugs in practice is extremely explicit error handling. I’m sure the OpenBSD folks handle errors the same way.

                                        1. -3

                                          Laziness, more like.

                                          1. 6

                                            I’d believe that for most other teams. But Go is really a language that has been designed. Even OCaml, a language I like very much, with tons of very fancy features, feels less cohesive and cleanly designed than Go.

                                            1. 2

                                              That’s well possible since MLs like OCaml consist of the core language and the module language and these feel a bit different. There is 1ML which tries to unify these in a coherent whole. Plus OCaml has a lot of syntax and type system featured plastered over the the underlying ML type system which make it a more flexible language but also a more complex.

                                              Maybe it’s also because languages which can be completely understandstood feel more “designed” because it is easier to grasp the design and see how things fit together?

                                              1. 2

                                                More intellectual laziness. “Return values worked for me, why should I do anything else?” Thompson et al are certainly smart and accomplished, but definitely fossilized in their thinking.

                                        2. 1

                                          Learning the Maybe monad in Haskell started my love affair with the language. After my mixed experience with Go it was particularly prescient.

                                          1. 1

                                            I will take the balance of good enough features plus fast builds over richer features and painful builds every time. This is definitely an area where personal preference is the deciding factor.

                                        1. 1

                                          I just found this article on javascript and adopt some useful pattern for encapsulation and reusable module~

                                          1. 2

                                            Sorry to nitpick, but that’s pretty complicated for what it’s trying to do, and I’m not sure there’s a need for it.

                                            For really simple things, like one off test programs, I have a ~10 line Makefile I copy and modify. It’s nothing fancy, but it points to some libraries I’ve installed by hand outside the system include/library locations, and has compiler flags I use often, etc. Basic Makefile syntax for simple apps is straightforward enough that it doesn’t really need anything complicated, I only use the copy/modify approach to save 5 minutes typing it up and double checking paths.

                                            For anything more complicated, like bigger projects with lots of dependencies, I prefer CMake. It would be more work for me to use this easymake than it would be to just use CMake.

                                            1. 1

                                              Yes, it’s rather complicated. I tried simplifying the code for a while, but it’s still complicated with 200+ lines. That’s why I'v added a NOTICE int the README.md before.

                                              I don’t know much about cmake. However, easymake has helped me build some applications in the last company I served, Because unfortunately the team only use make instead of cmake in the ci system.

                                            1. 8

                                              Looks too complicated to be a useful starting point for anyone not comfortable writing their own Makefile. I think make(1) should be studied in the same way one studies sh(1), yacc(1) etc. Once the main points are understood it is fairly trivial to write a minimal Makefile that gets the job done.

                                              1. 1

                                                Yep. The whole mess was started at the time I was not quite enjoying makefile. easymake has gave me some sweet time. It’s not quit generic or extensible, though.

                                                1. 1

                                                  Good to know! Wierd, CXX is g++ by default, from the gnu make manual

                                                  1. 2

                                                    Yep, just noting cc/c++ are a better option so that people don’t need to expect gcc.

                                                    Unless of course you’re trying to require gcc or say clang, but I’d leave that up to the users.