Continuing with the idea of abstractions, while they're the basis for so many great accomplishments in Computer Science, these abstractions come at a cost. One of Joel Spolsky's great essays is The Law of Leaky Abstractions. In essence, he says that even when you have simplified something by abstracting it out, if the abstraction is non-trivial then sooner or later you'll have to look under the hood and deal with something at a lower level than the abstraction. Thus, the abstraction has "leaked" -- it's not as powerful as it claimed to be.
I'm currently developing a web application. I hadn't done any web development for about 8 years, which is of course an eternity in the web development world. The last time I touched JavaScript I was writing XMLHTTP requests by hand -- now I'm learning jQuery and Bootstrap and HTML5 and Groovy and (my new favorite) d3.js.
When developing for the web, if you ever think "there should be a module that does this," well there is. In my case I combined vanilla JavaScript with jQuery and Bootstrap and d3.js. Everything worked pretty well. Thanks to these libraries it's very easy to quickly create a site that looks pretty and does some cool things. d3 allows you to create graphs that are interactive and in general very visually appealing. I wanted users to be able to choose the graphs' start and end dates in a way that was equally appealing. So instead of having two dropdowns for start and end date, I found a library called jQRangeSlider that, well, uses jQuery to create a Range that's controlled with a Slider.
The promise of today's web development paradigm, while not explicit, is that you can mix & match these libraries to create something really neat. But here's where the abstraction leaked for me. Somehow adding the slider is interfering with d3's animations of the graphs, so when d3 does it's initial fade in, sometimes it stops prematurely and looks bad. And the slider sometimes doesn't choose the dates that I want it to. When I test these features of my webapp individually, they work fine, but combining them caused a leak somewhere and I haven't figured out where it is yet. To be continued. . .
Monday, June 02, 2014
Thursday, May 22, 2014
Abstractions
One of the ideas basic to Computer Science is Abstraction. In my very first Computer Science class in college, we started out learning about logic gates and how voltage changes can alter the flow of current in a circuit. The voltages applied were ~3.0V and ~0V, if I remember correctly, but right away we simplified things by simply using zeros and ones instead of the actual voltages. This abstraction made it much easier to start dealing with the logic at a higher level.
In fact, the gist of the whole class was learning how applying one abstraction after another eventually allows us to use 3rd-generation programming languages (the C language in our case), where the bulk of development work happens today. A 3rd-generation programming language has the attractive feature of portability. You can write C code once and have different compilers translate it into assembly code specific to a certain processor architecture.
To get from electric current to C, we applied the following simplifications and abstractions:
Keep in mind that this was a freshman class; we barely skimmed the surface of what C is, and C is considered to be the lowest-level 3rd-generation programming language. Every other programming class continued to build on these concepts and continued adding more abstractions to the mix. It's mesmerizing to think that ultimately all we're really doing with programming is controlling the flow of electrons through a circuit. Abstractions are powerful. Next time: what happens when abstractions aren't so powerful after all.
In fact, the gist of the whole class was learning how applying one abstraction after another eventually allows us to use 3rd-generation programming languages (the C language in our case), where the bulk of development work happens today. A 3rd-generation programming language has the attractive feature of portability. You can write C code once and have different compilers translate it into assembly code specific to a certain processor architecture.
To get from electric current to C, we applied the following simplifications and abstractions:
- Treating analog current as a simple binary on/off signal.
- Treating logic gates as simple switches that react immediately in response to the the binary signal.
- Combining switches to form modules that do things like compute sums or fetch memory.
- Treating these modules as self-contained black boxes that we don't need to know the implementation details of.
- Arranging these modules in such a way that it forms a rudimentary computer.
- Sending instructions to the CPU first by using raw hex, then by using specific op-codes, then formalizing it with an assembly language that can be used to create entire programs.
- Writing C code that could be compiled (i.e. translated) into assembly before running.
Keep in mind that this was a freshman class; we barely skimmed the surface of what C is, and C is considered to be the lowest-level 3rd-generation programming language. Every other programming class continued to build on these concepts and continued adding more abstractions to the mix. It's mesmerizing to think that ultimately all we're really doing with programming is controlling the flow of electrons through a circuit. Abstractions are powerful. Next time: what happens when abstractions aren't so powerful after all.
Subscribe to:
Posts (Atom)