Tag Archives: computing

Computing

Functional Programming Definition

1 Comment

A dozen years ago, when I was first investigating functional languages, the distinctions between functional and not were much more apparent. Functional languages had functions as values and parameters, closures — an inline-defined function that captures (closed) context for use in future invocations, and if not outright prohibiting variable updates most of them discouraged programming styles that did variable updates.

Today, most new languages are a thorough mix of imperative, object-oriented, and functional styles. Functions-as-parameters, and closures (or something roughly similar) are as common as the procedural paradigm in the 90’s. However, the one key point that has been largely missed is the discouragement of modifiable variables. The former two styles — imperative and object-oriented — basically require it.

As a result, we’re left with programmers today making a lot of the same non-functional mistakes of years past, and the software is little better for it.

Therefore, my favorite definition of “functional language” is what is more commonly referred to as “pure functional” — languages that do not permit side-effects (state changes). This idea breaks down around the edges of software design, and that’s where a lot of diversity among pure-functional languages can be found, but it is the property that gives the functional style the majority of its benefits.

When we imagine the intricacies around implicitly changing state as part of a computation in systems that are large and separated, I think we should begin to understand why Everything is Functional.

Computing

Everything is Functional

1 Comment

At a high enough level, all computing is functional. If your language isn’t functional (state-change and side-effect free), your process is isolating it. If your process is modifying global state, then your hypervisor or individual machine is isolating it. If your machine is working with a cluster of machines to maintain and modify global state, then all other machines not in the cluster work in isolation.

The model of global state is a difficult one to maintain as scale increases. The time to synchronize data grows and the number of complications due to stale data gets worse. At the largest scales, the distinction between database and communication layer (think pub-sub) breaks down, and they effectively become one. This is the model of tools like RethinkDB where the query becomes an asynchronous request for updates to a particular subset of the data model.

The latest software modeling paradigms make a point of restricting state to a locale via microservices. Each microservice is allowed its own state, but communicates with all other parts of the system via a common message bus. Tools like Storm and Spark specialize in connecting these services together into a larger dataflow model.

It makes sense. Physical locality is guaranteed to eventually constrain software, regardless of the programming models we’ve gotten away with in the past. I think we would do well to recognize that, when stretched to the largest scales, software is relatively small units of computation and the data flowing between them (just like hardware). Aligning our heads, tools, and techniques around this model is likely to yield the best results long-term.

Pick up and learn a functional language today!

Haskell
OCaml
Scala

Ergonomics

User Interface Smorgasbord

Leave a comment

I’m tired of user interfaces. Most of them are clunky, poorly implemented re-incarnations of better interfaces past. Some tools do a really good job, but they aren’t readily re-usable. Some apps have great data models but no way to effectively use them. Way too often I find that I want to use one UI with another app’s data, but alas.

I should say that given the choice, I typically prefer the command line. That’s probably atypical of most users, but most users probably don’t realize what they’re missing. The power of a bash one liner is tough to beat — offering the composition of numerous single-purpose apps in ways that regular GUI users might never imagine. I often think it would be helpful to be able to have standard ways to interact with GUIs programmatically, and I know there are probably techniques and tools for doing so, but it seems like a path fraught with peril.

Standardizing Between Applications

The web browser did a tremendous thing in terms of partially separating the UI from the application data model. Every app developer is allowed to take advantage of or is otherwise forced to consider:

  • Standard navigation: forward, back
  • Anchors/bookmarks: Copy-paste URLs
  • Page searching: single-page only, but ubiquitous
  • Standard page structure, styling, and activity

This has made for an improvement in UI consistency that might have been difficult to envision otherwise.

Windows 8 and 10 made a move toward more consistently applied UI features via their “charms” interface. I thought this might be a good idea, but I never got around to trying it.

More Multi-Purpose UIs

I believe this move should continue and to a drastic degree. When I think about the types of data structures that I regularly deal with, I usually can’t come up with many more than ten (though I may not be all that imaginitive):

  • Plain text
  • Tables
  • Trees
  • Graphs
  • 2D maps
  • 3D maps
  • Audio
  • Video
  • Arbitrary data
  • Collections of the above

There are certainly a large number of variations on each of these, but I think this group captures the general categories — “arbitrary data” being the catch-all, of course. Step one: find a set of adapters that can represent most of the data formats that I care about as one of the above.

What kinds of things do I tend to do with my data?

  • Inspect/view
  • Search
  • Navigate
  • Edit
  • Diff
  • Transform

“Transform” being the bucket for “all the ways in which I could change my data”. These are innumerable, but also not necessarily interesting enough to warrant consideration here. Step two: find a UI tool for each of the above data categories that performs each of my standard actions. Granted, worst case this is roughly 50 tools, but I tend to think that some of the functions could overlap and in some cases, like audio diffing, they may not be all that interesting.

This is an approach I’ve been slowly pursuing for a couple years. I plan to make some of my work available in the near future.