1. 1

    I wonder if :W is a typo… (vs just W).

    1. 2

      Beautiful naming (got, tog, …)

      1. 4

        Just wanted to share a nice method for converting font-types into paths (in svg) that you’d be hard-pressed to accomplish without inkscape:

        inkscape -T -A tmp-hack.pdf orig-w-custom-fonts.svg

        inkscape -l final.svg tmp-hack.pdf

        1. 2

          One issue with the free tier is Heroku idles one’s instance for a chunk of the day : https://blog.heroku.com/heroku-free-dynos

          `free dynos are allowed 18 hours awake per 24 hour period’

          1. 3

            Sad, but true, is Joe’s Law : `Frameworks grow in complexity until nobody can use them.’

            1. 3

              Similar to Zawinski’s Law:

              “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Coined by Jamie Zawinski (who called it the “Law of Software Envelopment”) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.

            1. 2

              I have begun using PropEr for my Erlang/OTP code, largely because I feel unit testing of routines – routines that tend to be around four lines tall – in a language that has single assignment (SSA), to be quite the Kabuki theatre. Hurdles with this new way of testing, are mostly related to my slow adoption of something quite new. So, not sure if this feedback helps in any shape or form. I can’t stress enough how little unit testing has done for me, with Erlang. So, I’ll probably stick with PropEr for a good long while. Perhaps a resource with the focus along the lines of `Property-based testing for people coming from Unit testing’ would have helped some of the growing pains.

              1. 2

                Nice [first] post, Simon! Keep them coming.

                1. 4

                  For anyone thinking of trying out Erlang, this is how some of these shortcomings played out for me over the years.

                  In no particular order:

                  • if statements/expressions become an anti-pattern; you never use them
                  • expression termination handling becomes second-nature (thanks vim!)
                  • one leans on so-called strings less and less; ’tend to use atom constants and bitstrings
                  • variables at most are reassigned once ; A' gets augmented once becomingA1’ from time to time
                  • one falls in love with records to the point that they bring a smile to one’s face

                  This is to say nothing of Erlang’s shortcomings, which from my vantage point, are not on this particular list.

                  1. 3

                    What’s Core Erlang, relative to Regular Erlang? I tried googling it, and it was not as useful as I thought it would be

                    1. 4

                      it’s a compiler IL. several other beam languages use it as a target, and a lot of tooling (most notably the dialyzer) works directly on it. in the context of the series, iirc it’s the form that the compiler runs a lot of transformations on for optimization.

                      1. 2

                        I could be mistaken, but I believe I read in some white paper at some point, that the dialyzer project needed an intermediate format (one that would make their lives easier) in order to proceed. So Core Erlang sprung out those efforts during dialyzer’s infancy at Uppsala University. Feel free to correct me where I’ve mis-remembered.

                        1. 2

                          I have since read a bit on Core Erlang, Dialyzer works on the intermediate format directly. The intermediate format is also what Elixir (and other BEAM languages) compile down to, which is why the Dialyzer works at all on them. Really cool.

                        2. 1

                          If my understanding is correct, it’s basically an intermediate compilation target between normal Erlang code and what runs on the BEAM.

                        1. 9

                          I found much value in this related video posted quite recently :

                          https://www.youtube.com/watch?v=_FQJEzJ_cQw

                          1. 1

                            One snafu with aliases that I never found a great work-around was using date or cal or anything that is mutable, would be sort of galvanized after that bash/zsh profile was set. One would have to source that profile file to get the current, in my case, time. So, it didn’t work for things like that (which was quite a few aliases). A quick hack to make this work is welcomed, BTW.

                            1. 2

                              I’m not sure what you mean. I tried to guess, but I ended up with dynamic date values. I’ll attempt to fix a galvanized example you give me…

                              hobbes@metalbaby:~/e2-scratch/s2u$ alias foo='echo $(date)'
                              hobbes@metalbaby:~/e2-scratch/s2u$ foo
                              Fri Jan 19 17:48:51 CST 2018
                              hobbes@metalbaby:~/e2-scratch/s2u$ foo
                              Fri Jan 19 17:48:53 CST 2018
                              hobbes@metalbaby:~/e2-scratch/s2u$ foo
                              Fri Jan 19 17:48:54 CST 2018
                              hobbes@metalbaby:~/e2-scratch/s2u$ foo
                              Fri Jan 19 17:48:55 CST 2018
                              
                            1. 2

                              I think if I were to relive my Erlang education, it would be to go against the severely pushed agenda of `no matter what, use behaviors from the get-go.’ gen_server is a great pattern, but it feels counter to everything functional programming and for that matter concurrent programming is all about. Sure, now knowing how the behaviors are implemented, it all fits, but for the first while, the behaviors felt magical (like OOP), stateful-feeling-ish (like OOP), and imperative (after all, 1. a gen_server is embodied within a single named process, despite that Erlang touts: go ahead, create millions of processes; 2. the most common thing to do with said servers is use =call= which is blocking/synchronous). In the end, of course, use the behaviors, but just blindly using them from day-one is a crappy lead-in to Erlang/OTP, and probably comes with many hidden costs as far as how fast & deep one learns the paradigms of FP and all things OTP.

                              1. 1

                                I can’t agree more with this feeling. It is, in part, the inspiration behind this blog post. The idea is to first find the problems, try to solve them, figure out they’re always the same ones and somebody before you found them too, and only then using the tools that solve most of the problem for you and write your specific code.

                              1. 7

                                To parrot Joe Armstrong, Erlang is meant to run forever, so running some code then quit is not a pattern typically suited for Erlang. I wrote a small lib to reduce overhead for such use-cases of running code, then quit:

                                http://blog.ikura.co/posts/notp-a-middle-way.html

                                The overhead is real when using Erlang as is. Would you pack your bags light if you were set off on a multi-year journey? I for one would pack quite a bit in my bags.

                                1. 3

                                  ‘Just wanted to laud (in case there are anyone who doesn’t know of it) Backus’ 1978 paper on FP. It’s quite readable & comes from a unique perspective on the matter.

                                  1. 4

                                    The first `demo’ crashed my laptop. I haven’t had to restart my computer in a long time.

                                    1. 1

                                      Worked for me on my MacBook Pro 2017 in Safari. Pretty impressed that it can take down your system. Probably worth a bug report.

                                    1. 1

                                      `[Property-based testing] is a high-investment, high-reward kind of deal.’ I can’t think of a more Erlang-y notion than that (in a good way).

                                      1. 3

                                        I do stand by that comment. In the (current) preface I mention that I’ve spent years toying with property-based testing [on and off] without feeling competent. I’ve seen talks about it, asked questions to people who knew more than I do, and a lot of the examples – toy examples – always felt very limited or always highlighting some basic bug (0.0 =/= 0 but Erlang allows both!) Stateless tests are fairly okay to test, but stateful ones were more of a challenge.

                                        Eventually I decided to take a deep dive and test non-trivial projects with it [albeit personal toy projects] until I could find ways to deal with asynchronous code, complex outputs and inputs, and figure out, with limited outside help, what seemed to stick or not.

                                        I’m hoping that this ‘book’ helps share my experience and therefore makes the investment required lower, but truth is that there is a kind of habit that you get in “thinking in properties” similar to what you get in programming languages or specific paradigms, and that takes practice. There are tips and tricks, but you only think comfortably within a paradigm once you’ve forced yourself to hit and go through a few walls with it.

                                        1. 1

                                          but truth is that there is a kind of habit that you get in “thinking in properties” similar to what you get in programming …

                                          I find that the things that make good contracts also happen to overlap with good properties to test. That doesn’t solve the “properties are hard”, but does reframe the problem in a way that’s often, in my (rather limited) experience, easier to reason about.

                                      1. 2

                                        I’m not affiliated with Ericsson nor Erlang Solutions, but for those wanting to give OTP a try and have yet to, it’s super easy to get installing via https://www.erlang-solutions.com/resources/download.html

                                        Here’s a hello world example you can use. Type erl in your console to get the Erlang shell. Then:

                                        1> S = self().
                                        2> A = fun() -> S ! hello_world end.
                                        3> spawn(A).
                                        4> flush().
                                        5> q().
                                        

                                        This will showcase processes (which enable concurrency) and message passing to whet your appetite.

                                        1. 1

                                          Also I really enjoy elixir, the ruby like language built on top of the erlang vm. I recently built a raspeberry pi connected device with it.

                                        1. 5

                                          I know someone who got fired b/c they spent time writing tests. And although some may say, hey, I’d never want to work for a firm that does X, Y or Z anyway, well, I just wanted to point out that situations are out there where testing isn’t moving fast enough. Shipping fast is a huge priority for a lot of shops, etc.

                                          1. 1

                                            I also know someone who got fired for not writing tests, so I’m not sure this is really a valid argument. It does mean that if someone believes that writing tests is the best way to ship, then they should make sure that the organization that they join also believes that, and vice-versa.

                                          1. 2

                                            Hear hear on point two!

                                            1. 4

                                              Migrating an app off Heroku to DigitalOcean for an old client. Only now can I see the immense value Heroku offers.