1. 14

For instance: I personally use Haskell. My main development tool is Sublime Text with the SublimeHaskell package for live typechecking and linting. I use that in conjunction with iTerm with two panes open, one for building and running with ghc and one for testing out individual functions with ghci.

I haven’t really built any big apps or even multi-file programs yet, but I’m sure this approach won’t scale to those. I’ll probably end up using cabal or stack and making heavier use of the file tree in Sublime. I might also play around with Idris while waiting for dependent Haskell to come around.

What language(s) and setup do you use? Feel free to bold the names of the tools as a skimming aid.

  1.  

  2. 9

    Xcode. And a terminal open for git.

    Life as an iOS dev is rough

    1. 1

      Do you ever wish there were competitive alternatives to Xcode? I haven’t developed with it myself, but I’ve used it to build a few projects, and it seems kind of messy/bloated/unreliable/[disparaging adjective of choice] from the glimpse I got.

      1. 2

        It is very buggy, yes. Also a lot of errors that you encounter are very cryptic and have nothing to do with the actual issue. I believe JetBrains released AppCode, but I haven’t taken a look at it.

    2. 9

      vim with a few plugins (well, MacVim), with git for VCS, and iTerm 2 for a terminal. I use MacVim’s tabs and keep only what I need open. To reduce coupling and cognitive overhead, I try to modularize code heavily so I don’t need a huge monitor to track everything. I run a similarly minimalistic zsh prompt that tells me current git branch and dirty status, nothing else.

      I usually use make and some sort of file-watcher to do syntax-checking/test-running as I work for fast feedback. Make is important to me: I can switch projects without having to track whatever weird build command is used for the project.

      For languages, I generally use whatever the project is on, whether it’s Python, Ruby, Rust, or Haskell. I choose whatever language confers the most leverage for the domain, or has the best support for a platform. So, for example, if I’m hacking on a PL, then Haskell is an easy pick. If I’m writing small system utilities like watchexec, then Rust is my go-to.

      1. 4

        Also, Alfred is an absolute must on OS X. I treat it like a CLI for getting around a GUI: VPN connections, launching programs, and opening up Finder windows to a few key locations.

        The default config of Alfred is pretty bad IMO: it optimizes for opening everything with it, making it harder to get to what I want. I turn everything off except application launchers and add a few workflows to let me jump to certain folders, etc.

      2. 8

        At work I mostly write in Ruby, sometimes in Java. I do most of my work in acme (and have for a while), at first on OS X, and for the past month I’ve been experimenting with Windows.

        Odd things about my setup (all acme induced): I use real tabs in all programming languages, and I convert them to soft-tabs using git’s filter system and a custom, round-trip safe version of (un)expand I call detab and retab. I also have a preference for command line applications that print line at a time as opposed to using the entire terminal as a framebuffer of sorts. Finally, I’ve learned to like working without syntax highlighting and fixed width fonts.

        I have a tendency to foolishly seek novelty in my tools (see Windows, heh), so I’m as surprised as anyone that I’ve stuck with acme for this long.

        Disclaimer: I work for Microsoft. They let me use whatever computer or software I want, and they don’t know about this post.

        1. 3

          acme

          Hi fellow tool wanderlust sufferer. I’ve used acme on and off for a while and really appreciate the constraints (syntax highlighting is a blight, and fixed width fonts too) but never manage to stick with it for all that long.

          Any tips? Do you use plumber much, what other external programs are in your acme toolbox, etc.

          1. 2

            The constraints are key. Yes, you can minimize and even hide open files in acme, but you have to do it on purpose, it’s not like that by default. Having a very obvious visual indication that I’ve scatterbrained allows me to regain focus.

            That’s probably the best feature for me. If I ever switch, my next editor will need this.

            I love how after pushing through for two months on the no-syntax highlighting thing, I know never skim code anymore.

            Tips, yes:

            • Three button mouse is a must. I got this one, but I wish it were wireless. I think I might Frankenstein a cheap wireless mouse into it one of these days, once the cable is done fraying.
            • I don’t add much to the plumber rules. At first I thought about a million rules to add, but I end up forgetting they exist. Now I just add one for git sha’s and another for JIRA tickets. Between those and the filename:linenumber I’m set.

            As far as external programs, I have:

            1. a+ and a- for indentation.
            2. nbsptab converts tabs to non-breaking spaces, which lets me post code in places that strip indentation.
            3. rem (adds or removes comments from selected lines, language aware).
            4. gg (which is just git grep).
            5. GB is git blame of the currently open file.
            6. SuPut which lets me save files I don’t have permission to save.

            Other than that I end up using sort, fmt, sed (still don’t grok the sam syntax :/), etc.

            1. 2

              This is all gold for working with acme. I have that same mouse, it’s great. Gitfiles is a utility like Netfiles (which is currently broken because of sftp…) that does magic with git repos, you may or may not find it useful.

          2. 2

            Acme is pretty great.

            I found some tools to make writing Go nicer (auto format on Put and some nice wrappers around guru and friends) and wrote a few scripts to clean up win panes and such. I ended up writing a jira browser so that I could leave it less. It’s probably one of the easiest interactive editors to extend.

            1. 2

              Can you share your win cleanup tools? I still do Edit ,d

              1. 3
                #!/home/hank/plan9/bin/9 rc
                echo 'Edit ,x v/^% /d' | 9p write acme/$winid/body
                echo -n '/Edit ,x v\/\^% \/d/' | 9p write acme/$winid/addr
                echo -n 'dot=addr' | 9p write acme/$winid/ctl
                9p read acme/$winid/addr | awk '{printf("MX%s %s\n", $1, $2)}' | 9p write acme/$winid/event
                

                This is probably maximally ineffecient, but gets the job done. It writes out an edit line, then button 2’s it.

                1. 2

                  Thanks for this! Software needs to be as polished as it needs to be :)

          3. 6

            I write mostly ruby and associated languages/markups in evilmacs, Docker to containerize development environments, i3wm to handle my windows, codeclimate to analyze code style and formatting firefox 51.0a2 for mostly everything, using vimfx plugin (as well as a few others). Everything else is zsh and debian jessie. All. The. Time.

            Except my Nexus. That has other stuff going on.

            1. 6

              90% of the stuff I do is C and Scheme so my dev environment is basically Vim + Tmux (on void-linux or alpine linux with dwm and st). With C, I use gcc, make and entr (to rerun make on file changes), along with the syntastic vim plugin to catch syntax errors. For Scheme, I use chicken-scheme (and more recently racket), tslime, and vim-sexp - I only use dr-racket when I’m doing diagrams/graphs and have to render to a repl.

              1. 6

                Oh my emacs is the source of life.

                Languages:

                • C++ and Python* for work. I’ve found modern C++ more enjoyable than the C++ of the past, but it’s largely a depressing amount of time spent on the most basic things.

                • C, Golang, Guile Scheme, Common Lisp for all personal projects. I adore lisp, but go has a much livelier dev community than scheme/cl so I reach for it when I need to do API glue jobs.

                • Emacs Lisp for anything related to my text editor of choice.

                Build tools:

                • premake is used at work. An unexpected choice, mediocre, but seems to work in many environments.

                • tup for everything else. tup is the best editor for any sufficiently complex build task, and lightning fast.

                Emacs:

                • notmuch for reading all mail

                • helm for autocompletion and fuzzy matching file names

                • projectile for project management

                • magit for git tasks

                • org-mode for notes, todos, etc

                • global for c++ tag searching

                • paredit for scheme/lisp editing

                • erc for IM/IRC

                • geiser & SLIME for lisp development

                Odd’s & ends

                • linux. phone, work laptop, home laptop, server, everything.
                • screen, xterm, ion.. I try to use “old” software on linux so that way things don’t change too much. This strategy has really been working well recently, but I worry about bit-rot.

                Also, I think I should really be using color a lot more in my environment, but I haven’t figured out the best ways. Currently I use a small script that picks random background colors for my xterms, wish there were saner ways of managing tasks with emacs.

                My dream would be to be able to start a “piece of work” in emacs, and it would restore browser tabs, xterms, text files, git branches etc that were open when I last was working on it. Then, when I switched to something else they’d all close and all new stuff would open. Been trying to code something up in emacs but it hasn’t gotten far. This would really give me a strong sense of focus on my tasks.

                Lastly - I find emacs wildly useful for diving deep on development, and encourage everyone to seriously evaluate switching to it.

                1. 5

                  I use vim for pretty much everything. If I have to dabble into some bigger Java projects, I’ll use IntelliJ. I find myself digging deep into Chrome Dev Tools a lot when doing web dev.

                  Lately, though, I’ve been trying out disrupting ripples in the Eddy currents using butterflies, since I heard that’s the new hot thing. I’m a little uncertain with the direction it’s going in, as well as the safety of the butterflies.

                  1. 4

                    On my laptop, I have 4 workspaces. Each for a different usage: top-left is browser, top-right is sublime, bottom-right is terminator and bottom-left is random things (like music, video or image editing). So it’s easy to switch to each one with familiar shortcuts.

                    Random tools I like:

                    • fzf for sublime-text file-search in the terminal
                    • fish, a nice shell, and virtualfish for working with virtualenv
                    • Tabby cat to have a cat instead of the usual new tab page that is very distracting

                    That’s for hobby dev but it’s nice.

                    1. 2

                      How does fish work for you? I also use it as my main terminal. I personally like the changes they made to shell syntax, but it can be frustrating to enter commands found online in my experience. I’ve also tried out fizsh, which has syntax highlighting and history-based completion like fish with the standard syntax of zsh.

                      1. 2

                        It’s working well. When I need to copy paste something strange, I often use bash. One of my favorite thing with fish is the alias feature where it auto-complete your alias like it’s a normal command. Also since it comes with so much built-in, it’s a lot faster to start than zsh with all the usual plugins.

                    2. 4

                      I mostly use C++. Source versioning is with git. I have hotkeys in zsh for git: alt+d is git diff, alt+t is git status, alt+down arrow is git pull, alt+up arrow is git push. Compiling C++ stuff is with CMake + Ninja, editing with Vim: A.vim for file switch between .cpp/.h, Ctrl+P for fuzzy file search (it’s a Vim plugin), thesilversearcher/ripgrep for quick file search (integrated into Vim), GNU Global+Ctags for poor man’s symbolication (but gets the job done, integrated into Vim), Ultisnips for some repetitive code typing (ie. for Qt stuff, it’s a Vim plugin), gnome-terminal for a terminal (but any terminal will do, if it doesn’t have tabs, then I use tmux), zsh aliases like ’m' for build (<leader>b in Vim also does this), ‘r’ for run, ’d' for debug, ’t' for test runner. I use test running tools based on GoogleTest. If I must use Windows, I’m doing it mostly by using msys2.github.io. If I must compile C++ code that is done in Visual Studio, I’m using custom bash scripts to invoke MSBuild.exe, pipe its output through my set of ‘sed’ rules, so MSBuild’s error log is compatible with Vim’s quickfix window (“:cope”). On Windows I’m also using GNU Global+Ctags for file navigation. But normally when I can I’m using Linux or macOS.

                      Sometimes I also use Rust, Ctags works with Rust with some custom rules. I have ‘cargo build’ command bound to my ‘build’ hotkey in Vim, so all errors go to quickfix window. Zsh aliases same as before, ’m', ’t', ‘r’ also work (but not ’d' for debug).

                      For Ruby/Python I don’t do anything compilated, just tabbed console, Vim as an editor, second tab for testing/running.

                      For Window management, I can use whatever gives me multiple workspaces. I was an i3 user for a long time, now I use gnome3 because DOTA2 had more fps when running from gnome3 :). My setup for development is: first workspace is for edition/compilation, second for testing/running/debugging. So, under gnome, I use ctrl+alt+arrows to switch between ‘perspectives’.

                      I also actively use two monitors. My right monitor is my documentation monitor. I run a browser there. On this browser, I have bookmarks for popular frameworks like Qt, Cplusplus, Python3 docs, Ruby docs, Qwt (charting lib for Qt) docs, Java docs, and some others, preferably to ‘all classes’ sections, where I can just enter the page and start searching for a class with Ctrl+F. This is my intellisense :).

                      Very often I also use ssh for development, to run stuff on another machine. Sometimes I use ssh as a method of invoking a compiler on another machine, i.e. when doing development on Linux, but for Windows system, I sometimes run a Windows VM with sshd enabled, I’m editing the code on Linux, and when compiling I’m just running ‘ninja’ on a Windows VM through ssh, so ssh pipes the output from Windows compilation process (Windows gets source files from a shared directory). I get all errors locally on Linux machine in my Vim session, postprocessed by some ‘sed’ rules, so paths will be compatible with Linux filesystem. It actually works pretty nicely.

                      1. 4

                        Sam (text editor), bash, git. Most of my work is in C and Python.

                        IDEs for me have always seemed too limiting. I tried (hard) to use them, but I always ended up having to do a lot of stuff in a shell anyway, so, as has been the case for years now, Unix is my IDE. :)

                        1. 3

                          These days I mainly code in haskell and php, but I’ve mpre or less managed to keep the same setup with every language I’ve used, though It’s had a few iterations, mostly related to adopting neovim instead of vim.

                          So I use neovim with neomake (Which uses neco-ghc, hslint and php), deoplete (for php I pair it with padawan) for auto completion and a few other plugins. I run this in a tmux panel in simple terminal with a second or third panel for a terminal.

                          I also use xmonad as a window manager, I generaly have two other workspaces, one for general purpose terminals and the other for web browsing. I’ll shift whatever image viewing or other in an other workspace when I need to.

                          1. 3

                            At home on Debian I run StumpWM, rxvt-unicode, tmux, git and Emacs. The last couple years I’ve been mainly using Common Lisp, so I’m running Slime and SBCL (updated every few days from the tip of their Git repo). I also use Python and C++ quite a bit, so I have Python 3, gcc/g++, make/autotools/cmake, and Qt around. For both of those I also use Emacs. I put everything on GitHub, so in theory people can submit pull requests/code reviews, open issues, and ask questions there.

                            On my home MacBook I run OSX and the built in terminal, but everything else is about the same as the debian machine, except instead of installing gcc/g++ directly, I have to install XCode. I’ve played with XCode a bit, but it’s not portable, so I stick with other tools.

                            At work I run an old version of Ubuntu (I might switch this to Debian soon). The tools are pretty similar to my home setup: StumpWM, rxvt-unicode, tmux, Mercurial, git, g++, make, and Emacs. Unfortunately, our project management setup sucks at work, so I mainly use Mercurial (and Kiln/FogBugz), but some projects are using Jira, BitBucket, and Git. There’s been talk about moving everything to Jira, BitBucket and Git, but realistically I don’t think it will ever happen, and the longer we go, the less likely it becomes.

                            1. 3

                              As I regretfully write Go professionally (I love my job, just don’t particularly enjoy programming in Go), Emacs with go-mode, goimports, golint, and godef. I use geiser for interacting with Racket when I get a reason for that, and spend a lot of time in compilation-mode, shell-mode, and magit. I should probably start browsing Godoc in emacs more, but end up in Firefox a lot of the time instead.

                              At home, still Emacs for everything, but I don’t have a ton of time to play around with things. Some C, a bit more Go, the occasional Lua for Love2d tinkering, and a bit more Racket.

                              1. 3

                                Qt Creator (buggy as f-), VIM (not an IDE), urxvt, tmux. C, CMake, valgrind, git.

                                You put too much importance on silly stuff. I’m pretty sure you don’t need any big changes. Some of the more respectful programmers I’ve met use almost vanilla Emacs and VIM + gdb.

                                Multi-fileness is optional, I’ve found out I am pretty comfortable with organized >10k SLOC files with multiple views, and as of these days I mostly create 1 file per library or executable. Some of the things I value the most are easy search, completion and symbol jumping.

                                Haskell is a language on a very different level than what I’m used to, though.

                                1. 2

                                  Multi-fileness is optional…

                                  I agreed with you up till this sentence.

                                  Everything in a single file only works for the very tiniest projects, and then only if there’s one person working on it. Even on tiny projects there can be a lot of benefit in breaking things out into multiple files. It logically groups similar functionality, can speed up compile times, helps new developers learn the project, etc.

                                  1. 1

                                    As for cooperation, you have a point there. But allow me to disagree with some of the rest:

                                    tiniest

                                    Just no. I already have a 20k SLOC project, which is arguably not tiny, and it still scales fine.

                                    It logically groups similar functionality

                                    You can do that within a file, there’s barely any difference.

                                    can speed up compile times

                                    The opposite is the case a lot of the time, I get whole program optimization and insanely fast builds.

                                    Actually, making a single huge compilation unit is a popular way of optimizing builds.

                                    1. 4

                                      I also have to agree with @jlarocco, using multiple files makes merging easier, cooperation easier (when multiple people are working on different files), navigation easier (although you may disagree on this one, since this is not really a fact). I think you may like your 1-file project because you wrote it and you know it, but a different case is when you’ll inherit a 20k SLOC 1-file project from someone else. I think readability would be a serious issue here.

                                      Also creating ‘source amalgamations’ is indeed popular (i.e. sqlite does this), but it’s a good feature to have when those amalgamations are created by the build system automatically (ahead of time), not by programmer manually.

                                      1. 2

                                        merging easier

                                        cooperation easier (when multiple people are working on different files)

                                        git doesn’t care. I just don’t see any point here, there is no difference. Well, maybe depending on your workflow. I imagine someone else’s might be affected.

                                        I think readability would be a serious issue here.

                                        Depends. To the contrary, one can get easily lost in a larger amount of small files. Such projects annoy me as I can’t make any sense of them while I swap between files.

                                        It seems to me that your point of view is a senseless dogma like gotos.

                                        In the end, almost anything is fine as long as it’s consistent.

                                        1. 3

                                          I already have a 20k SLOC project, which is arguably not tiny

                                          It’s not tiny, but it’s still quite small.

                                          git doesn’t care

                                          You’re not coöperating with git, you’re coöperating with people.

                                          It seems to me that your point of view is a senseless dogma like gotos.

                                          While both may be called dogmas, I wouldn’t call either senseless. Conventions such as these become more critical once the number of developers grows above 50, and the number of LOC in a project is more than a million.

                                          1. 1

                                            You’re not coöperating with git, you’re coöperating with people.

                                            Still failing to see any difference. Code is code, place doesn’t matter.

                                            Conventions such as these become more critical once the number of developers grows above 50, and the number of LOC in a project is more than a million.

                                            That’s more a matter of habits (largest common denominator wins). A more realistic argument against is e.g. that text editors and various poorly concepted stuff like “web browser + github” may have problems working with big files because no one cared to think about efficiency.

                                            As a side note, a million line codebase with 50 devs smells of a monolithic monster that haunts developers in nightmares. I think the biggest problem you have then is the size itself. Software shouldn’t be this large.

                                            1. 4

                                              Code is code, place doesn’t matter.

                                              Indentation and naming don’t matter to compilers either, but people still fight over coding styles.

                                              A more realistic argument against is e.g. that [tools] may have problems working with big files because no one cared to think about efficiency.

                                              By “conventions such as these” I meant both file size and use of goto. If you’re reading someone else’s code, consistency and clarity matter more than anything.

                                              As a side note, a million line codebase with 50 devs smells of a monolithic monster

                                              Not necessarily. It can be a modularized monster that includes several well-separated modules or libraries.

                                              Software shouldn’t be this large.

                                              The OpenBSD kernel is about 2M lines. Its userland (without X11) about 7M (2M without GNU stuff). And both put together are smaller than the Linux kernel (15M lines). Maybe software shouldn’t be that large, but it is.

                                              1. 1

                                                As a side note, a million line codebase with 50 devs smells of a monolithic monster that haunts developers in nightmares. I think the biggest problem you have then is the size itself. Software shouldn’t be this large.

                                                How large should it be then?

                                        2. 2

                                          20k SLOC is still a very small project by most measures.

                                          I don’t work on your code, so I don’t really care what you do, but FYI most people would consider a single gigantic file really bad style and difficult to work with, and it will annoy your co-workers and cause potential open-source collaborators to shun your projects.

                                      2. 1

                                        You put too much importance on silly stuff.

                                        Haha, that’s fair. I guess the programming itself is more important than the environment. All the same, I have a stupid fascination with the design of software that’s built for building more software.

                                        Multi-fileness is optional, I’ve found out I am pretty comfortable with organized >10k SLOC files with multiple views, and as of these days I mostly create 1 file per library or executable.

                                        Don’t you think there are some advantages to categorizing parts of a program into different files? It seems like some of the workarounds you use might just be ways of simulating this kind of organizational system.

                                      3. 2

                                        I use Emacs mostly. For Ocaml, I’ve recently started making use of merlin which is a pretty unobtrusive IDE-like tool for Ocaml in emacs. It does error checking on save and function completion when I hit a button. I try to do most everything in Emacs although reading Java code usually has me spinning up intellij for the tooling it it, but I do not enjoy writing code in intellij, I find it too distracting.

                                        1. 1

                                          I’ve had a few stilted romps through Emacs (and also Vim) over the years, but the difficulty curve always seemed far too steep. I’m curious to read your impression of Emacs. What got you to make the switch from other IDEs? Or are you one of those lucky bastards who started programming before there was anything else?

                                          1. 3

                                            I started Emacs when I developed serious wrist pain from using the mouse in University. So I wanted an environment that supported keyboard only operation. Emacs fit the bill and since I programmed in C++ and Linux at that time, most things worked out of the box. The Emacs tutorial flattened the learning curve so that Emacs became useful for me very quickly. And the benefit was that everything could be done from the keyboard, which gave me motivation to work through the issues.

                                            1. 1

                                              I started Emacs when I developed serious wrist pain from using the mouse in University.

                                              Doesn’t chording in Emacs kill your wrists? One good thing about vi is that you seldom press more than two keys at once.

                                              1. 2

                                                Not in my experience. Since I rarely move my fingers from the homerow I suppose I don’t lose my posture as much as when using the mouse. A good keyboard helps too.

                                                I can follow your argument though. Maybe it is even better with vi. It would be quite a big time investment for me to learn to use it effectively and I am not convinced that it would be worthwhile.

                                            2. 3

                                              I was a vim user before but, probably 10+ years ago, I decided to learn Mozart/Oz where Emacs was the development environment so I learned it. There isn’t any special nobility in using Emacs, I just happen to be used to it and like it. I am also one of those people who believes modern IDEs help one write more code, not better code, so I don’t find many modern IDE’s compelling enough to learn (with the exception of using an IDE to explore large Java codebases because they are difficult to grok otherwise). I’m also not a very sophisticated Emacs user. Probably 90% of my Emacs usage is 7 or 8 commands. I do wish there was a viable Emacs clone that was less of a kludge, the whole elisp system is pretty nasty, so in that sense I think Emacs is a weak point in my development setup which strives for simplicity but other editors don’t seem much simpler so meh.

                                              1. 2

                                                I’m the latter category. I “switched” from vi (not vim) about 5 years back.

                                                My main reasons to switch to emacs was programming it to do work for me. Primarily now org mode and tramp rule the day for my use. I even have my emacs configuration in org mode itself so its easy to structure package installs and configuration. So I’m basically papering over most of the annoyances. Which to be fair emacs can have a lot of these, but generally its nothing that can’t be overcome.

                                                I use/abuse haskell/idris/c/python/shell with my emacs setup. With flycheck and a recent-ish emacs i’ve not really had a lot of issues. The curve sucks for sure, but now that I’ve invested some time into it and treating it as a programming language to learn, its basically worked well and using most ide’s I don’t find much missing. Perhaps refactoring support but honestly thats at best a nice to have thing not a requirement.

                                            3. 2

                                              I mainly use Python 3 and JavaScript. I use PyCharm to write 90% of my code, with the rest in various text editors (Sublime Text, Atom, VS Code). I do all my version control, controlling processes, and searching over my code in the terminal instead of in PyCharm; I’m just more used to it that way, even if it’s more steps.

                                              I use direnv heavily to set up individual development environments and use Webpack to compile my front-end assets.

                                              I recently used Docker on two projects and feel ambivalent about it. I might use it more for development environments. I also used to use Emacs for about 10 years and always consider going back. PyCharm and VS Code work well for me for now, though.

                                              1. 2

                                                I mostly write JavaScript and I use Visual Studio Code. No special plugins. I use regular old terminal with two tabs to run a Postgres database client (for local) & Node/Grunt for running the server, Redis Desktop Manager for managing locally cached user content, and I keep Chrome open for dev testing/docs/Clubhouse project management tools/GitHub. For testing, I use Mocha and Jest via terminal. For code cleanliness, I use JSCS and JSHint via terminal. Nodemon watches for any server changes to reload the server, while there are other watch tasks for minification/code cleanliness on file save. Browserify makes my client-side code look like server-side code and I love it. Most of those tools run automatically via build scripts. I type grunt and it’s good to go.

                                                The VS Code debugger is pretty boss for Node apps, so if I need to debug the server, I run it from there. If I’m doing front end stuff, though, I just run it in the regular terminal.

                                                We use GitHub commits to kick off a Travis CI build which also does all of our testing and reports any errors, which is really helpful when it comes to doing reviews. We also use GitHub’s code review tools before merging anything.

                                                I’m OS-independent, but I most often use OSX for work things and Windows 10 for personal things. Gotta keep the development separated!

                                                1. 2

                                                  Spacemacs + Haskell + nixos + xmonad + zerotier

                                                  1. 1

                                                    zerotier as in ZeroTierOne SDN?

                                                    1. 2

                                                      Correct. I mentioned it because I find it’s pretty integral to how I work these days. I have a private git-http-backend/gitweb that I host my internal projects on, that I reference in my nix expressions.

                                                      Being able to access all my devices and computers from anywhere makes it easy to work remotely. I run another network at work for our intranet because it’s brain dead simple to set up on Windows, osx, linux, ios, android, etc.

                                                  2. 2

                                                    I no longer do much software development as part of my day job but when working on personal projects I use vim (well, MacVim) exclusively. I also use the standard set of accompaniments - iTerm2, git (from pkgsrc), zsh, tmux, Alfred, TotalSpaces. Most of my programming is in Go at the moment although I sometimes have to dip into JavaScript.

                                                    I have tried switching to Emacs on numerous occasions over the last ~25 years (heck, I even used Emacs before vi), but have never quite made it. I’ve worked through a lot of the tutorial, read large swathes of the ORA book and am quite familiar with a lot of the standard keybindings. But still, it won’t stick :(

                                                    1. 1

                                                      I use a typical dwm/vim/tmux/make/gcc/etc setup. The one thing that hasn’t been mentioned yet is gdbx, which is the only Linux debugger I’ve used that isn’t completely terrible. It doesn’t have a watch window but apparently that’s being worked on. Some other debuggers I’ve tried:

                                                      • gdb - the “standard” but I can’t tell what the hell is going on when it only prints single lines after each step
                                                      • gdb -tui - better, but it craps out a lot
                                                      • lldb - screenshots look nice but when I try to type in it it just prints unicode escape sequences or something (you can’t get text input to work in 2016??? in a console app so ncurses/the terminal is doing everything for you anyway????????). Apparently you can fix this with a compile time switch but I only have an i7 and 16GB of RAM so I can’t compile LLVM
                                                      • various vim gdb scripts - meh. pyclewn was decent but a bit buggy
                                                      • vim-lldb - needs python modules for vim + lldb. I have the lldb module for python2 and the vim module for python3 and apparently you can’t download them separately (I feel like LLVM is consistently miserable to interact with outside of “I’m going to run this precompiled clang binary”, which is super disappointing when it’s being positioned the universal compiler of the future)
                                                      • various python gdb scripts - no I don’t want to download 6 million dependencies
                                                      • affinic debugger - meh
                                                      1. 1

                                                        For work, I mostly write Erlang and C, while at home I write Lisp/Scheme, and try as many different languages as I have time for. My editor of choice is Emacs, though I did spend several years using vi/Vim, which I often use over ssh. I use tmux, st and zsh for all my terminal needs, and recently switched from i3 to dwm for window management. I use Arch Linux at home, and Ubuntu at work.

                                                        1. 1

                                                          WORK

                                                          • For OpenResty/Lua, Neo4J/Cypher, React Native/JS (with redux and redux-saga), bash scripts (to glue everything together and interact with gcloud a bit more fluently) and legacy PHP, I use vim and tmux inside Mac OSX Terminal. tmux does everything I (perhaps mistakenly) think I’d need from e.g. iTerm2, and I don’t have any problems with Terminal. Dev environments mirroring production all run in Debian VMs running inside VirtualBox and managed by Vagrant.

                                                          • For iOS and Android builds and releases, along with the odd native Obj-C or Java module, I use Xcode and Android Studio.

                                                          PLAY

                                                          • erlang with some C (and occasionally C++) to glue external libs/drivers into NIFs, some browser-based vanilla JS, all in vim and tmux. Recently I don’t seem to do anything like as much PLAY as I’d like to be doing.

                                                          In general, I try to keep everything as vanilla and default-install as possible, so I don’t use any vim plugins. Just a few lines in .exrc for syntax colouring and indentation, and a few language-specific syntax schemes. (Looking at syntastic after seeing @nc’s post though, I should probably try that out.) My .tmux.conf is <20 lines, mostly setting modifiers to be vim-like but still allow all the emacs bindings in bash.

                                                          I currently use homebrew package manager but I’m looking somewhat enviously over the fence at pkgsrc/pkgin.

                                                          1. 1

                                                            At the moment i develop in C#, C++ and ClojureScript on Windows. I use Emacs on Windows and an assortment of PortableApps. It took quite a while to collect all the tools that Emacs uses to support various workflows and teach Emacs about them. I also spend quite a lot of time in Visual Studio. Reluctantly so, and I make quite a few attempts a year to code C# from Emacs, unsuccessfully so far.

                                                            1. 1

                                                              I live in Emacs, for programming and basically for everything else. For work, I write Python, using conda to manage my installations. I write Java in Intelli-J, which is an astonishingly powerful tool. My day to day environment is OS X, but I have a big Linux compute server under my desk that I ship code to from time to time.

                                                              1. 1

                                                                Lately I’m writing entirely Ruby and C. A month or two ago I decided to start using Emacs full-time (using vim, for the decade prior), and Spacemacs with evil mode turned off is a really nice and easy way to get that happening. iTerm to build and test.

                                                                1. 1

                                                                  Atom, termite, filezilla and node.

                                                                  I really want to start using vim properly though. I just don’t use it enough and I need to force myself to.

                                                                  1. 1

                                                                    C++ in Visual Studio and Geany/KDevelop, I like all of those IDEs, but I wish all the features I wanted were all under the same roof. Lots a bash recently too. Occasionally Javascript, I’m always pleasantly surprised by the speed of development, but I hate the lack of type safety.

                                                                    1. 1

                                                                      I use Void Linux with awesomewm as a window manager and urxvt as a terminal emulator. My workspace layout varies based on what I’m doing. My go-to language is Perl, with vim as the editor. Git as VCS, of course. That’s about it. I use SeaMonkey as my day-to-day browser and email client.

                                                                      1. 1

                                                                        I am making small web apps (node.js and Elm) on Macbook Pro. Working mostly in Vim + Tmux + Terminal.app. From time to time switching to Google Chrome. http://www.romanzolotarev.com/dotfiles/