1. 6

    as a vim user, i’ve been wasiting time figuring out the best way to do overtone things without emacs.

    i want to be able to send snippets of code to a lein repl, and i think i’ve settled on vimux (and tmux)

    it works pretty well actually. i tried using it for haskell to interact with ghci (actually, ghci-color) but it doesn’t work so well, because you need to wrap multiline things in “:{ … :}”, and just copying a definition like

    foo :: String
    foo = "Whatevs"
    

    doesn’t work, as it needs to be

    let foo :: String
        foo = "Whatevs"
    

    what i should really be doing is study.

    1. 3

      Perhaps you might get farther using vim-ipython combined with IHaskell? I haven’t done it myself (I should try!) but I’ve heard that vim-ipython might work with IHaskell.

      (Disclaimer: IHaskell is my project, so of course take anything I say about it with a grain of salt :) The vim-ipython author filed some issues at some point that made it seem like it should work with IHaskell just fine.)

      1. 1

        i wouldn’t even mind using IHaskell by itself; i’ll give it a try again. i’ve tried it before, but i don’t really like the docker way of running it; and the standard installation hasn’t worked out for me; but i can try again when i have more time.

      2. 3

        I wish the vim REPL integration plugins were easier to use. I’ve had heaps of trouble getting IDE-like features to work. I’m currently using haskellmode-vim, which seems to work OK, but as soon as I import a cabal dependency, I can’t load a module directly in ghci and therefore haskellmode-vim’s type inference stuff fails.

        1. 2

          yeah; i think if i had a bit of free time i’d probably just sit down and learn emacs (or lighttable)

          1. 2

            tpope’s dispatch and fireplace work pretty well if you’re already a tmux user. I’m not gonna pretend that it’s like having an actual emacs repl but it’s not too bad and might actually work really well with overtone!

        1. 5

          Are any of these actually particularly common? I am graduating soon – are these behaviours I’m likely to run into in the general Silicon-Vally/software/tech company arena? (I’ve been lucky enough to work at great places for internships so far, and don’t think I’ve seen anything like these.)

          1. 9

            It depends entirely on the company. The only real way to try and determine whether these things occur at a given company is to ask the people that work there questions to that effect. Really, the best way is to work there, but this is a solid second-place choice ;)

            Questions to ask during the interview process to suss out details (by applicable question number):

            • 2) What does the process for committing code look like? How effective is it/how often is it followed?
            • 4) What’s your least-favorite project you’ve been on since you’ve started?
            • 10) What kind of hardware do you develop on?
            • 17) How well do you feel like you understand the company’s direction?

            When spread out over several different interviewers (who likely aren’t communicating their specific answers between each other), you can start to get a good idea of what the people that work there really think about their company.

            The interviewers probably won’t lie to you outright (would you?), but they may not tell the whole truth either. Asking a bunch of times gets you answers you can synthesize into a picture of the environment. If things sound too shady, or you can’t get a straight answer, passing on the job might be a good idea!

            Edit: Asking these kinds of questions is always a good idea, as well. Not only does it get you a good idea about the company as a whole, but it marks you as somebody who’s actually thought about the kinds of things they’d like to see in a company. From first-hand experience as an interviewer, this makes a great impression!

            1. 4

              There’s a little truth in all of them, but the ones I see most commonly are #1, #4, and #14.

              1. 3

                As someone who is working in a start up, has worked in 2 previous start ups, several months at enterprise, one tremendous personal failure, and has friends in start ups around ~10-20 people that are vocal about the problems. I will say that you will encounter at least a few of these. A company that has all of these is a company you should leave immediately without question.

                If you are planning to work in this wonderful profession (no sarcasm, this is a beautiful profession with the right people) for many years, be prepared to:

                • Work for someone who won’t treat you the same way a recruiting document may suggest.
                • Work for someone who has little to no understanding of software development.
                • Work for someone who has little to no understanding of how to build a team.
                • Be in a situation where the business is struggling and stress becomes a daily thing.

                Also remember as you work, you change and develop new perspectives. You will also inevitably make mistakes and see a new side to people.

                Ideally you never have to deal with any of these, and you can focus on building awesome things that explore your creativity as well as the needs of people you care about.

                1. 2

                  #3 gave me flashbacks! both the ETA crap, and interrupting me to explain how I was solving the problem (for no very good reason other than the warm fuzzy illusion of managing the effort)

                  1. 2

                    At my last place, 1,5,6,9,10,19 & 21 are pretty spot on unfortunately.

                    1. 2

                      That is brutal. 5 is incredibly tough to deal with. 10 is hilarious if they tell you during the interview that you can pick the hardware you want.

                      1. 1

                        5 is pretty common when an exec has been sold technology before a project starts, thinking it will make everything easier. Then 5 becomes a requirement for the project or it is a) money wasted b) makes said exec look bad. The piece should be renamed to, “How Bureaucracies Function.”

                    2. 2

                      Bad management is very widespread within sv / tech companies, because fast-moving companies inevitably end up with managers with little experience/training.

                      You can dodge some of these issues by working for larger / more-established companies, but even the most well-respected companies have bad managers thriving on some teams. Sometimes top-performing teams can be managed by complete assholes of some form or another (e.g. many of the stories about Steve Jobs).

                      Learning to “manage up” with inexperienced managers, or change positions when the situation is untenable is a reality of business, and not unique to tech.

                      Just to be clear, though – this is a managerial problem and not something you should suffer through! There are plenty of fantastic people out there to work for. As a tech worker you hold sway and can try to seek out places that don’t have these antipatterns, and work to reverse them when you see them.

                    1. 1

                      I wonder if this could be made prettier with a little bit of Template Haskell and quasiquotation. In particular, could we replicate the nice syntax of printf that everyone is used to with formatting, and have it actually be commonly used and somewhat well-known? I would envision something along these lines:

                      print [|Person's name is %s, age is %d|] "Dave" 54
                      

                      I also wonder whether having print be polymorphic in its output type is a good thing. printf is, which allows it to be used as both printf and sprintf from C, but I’m not sure how much of a benefit that really is (and it means that you sometimes need extra type signatures). On the other hand, being able to use printf to output String, Text, and ByteString (of both variants) might be nice.

                      Also, note that the technical aspect of this idea is fairly simple – it’s probably already been implemented a half dozen times. The template haskell paper even uses it as an example and motivation for Template Haskell and shows a simple implementation. However, pulling in quasiquotes or Template Haskell to a new project always feels like a big decision, and so it’d rarely be used just for printf.

                      1. 4

                        Interestingly, I find both ridiculous. I now just use discount and a Makefile

                        1. 3

                          Why not use Pandoc I get the fuzzies knowing that my documents got turned into an AST by Haskell.

                            1. 4

                              Hakyll is really great. I started with Jekyll, migrated to Octopress, didn’t like it, and eventually moved over to Hakyll. It strikes me as more of a library made for writing your own static blog generator, totally customized to your own blog, as opposed to a pre-built tool. However, this means it’s really great for customization - my website is run by a custom file format written in 80 lines using Parsec, and can accept four or five different formats for its blog entries (IHaskell or IPython notebooks, LaTeX, Markdown, HTML, plain text, or Asciidoc). All of this was trivial to add to the Hakyll blog over the years, at the price of a pretty steep upfront configuration cost.

                              1. 1

                                Please tell me more, this sounds amazing. Is your parsec available?

                                1. 1

                                  Sure, you can take a look at the entire blog on Github.

                                  It’s not that fancy, and it’s not that generalizable, but it works really well for me. I have a directory called posts. In that directory, I have a file called postlist, with contents like this:

                                  post {
                                  title "Finger Trees";
                                  date 2014-09-16;
                                  source finger-trees;
                                  categories haskell, ihaskell;
                                  }
                                  post {
                                  title "Linguistics and Syntax";
                                  date 2014-04-29;
                                  source why-syntax;
                                  categories linguistics;
                                  }
                                  

                                  The posts directory also contains a subdirectory for each post; the source field specifies which directory corresponds to which post. Each of these directories must contain a post.ext file, where ext is tex, md, ipynb, and maybe a few more formats, I don’t remember. The directories can also contain img, data, and files directories, which the post.ext file may use. When you run the blog generator, it’ll parse the postlist, generate a post for each post.ext file, and create all the relevant HTML pages. It’s very nice, because it means I can write my blog in any format - sometimes I use HTML, sometimes latex, sometimes IPython/IHaskell notebook. Then I just create a new directory, add something to the postlist, regenerate the blog, and run a single command to deploy.

                            2. 2

                              I haven’t seriously taken a look at pandoc recently. Perhaps I should?

                              1. 1

                                It’s definitely worth a look. I try to not depend on Haskell stuff in general, because it’s a rather large dependency and I still haven’t forgiven it for portability issues years back, but I make an exception for pandoc because it’s just that good.