John DeHope

This style of Every Programmer Should Understand This blog post has been cropping up a lot lately. I disagree with this particular one. Let me try my own hand.

Breaking problems down is the single most important skill of a programmer. I have in mind four different angles of “breaking down”.

First, breaking problems down into their more basic or general parts. As an example, almost all business applications can be re-imagined as “I need a database that we can query and update, while only dealing with relevant business details, and avoiding all the nasty computer bits.”

Second is breaking problems down into sub-problems. If somebody asks you to reverse a linked list, you can do this very fancifully in-place in memory in O(n) time and whatnot. Or you can create a new list, pull items off the back of the first list, and push them onto the new list. This second solution is simpler, more general, and likely slower and offers poorer memory utilization. But at least you have smaller and simpler problems, rather than one larger and more complex problem.

Thirdly, breaking problems down linearly into steps that, when taken, will lead to an acceptable outcome. The classic example of “make a sandwich” can be broken down into multiple individual steps that, done one after the other, yield a sandwich. First get some bread, mayonnaise, turkey, and a knife. Spread the mayo on the bread using the knife. Etc.

Finally, breaking a problem down into all of it’s possible twisty paths. Few things in life proceed down a happy path for long. Taking care to follow the “what if” scenarios and having some kind of mitigation strategy is key. Even throwing up your arms and shouting “I’m out!” is better than not considering unfortunate circumstances at all.

An astute reader will recognize that none of the above really has anything at all to do with programming. This is just how you approach any challenge in life.

Written 2015-07-07.

I’d like to see HTML deprecated and replaced by two then unrelated specs: one for documents, one for applications. I’ll spend some time thinking about the document spec here. The application spec will have to wait for another day.

A purely declarative model, with no dynamic content considered.

A purely semantic model, with nowhere appearing anything like “bold” or “red”.

A style spec which adds formatting and design to the purely semantic elements described in the primary spec. It could be defined as a proper subset of about a tenth of CSS.

A style property which is intended purely as a default or suggestion. The intention is that reader could replace the suggested style with another at will, and with absolutely no fear at all about missing any content.

Very specific and picky rules about the format of the documents, and what the displayed error messages should be when they’re broken. Something like the famous “fail whale” should be against the spec. Likewise something like mis-ordering closing tags from opening tags would be against the spec, and would have a very clear error message that should be displayed in that case.

Every document specifies an exact version of the spec that it is written to. Browsers of this format would need to logically incorporate a renderer for each version they support. There is no “the spec” there is only “the 1.3 spec”.

I’m probably missing some things because I am not a specification aficionado. But I feel like a lot of the rot of the HTML standard through the years is due to the above things not being more tightly nailed down from the beginning, and from the continual struggle for HTML to be both a document format and an application platform.

Written 2015-07-09.

https://www.strathweb.com/2015/01/asp-net-mvc-6-attribute-routing-controller-action-tokens/

Back in the day, folders and file names were your routes. It was a simpler time. Nowadays we of course have to explain to the framework how to do it, often in too-explicit detail. It seems a yearning for the old ways is creeping back into mainstream modern web development. Take this “routing tokens” feature in the upcoming ASP.Net 5. What’s next, an attribute on a class that (via Roslyn) changes its name based on the file the source code is in? The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

Written 2015-07-22.

I’m tired of all this cutting edge JavaScript business. I’d like a book, or blog, or library, or framework, that is last-year-oriented. Something like: based on what we know today, and what browsers have what market share, and what JavaScript features are available, this is the library, or framework, or technique, that we would have used a year or more ago. Then I would use that technique. Chasing tomorrow’s tail is too much of a distraction. I’d rather gnaw on yesterday’s bones.

Written 2015-11-16.

Until ES6 is on a super majority 67% of browsers, it’s pointless to want to try to use it. Polyfills and transpiling? Ain’t nobody got time for that! When I can use let and it’ll just work, we can talk.

Written 2015-11-17.