As some great religions and philosophies of the world have been trying to tell us all along, we actually are living in hell, a hell of our own making.

(As a bleeding heart progressive type, I say that very much tongue-in-cheek vis-a-vie the real issues in the world. But still, within the parochial confines of software engineering, it really is rather depressing to me.)

If I were super filthy stinkin' rich, I would fund a project to make digital back for old 35mm film cameras. I know, it has been tried-and-failed before, I know. But heck! The sensor tech gets ever better and thus it might get ever easier to actually make. Random example: the sensor technology is such that one could even just be videotaping everything coming through, and then pick out capture frames later. Or, have the digital back do that for us, and snap out the non-dark images. Works fine for non low-light long-exposure situations. Or, set the back's ASA to 1000 and then notice when there's non-blackness and get a raw shot, because the film camera is probably set at like 200.

yes!!!

I guess maybe I just want Ceylon?

Networking is crap. I mean, sure, it is amazing that it works at all, but then the ways in which it doesn't work are sometimes really low hanging fruits of utter ux stupidity. A concrete example is my home router for my ISP that is running the DHCP server, and making itself the DNS IP. But then the router flakes out and can't serve DNS requests sometimes. So on my Linux laptop I manually added some public DNS server IPs as backups. But there's nothing built into Android to let me do that.

I <heart> when some software, be it Ubuntu's desktop, or Android's various UIs, draws something that is some cached old image, and then updates it e.g. by resorting or by animating. So that my fingers are in a race with the machine's update. So when I click/tap on what I wanted, it has suddenly changed to something else, a split second before.

How can people do this?

I really just do not get it.

• trying to find "how to do x" so i can learn how to stop x.
• that turns up hits for "how to do x". i guess most people want x.
• so then search for "how to prevent x".
• and get results that are basically "how to prevent x from not happening".

"Meanwhile, doing the "right" thing with a global value is significantly harder. It has to be collected, and passed around with varying degrees of difficulty, and could potentially involve hundreds of lines of code if for instance you need to change the type of what is passed around, which is evidence that this is not a simple problem. Nobody "wants" to use a global variable, but if you make it even slightly more convenient than the local "right answer", whatever that may be for a language, programmers are going to use them. Even Haskellers can succumb to the lure of unsafePerformIO $ newIORef 0."

The nuance I'd like to riff on is that there are Good People doing the Best They Can with the Bad Tools They Gotta Use but even they realize that, "heck this code is most likely going to have to change a lot over time, and reworking the code as you go along to deal with those changes means a lot of managing repetitive ASCII because our languages suck," and so the Siren song to use the global (or whatever other evil shortcut) becomes all the more alluring.

In case you didn't know, I hate to burst your bubble, spoiler alert, the truth hurts will out out damned spot, I'll be blunt: most programming sucks. Both when having to do it, and the end results.

I guess if you watch 'news' on TV then you are already inured / brainwashed / beaten down / trained / withered and probably don't notice, but holy heck: Yahoo's front page with their "news" is just horrible, horrible crap. Thank god for the BBC and even just Google News for being at least slightly less sensationalist.

One thing all sides can agree on: the 'mainstream' media is just horrible, horrible crap.

I might have missed how to do it, since I am dumb and easily confused (and ever more so the older I get, more is the pity for me) BUT I didn't see a way to do e.g. "flow foo.js" and have it not check the other *.js files in there. That is annoying for several reasons. The fundamental issue for me in terms of UX is that I think the more fundamental UI is to require being given a set of paths-to-files to check. The "check all files implicitly automagically" is some weird nice-to-have in my book, and really not the right default at all. But of course it is all kinda subjective. Still... I'm pretty sure I'm right. ;-)

And never the twain shall meet.

"Matthias Felleisen, apparently as a byproduct while developing his dissertation in which he defined relatively well-behaved lambda-like calculi for describing imperative language features (continuations and mutable variables), proposed a formal definition of a "more expressive than" relation between programming languages, building in part on Landin's notion of syntactic sugar. Notable as a rare objective measure in a very subjective area."

I do not think Scala is perfect, but I am always very happy to use the REPL that comes with it when I want to experiment with Java stuff. (I used to use things like BeanShell.) Thanks, Scala!

As a sometimes graphic designer / user interface / user experience / information architect type wanna-be, I have say that I think the colors chosen for the Legoland calendar are kinda outright dumb.

