Julia feels…rough.

There are parts I absolutely love, like the strong typing, the baked-in matrix operations, and the support for multi-type dispatch.

Then there’s the pieces that seem incomplete. Like the documentation, which is very extensive, but proved useless when trying to find out the proper way to build dictionaries in the latest version. Or the package system, which will install things right into a running repl (cool!) but does it without getting your permission for all its dependencies (boo).

All in all, I’d like to build something more extensive in Julia. Preferably something ML-related, that I might normally build in Python.

Day One

• can install with brew
• book written for 0.3, newest version is 0.5
• has a repl built in :)
• typeof for types
• "" for strings, '' only for single-chars
• // when you want to divide and leave it divided (no float, keep the fraction)
• has symbols
• arrays are typed, but can contain more than one type (will switch from char to any, for example)
• commas are required for lists, arrays, etc (boo)
• tuples: fixed sized bags of values, typed according to what they hold
• arrays carry around their dimensionality (will be important for matrix-type ops later on)
• has dictionaries as well
• hmm: typeof({:foo => 5}) -> vector syntax is discontinued
• Dicts have to be explicitly built now: Dict(:foo => 5) is the equivalent
• XOR operator with $
• bits to see the binary of a value
• can assign to multiple variables at once with commas (like python)
• trying to access an undefined key in a dict throws an error
• in can check membership of arrays or iterators, but not dictionaries
• but: can check for key and value in dict using in + pair of key, value: in(:a => 1, explicit)
• book's syntax of using tuple for the search is incorrect
• julia docs are really...not helpful :/
• book's syntax for set construction is also wrong
• nothing in the online docs to correct it
• (of course, nothing in the online docs to correct my Dict construction syntax, either)
• can construct Set with: Set([1, 2, 3])
• arrays are typed (Any for multiple types)
• array indexes start at 1, not 0 (!) [follows math here]
• array slices include the ending index
• can mutate index by assigning to existing index, but assigning to non-existing index doesn't append to the array, throws error
• array notation is row, column
• * will do matrix multiplication (means # of rows of first has to match # of columns of second)
• regular element-wise multiplication needs .*
• need a transpose? just add '
• very much like linear algebra; baked-in
• dictionaries are typed, will throw error if you try to add key/value to them that doesn't match the types it was created with
• BUT: can merge a dict with a dict with different types, creates a new dict with Any to hold the differing types (keys or values)

Day Two

• if..elseif...end
• if check has to be a boolean; won't coerce strings, non-boolean values to booleans (nice)
• reference vars inside of strings with $ prefix: println("$a")
• has user-defined types
• can add type constraints to user-defined type fields
• automatically gets constructor fn with the same name as the type and arguments, one per field
• subtype only one level
• abstract types are just ways to group other types
• no more super(), use supertype() -> suggested by compiler error message, which is nice
• functions return value of last expression
• ... to get a collection of args
• +(1, 2) -> yields 3, operators can be used as prefix functions
• ... will expand collection into arguments for a function
• will dispatch function calls based on the types of all the arguments
• type on pg 208: int() doesn't exist, it's Int()
• WARNING: Base.ASCIIString is deprecated, use String instead.
• no need to extend protocols or objects, classes, etc to add new functions for dispatching on core types: can just define the new functions, wherever you like, julia will dispatch appropriately
• avoids problem with clojure defmulti's, where you have to bring in the parent lib all the time
• julia has erlang-like processes and message-passing to handle concurrency
• WARNING: remotecall(id::Integer,f::Function,args...) is deprecated, use remotecall(f,id::Integer,args...) instead.
• (remotecall arg order has changed)
• randbool -> NOPE, try rand(Bool)
• looks like there's some overhead in using processes for the first time; pflip_coins times are double the non-parallel version at first, then are reliably twice as fast
• julia founders answered the interview questions as one voice, with no distinction between them
• whole section in the julia manual for parallel computing

Day Three

• macros are based off of lisp's (!)
• quote with :
• names fn no longer exists (for the Expr type, just fine for the Module type)
• use fieldnames instead
• unquote -> $
• invoke macro with @ followed by the args
• Pkg.add() will fetch directly into a running repl
• hmm...installs homebrew without checking if it's on your system already, or if you have it somewhere else
• also doesn't *ask* if it's ok to install homebrew
• not cool, julia, not cool
• even then, not all dependencies installed at the time...still needed QuartzIO to display an image
• view not defined
• ImageView.view -> deprecated
• imgshow does nothing
• docs don't help
• hmm...restarting repl seems to have fixed it...window is hidden behind others
• img no longer has data attribute, is just the pixels now
• rounding errors means pixels != pixels2
• ifloor -> floor(Int64, val) now
• works!

So frustrating. I had high hopes going in that Elixir might be my next server-side language of choice. It’s built on the Erlang VM, after all, so concurrency should be a breeze. Ditto distributed applications and fault-tolerance. All supposedly wrapped in a more digestible syntax than Erlang provides.

Boy, was I misled.

The syntax seems to be heavily Ruby-influenced, in a bad way. There’s magic methods, black box behavior, and OOP-style features built in everywhere.

The examples in this chapter go deeply into this Ruby-flavored world, and skip entirely over what I thought were the benefits to the language. If Elixir makes writing concurrent, distributed applications easier, I have no idea, because this book doesn’t bother working examples that highlight it.

Instead, the impression I get is that this is a way to write Ruby in Erlang, an attempt to push OOP concepts into the functional programming world, resulting in a hideous language that I wouldn’t touch with a ten-foot-pole.

I miss Elm.

Day One

• biggest influences: lisp, erlang, ruby
• need to install erlang *and* elixir
• both available via brew
• syntax changing quickly, it's a young language
• if do:
• IO.puts for println
• expressions in the repl always have a return value, even if it's just :ok
• looks like it has symbols, too (but they're called atoms)
• tuples: collections of fixed size
• can use pattern matching to destructure tuples via assignment operator
• doesn't allow mutable state, but can look like it, because compiler will rename vars and shuffle things around for you if you assign something to price (say) multiple times
• weird: "pipes" |> for threading macros
• dots and parens only needed for anonymous functions (which can still be assigned to a variable)
• prints out a warning if you redefine a module, but lets you do it
• pattern matching for multiple functions definition in a single module (will run the version of the function that matches the inputs)
• can define one module's functions in terms of another's
• can use when conditions in function def as guards to regulate under what inputs the function will get run
• scripting via .exs files, can run with iex
• put_in returns an updated copy of the map, it doesn't update the map in place
• elixir's lists are linked lists, not arrays!
• char lists are not strings: dear god
• so: is_list "string" -> false, but is_list 'string' -> true (!)
• wat
• pipe to append to the head
• when destructuring a list, the number of items on each side have to match (unless you use the magic pipe)
• can use _ for matching arbitrary item
• Enum for processing lists (running arbitrary functions on them in different ways, like mapping and reducing, filtering, etc)
• for comprehensions: a lot like python's list comprehensions; takes a generator (basically ways to pull values from a list), an optional filter (filter which values from the list get used), and a function to run on the pulled values
• elixir source is on github

Day Two

• mix is built in to elixir, installing the language installs the build tool (nice)
• basic project template includes a gitignore, a readme, and test files
• source files go in lib, not src
• struct: map with fixed set of fields, that you can add behavior to via functions...sounds like an object to me :/
• iex -S mix to start iex with modules from your project
• will throw compiler errors for unknown keys, which is nice, i guess?
• since built on the erlang vm, but not erlang, we can use macros, which get expanded at compile time (presumably, to erlang code)
• should is...well...kind of a silly macro
• __using__ just to avoid a fully-qualified call seems...gross...and too implicit
• and we've got to define new macros to override compile-time behavior? i...i can't watch
• module attributes -> compile-time variables -> object attributes by another name?
• use, __using__, @before_compile -> magic, magic everywhere, so gross
• state machine's "beautiful syntax" seems more like obscure indirection to me
• can elixir make me hate macros?
• whole thing seems like...a bad example. as if the person writing it is trying to duplicate OOP-style inheritance inside a functional language.
• elixir-pipes example from the endnotes (github project) is much better at showing the motivation and usage of real macros

Day Three

• creator's main language was Ruby...and it shows :/
• spawn returns the process id of the underlying erlang process
• pattern matching applies to what to do with the messages a process receives via its inbox
• can write the code handling the inbox messages *after* the messages are sent (!)
• task -> like future in clojure, can send work off to be done in another process, then later wait for the return value
• use of Erlang's OTP built into Elixir's library
• construct the thing with start_link, but send it messages via GenServer...more indirection
• hmm...claims it's a "fully distributed server", but all i see are functions getting called that return values, no client-server relationship here?
• final example: cast works fine, but call is broken (says process not alive; same message regardless of what command sent in (:rent, :return, etc)
• oddly enough, it works *until* we make the changes to have the supervisor run everything for us behind the scenes ("like magic!")
• endnotes say we learned about protocols, but they were mentioned only once, in day two, as something we should look up on our own :/
• would have been nicer to actually *use* the concurrency features of language, to, idk, maybe use all the cores on your laptop to run a map/reduce job?

Between the move and the election and the holidays, took me a long time to finish this chapter.

But I’m glad I did, because Elm is – dare I say – fun?

The error messages are fantastic. The syntax feels like Haskell without being as obtuse.  Even the package management system just feels nice.

A sign of how much I liked working in Elm: the examples for Day Two and Three of the book were written for Elm 0.14, using a concept called signals. Unfortunately, signals were completely removed in Elm 0.17 (!). So to get the book examples working in Elm 0.18, I had to basically rebuild them. Which meant spending a lot of time with the (admittedly great) Elm tutorial and trial-and-erroring things until they worked again.

None of which I minded because, well, Elm is a great language to work in.

Here’s the results of my efforts:

• Day Two
• Day Three

Day One

• haskell-inspired
• elm-installer: damn, that was easy
• it's got a repl!
• emacs mode also
• types come back with all the values (expression results)
• holy sh*t: "Maybe you forgot some parentheses? Or a comma?"
• omg: "Hint: All elements should be the same type of value so that we can iterate through the list without running into unexpected values."
• type inferred: don't have to explicitly declare the type of every variable
• polymorphism via type classes
• single-assignment, but the repl is a little looser
• pipe syntax for if statement in book is gone in elm 0.17
• case statement allows pattern matching
• case statement needs the newlines, even in the repl (use `\`)
• can build own complex data types (but not type classes)
• case also needs indentation to work (especially if using result for assignment in the repl)
• records: abstract types for people without beards
• changing records: use `=` instead of `<-`: { blackQueen | color = White }
• records look like they're immutable now, when they weren't before? code altering them in day one doesn't work
• parens around function calls are optional
• infers types of function parameters
• both left and right (!) function composition <| and |>
• got map and filter based off the List type (?)
• no special syntax for defining a function versus a regular variable, just set a name equal to the function body (with the function args before the equal sign)
• head::tail pattern matching in function definition no longer works; elm is now stricter about requiring you to define all the possible inputs, including the empty list
• elm is a curried language (!)
• no reduce: foldr or foldl
• have to paren the infix functions to use in foldr: List.foldr (*) 1 list
• hard exercise seems to depend on elm being looser than it is; afaict, it won't let you pass in a list of records with differing fields (type volation), nor will it let you try to access a field that isn't there (another type violation)

Day Two

• section is built around signals, which were removed in Elm 0.17 (!)
• elm has actually deliberately moved away from FRP as a paradigm
• looks like will need to completely rewrite the sample code for each one as we go...thankfully, there's good examples in the elm docs (whew!)
• [check gists for rewritten code]
• module elm-lang/keyboard isn't imported in the elm online editor by default anymore

Day Three

• can fix the errors from loading Collage and Element into main by using toHtml method of the Collage object
• elm-reactor will give you a hot-updated project listening on port 8000 (so, refresh web page of localhost:8000 and get updated view of what your project looks like)
• error messages are very descriptive, can work through upgrading a project just by following along (and refreshing alot)
• critical to getting game working: https://ohanhi.github.io/base-for-game-elm-017.html (multiple subscriptions)

Continuing on to the next language in the book: Factor.

Factor is…strange, and often frustrating. Where Lua felt simple and easy, Factor feels simple but hard.

Its concatenative syntax looks clean, just a list of words written out in order, but reading it requires you to keep a mental stack in your head at all times, so you can predict what the code does.

Here’s what I learned:

Day One

• not functions, words
• pull and push onto the stack
• no operator precedence, the math words are applied in order like everything else
• whitespace is significant
• not anonymous functions: quotations
• `if` needs quotations as the true and false branches
• data pushed onto stack can become "out of reach" when more data gets pushed onto it (ex: store a string, and then a number, the number is all you can reach)
• the `.` word becomes critical, then, for seeing the result of operations without pushing new values on the stack
• also have shuffle words for just this purpose (manipulating the stack)
• help documentation crashes; no listing online for how to get word docs in listener (plenty for vocab help, but that doesn't help me)
• factor is really hard to google for

Day Two

• word definitions must list how many values they take from the stack and how many they put back
• names in those definitions are not args, since they are arbitrary (not used in the word code itself)
• named global vars: symbols (have get and set; aka getters and setters)
• standalone code imports NOTHING, have to pull in all needed vocabularies by hand
• really, really hate the factor documentation
• for example, claims strings implement the sequence protocol, but that's not exactly true...can't use "suffix" on a string, for example

Day Three

• not maps, TUPLES
• auto-magically created getters and setters for all
• often just use f for an empty value
• is nice to be able to just write out lists of functions and not have to worry about explicit names for their arguments all over the place
• floats can be an issue in tests without explicit casting (no types for functions, just values from the stack)
• lots of example projects (games, etc) in the extra/ folder of the factor install

Realized I haven’t learned any new programming languages in a while, so I picked up a copy of Seven More Languages in Seven Weeks.

Each chapter covers a different language. They’re broken up into ‘Days’, with each day’s exercises digging deeper into the language.

Here’s what I learned about the first language in the book, Lua:

Day One

• table based
• embeddable
• whitespace doesn't matter
• no integers, only floating-point (!)
• comparison operators will not coerce their arguments, so you can't do =42 < '43'
• functions are first class
• has tail-call-optimization (!)
• extra args are ignored
• omitted args just get nil
• variables are global by default (!)
• can use anything as key in table, including functions
• array indexes start at 1 (!)

Day Two

• no multithreading, no threads at all
• coroutines will only ever run on one core, so have to handle blocking and unblocking them manually
• explicit over implicit, i guess?
• since can use functions as values in tables, can build entire OO system from scratch using (self) passed in as first value to those functions
• coroutines can also get you memoization, since yielding means the state of the fn is saved and resumed later
• modules: can choose what gets exported, via another table at the bottom

Day Three

• had to add Homebrew's Lua include directory (/usr/local/Cellar/lua/5.2.4_3/include) into include_directories command in CMakeLists.txt file
• when compiling play.cpp, linker couldn't find lua libs, so had to invoke the command by hand (after reading ld manual) with brew lua lib directory added to its search path via -L
• basically, add this to CMakeFiles/play.dir/link.txt: -L /usr/local/Cellar/lua/5.2.4_3/lib -L /usr/local/Cellar/rtmidi/2.1.1/lib
• adding those -L declarations will ensure make will find the right lib directories when doing its ld invocation (linking)
• also had to go into the Audio Midi Setup utility and set the IAC Driver to device is online in order for any open ports to show up
• AND then needed to be sure was running the Simplesynth application with the input set to the IAC Driver, to be able to hear the notes