107 karma · joined January 4, 2012
On the general question: there is an obvious distinction to be made between someone asking you for advice on what they plan to spend the next three years doing, and what they're hacking together on a single pizza-fueled weekend. The latter is a learning experience and even without your advice they'll fail fast if they fail, so don't sweat it.
That may be your perception, but I don't think it's universally true. Ask anyone who's tried to build a project on AOSP ...
I struggle to understand how this can be true, and I say that as a Lisper (spiritually if not currently), because 'this data does something meaningful when interpreted by a computer' is exactly a semantic distinction from 'this other data doesn't'
https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-... # but nothing else in there looks to be any closer either
This is all a completely separate issue from the one of whether replies should be indented under their parent. For my money, this only makes sense if the reply is approximately as long as 'ME TOO!!!11!!!1!' and in the more interesting case that the reply is actually a reply and not just a comment, indenting is the wrong decision. But there is no need to conflate the two: ordering and indenting are independent decisions
I'm pretty sure I could have written the same thing in 2002 except that the list of technologies would have looked different.
If we're talking about userland applications, the Linux kernel A[BP]Is have IME historically been more stable than the Glibc interfaces (which are supposedly the "supported" interfaces) layered atop them.
In-kernel interfaces for binary-only modules are a different kettle of fish altogether.
Particular nits are: - pressing the browser 'back' button triggers an immediate logout - they don't use email for anything except to tell you they've sent you a "secure message" that you have to log in and read - no data export (though there are greasemonkey scripts)
Their customer service I've found to be fine unless you want anything usual, complicated, or to be done in a timely fashion. Much like any large company, really
This approach will be a hard sell for Father O'Reilly and Dwight David "Ike" Eisenhower
Seriously, cooking as an analogy highlights a difference between private recreational practice and public for-pay professional practice. Building bridges, unless you live in a place where everyone has a backyard with a river in it, not so much.
Quite. Does anyone yet make an ereader that can safely and sanely be used in the bath?
This sounds to me like you're saying that the law should reward people for wielding more power (bigger heavier vehicles) less responsibly (driving distracted). A prudent pedestrian will and should be mindful of where he's going and I don't think anyone with an instinct to self-preservation would say otherwise, but shouldn't the law serve the interests of the vulnerable where they conflict with the powerful?
I am reminded of http://philip.greenspun.com/ancient-history/professionalism-...
From a business apps point of view, this is exactly it. You might find that methods are subordinate to objects, but in the business domain itself, the objects themselves are manipulated by processes. It's a whole other layer above the OO layer, and failure to realise this means you either end up with lots of FooManager classes, or you push overarching responsiblities back down into low-level objects that don't really want them, and find you have too much coupling and not enough Demeter
(Of course, you might be writing FooManager classes with this upper layer explicitly in mind - in which case fair enough and you'll probably like DCI. But I think there's still a lot of mileage in plain ordinary functions that don't have to belong to anything)
My estimate is that 98% of all programming everywhere is as algorithmically trivial as calculating a weighted modulo 11 checksum - probably more so - and it acquires its bugginess from accidental complexity due to poor factoring, and from conflicts at interfaces. Test-driven development is pretty good, in my experience, at helping ameliorate both these problems.
Of course, that doesn't mean I actually do it 100% or even 80% of the time. I'm happy to agree that it's no panacea: testing threads and UIs are particular pain points for me, and usually I substitute with either Thinking Really Hard or just Not Changing Stuff As Much
Formal proof for me is stuff I learnt at college, forgot subsequently, and keep meaning to reread up on. Thank you for prompting it back up my TODO list