Deals where you sign away the ability to sue and only get to use arbitration do not have to be inherently bad. But I guess 99.five9s% of the time they are, because of how they are set up. As screwed up as the legal system is in the USA, as an end-user I would rather take my chances with it than with the enforced arbitration route.

Thus I would like somebody with visibility to start a service that tells us which companies and products and organizations do not include such evil language in their Terms of Service or whatever. So we can try to see alternatives, and factor that into our decisions.

Something cool about Android (5+, at least, I guess) from a nerd perspective: If you use the official animation system, then the Battery Saver can disable those animations system-wide to save on juice. Super keen!

Well, at least the first instalment of The Mysterious Benedict Society was mind bogglingly good.

I think CHDK is, in a nerdy, hard-to-use way, completely awesome!

(I think Wikia is, in a blatant, obvious way, completely slow annoying ad-bloated browser destroying hell!)

I don't mean to say there is direct cause and effect, but I am pretty sure there is very, very strong correlation: Open Source software generally does not ever really stand out when it comes to Usability or User Experience. If there isn't an already existing commercial thing which has had competition honing it's user interface for the OS folks to copy, then we end up with monstrosities like the original GIMP, or anything related to KDE, or GNOME, or, to wit this evening for me, anything related to trying to stitch up a panoramic photo. (And even when there is something to copy, somehow things get mucked around with enough to make it overall worse, it often seems.)

Of course, whenever anybody attempts to point out all the suck there is some really disturbingly clueless vehement reaction from fan-types claiming that everything is perfectly correct, that everybody should actually want the equivalent of bloody internal guts to vomit out of their computers onto their laps every time they try to Just Get Something Done.

As an erstwhile programmer, I do love me some Open Source! I prefer to run Linux. I pretty much don't trust or really much like the nefariousness or usability of Windows or Mac OS X for use at home, unless it is what I need to get a job done. Not being able to figure out WTF when something is fubar because there's no docs and the thing is closed source is the worst hole to try to dig oneself out of. But my love of FLOSS does not mean I cannot bear witness to the general abomination of i.e. the so-called linux desktops, whichever they are.

Now, I don't want to just complain. I want to know what it is that we as software people can do to make UI and UX something more easy to wrangle. I think fundamentally it is all really hard and so only the people with enough time, which generally means enough money, can ever get around to evolving something that doesn't bare-faced suck. Most of commercial stuff is crap, too! I guess because UI and UX is really bloody hard.

What are the essential complexities of it? Then what are the accidental complexities? I feel like the essential complexities are things like: How much subjectivity there is in usability; The inherent variance in people; The bad training people got using other bad UI memes, getting brainwashed in the process. I feel like the accidental complexities are everything related to software, no matter how wonderful it is purported to be (random e.g. Interface Builder).

Since I am the 2nd type of person, I do not know what the solutions are. I can only point out that we have problems. (The 1st kind of person doesn't see or admit there are problems. The 3rd kind of person can come up with actual possible solutions to experiment with.) So I am doomed to suffer. Ignorance would be blissier.

(The real kicker that tells me humans are frankly idiots when it comes to UI and UX is that even with the much trumpeted and ballyhoo'd touch interface, things! still! suck! C'est de soupirer. Gun in mouth blues.)

I realize I am talking about "first world" problems here...

...but I have to say that I am fundamentally unimpressed with most everything Google does other than maybe Search. Today it is Google Photos / Picasa that is doing its best to create a completely unintelligible, terrible, lame, broken, confusing, slow, uninformative, misleading, random, and all 'round BAD user experience. I literally do not know how somebody could even come up with a plan to actively execute to make things this bad. Nor could simulated annealing find these grossly global minimums in the UX state space. There truly are genius alien PhD's working tirelessly there to invent this pure and utter drivel. BUT HEY, IT'S FREE. (Errr, not! It is called your SOUL, people!)

/venting.

Textbook definition of, "bimodal distribution"? Weird stuff. I guess it is like random psychological conditioning, they want to keep you off guard?! Sorta always giving the monkeys hope their order will be the blessed one.

Godwin's Law #2: "Godwin's rule of Donald Trump analogies."

Software is hard. Really, really hard. You just won't believe how vastly, hugely, mind-bogglingly hard it is. I mean, you may think it's a long way down the road to the chemist -- er, ok, but you know, software is hard.

Unfortunately, part of the reason software is hard is that we, the majority of us, even in software development, do not know how to do it right, or even well. Especially when it comes to the software engineering things that go around the actual core code itself.

Pretty much every software project I have ever worked on or used has been obviously terrible in terms of basic usability, user experience, quality, sanity, cleanliness, etc., pretty much all immediately obvious within the first 10 minutes of using it. (That doesn't mean they are all useless projects. Hopefully far from it. They've paid my bills at least. But that doesn't mean they were great, to me, if they had these other issues. So probably there has never been a great project ever, according to me. Like I said: it is hard.)

And I really do indict myself here, not just everybody else in software. :-) By putting this off-the-cuff list up I hope some folks can think about what tools or processes could be invented or refined in order to nullify them. (On which I have my own thoughts, but you can try doing your own 5 Whys on them.)

• Not having anything better than a somewhat mediocre if not downright bad installation experience (e.g. anything written in C or C++ that I have to try to get to build on my machine).
• Purporting to be 'cross platform' but then instead of actually really solving it or at least admitting where it isn't being solved well, just sort of either rationalizing it or maybe really being unable to even see the suck?
• Not spending enough time to get good quality on The Naming of Things. 
• Not having progress bars or verbose modes or any of the things people need when they are trying to figure out WTF.
• Not doing continuous integration.
• Not having 'sufficient' unit tests.
• Not having somebody dedicated to devops on the project.
• Having a checksum for file downloads, but not saying precisely what kind of checksum it is.
• Not managing versions properly (e.g. ending up with a flood of warnings when people run the build, and then you apparently can't do anything about it until some future release because of some versioning nightmare constraint).
• Using some kind of overly fancy web fu on the documentation, such that it even breaks the freaking back button navigation. Let alone looks and behaves kinda crappy.
• Not presenting a unified one-throat-to-choke front to users who just wanna get their work done, not learn the inner byzantine component architecture of your system.
• Not having great documentation. Like, maybe you have a lot of documentation, but I still can't find the answer to my question, or even know how to find if the answer isn't in the docs.
• Letting documentation drift out of date just to screw the newbies.
• Trying to reinvent something yourself as a component in your system (e.g. event bus) when you could maybe have used something that already exists and has miles on the tires and mindshare and S.O. answers and documentation and etc.
• Trying to use communication mediums that turn up less in web search results, because I guess you want people to ask the same thing ever over instead of just finding the answer via e.g. Google+StackOverflow?
• Not using or passing static checks, for example IntelliJ's"inspections".
• (Using any tool that itself kinda sucks. At least try to pick the one that sucks least. (That is, of course, impossible.))
• (Personal bent: using a language that isn't amenable to static type checking.)

Oh. My. God. Apparently by default out of the box the IntelliJ based AndroidStudio helpfully suggests it can remove curly braces around a one-line-block. "Remove braces from 'for' statement."

"When I work on old code, I spend the most time on lifetime analysis when trying to make changes, followed closely by dataflow propagation which informs the lifetime analysis."

A thought occurs to me while trying to learn and use Kivy on Android, via Buildozer: if you are going to have something, be it a configuration script, a build tool, a language, etc., it would perhaps be nice to leverage things which already have well known and well documented semantics.

Thus rather than the buildozer.spec file using heaven only knows what format, use something more standard like JSON or even XML (e.g. how does one break up a long line value?). I know the new cool kids would laugh, but I'd rather have it be based on e.g. Make for Pete's sake. Similarly, rather than making up your own event system, how about find one that is more already long lived and well documented (e.g. what aspects of the event system are synchronous vs. asynchronous, exactly)?

(There's a zillion other things about Kivy and Buildozer that are just terrible, terrible UX, but I'm restraining my whining to this for now, and attempting to draw some sort of constructive lesson from it other than just, "how about you just not suck in the first place?" E.g. if you are going to write a command line tool, what if you made sure the docs matched how it behaved? Gosh. Or that you maybe caught internal errors in a standard way and reported them cleanly rather than letting the stuff leak out like olestra all over my console? Also, has nobody ever heard of showing % progress even in a command line tool? Etc.)

I would just like to go on record as saying that just about every UI I've ever seen for managing web browsing history has been a transparent piece of junk wrt actual UX. I completely cannot fathom how all browsers everywhere (that I've used, and I've used quite a few) get it so blatantly, clearly, stunningly, obviously, terribly wrong. As if the people working on the browsers have never used it themselves.

Having said that, of course UI and UX are hard. Especially when you have some gazillions of users that you have to not piss off with arbitrary changes, even if the changes are for the better. At least, if you are in it to make money.

Some things I would like to see as possible improvements:

• History pull-down/pop-up menus are truncated these days (Chrome, Firefox). I miss the days when it was a scrolling thing. Maybe that was hell for some use cases? I don't get it, personally.
• Full histories in Chrome do not show a useful page title for Google Search interactions. How the hell can that possibly have ever come to be? Utter bare faced insanity.
• Tabbing is hell when it comes to histories. This to me is probably the most can't win thing of it all. Firefox's "Recently Closed Tabs" confuses me. I think I just want everything inlined in my history. Did they have a separate thing because their history menu doesn't scroll? Dunno. Maybe Chrome's "recently closed" vs. "recently visited" is the best thing I've seen so far?

Related is when I start typing an address into the address/search text field. I want the completions to show the root URL of a site first even if I never visited it directly, and then the various sub pages I actually visted.

"Error confinement and recovery are much harder in the virtual worlds of software than in the real world of physical objects."

From Great Principles of Computating.

C++: So close, and yet so far away?

"Here, we will only briefly mention other ways of breaking the C++ type system. These problems are well known and have well-known solutions, so we will not address them here. Misuse of unions and casts can lead to type and memory violations (so follow the rules that prevent that [Stroustrup,2015]). For example, use a variant class rather than a plain union. Out-of-range access and access through a null pointer can lead to type and memory errors (so follow the rules that prevent that). In particular, use array_view and not_null from the Guideline Support Library (GSL) [Sutter, 2015b]. To minimize range errors, we also recommend using a make_array() function that returns an owner> to allocate an array on the free store, rather than using new or malloc() directly. The aim of the Code Guidelines is to eliminate a large range of errors by mutually supportive rules. No one rule can by itself prevent a large class of errors: ban one misuse and others will become popular (this is often referred to as “playing whack-a-mole”). Thus, our ideal is a large set of mutually supportive rules that together deliver type and memory safety guarantees."

"Unfortunately, multicast does not scale socially (a tragedy of the commons) and rarely succeeds across organizational domains, whereas flooding only succeeds when the signal/noise ratio is high." I want somebody with deep pockets to start a sibling internet on which multicast is guaranteed to be supported, no holds barred.

"I should also note that the above is not yet fully RESTful, at least how I use the term. All I have done is described the service interfaces, which is no more than any RPC. In order to make it RESTful, I would need to add hypertext to introduce and define the service, describe how to perform the mapping using forms and/or link templates, and provide code to combine the visualizations in useful ways. I could even go further and define these relationships as a standard, much like Atom has standardized a normal set of HTTP relationships with expected semantics, but I have bigger fish to fry right now."

3.7 Limitations

Each architectural style promotes a certain type of interaction among components. When components are distributed across a wide-area network, use or misuse of the network drives application usability. By characterizing styles by their influence on architectural properties, and particularly on the network-based application performance of a distributed hypermedia system, we gain the ability to better choose a software design that is appropriate for the application. There are, however, a couple limitations with the chosen classification.

The first limitation is that the evaluation is specific to the needs of distributed hypermedia. For example, many of the good qualities of the pipe-and-filter style disappear if the communication is fine-grained control messages, and are not applicable at all if the communication requires user interactivity. Likewise, layered caching only adds to latency, without any benefit, if none of the responses to client requests are cacheable. This type of distinction does not appear in the classification, and is only addressed informally in the discussion of each style. I believe this limitation can be overcome by creating separate classification tables for each type of communication problem. Example problem areas would include, among others, large grain data retrieval, remote information monitoring, search, remote control systems, and distributed processing.

A second limitation is with the grouping of architectural properties. In some cases, it is better to identify the specific aspects of, for example, understandability and verifiability induced by an architectural style, rather than lumping them together under the rubric of simplicity. This is particularly the case for styles which might improve verifiability at the expense of understandability. However, the more abstract notion of a property also has value as a single metric, since we do not want to make the classification so specific that no two styles impact the same category. One solution would be a classification that presented both the specific properties and a summary property.