--- /dev/null
+---
+postid: 03e
+title: Glasgow Haskell Compiler no longer suitable for teaching
+date: November 8, 2015
+author: Lucian Mogoșanu
+tags: tech
+---
+
+While recently fiddling with the latest version of GHC[^1], I noticed that the
+standard [Prelude][haskell-prelude] library now contains a few rather contrived
+constructions. For example, this is what querying `foldl`'s type yields:
+
+~~~~
+Prelude> :t foldl
+foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b
+~~~~
+
+This change is the result of the so-called "[Functor-Applicative-Monad
+Proposal][famp]" (AMP), and more specifically the "[Foldable/Traversable
+Proposal][ftp]" (FTP), both being proposed and developed to meet a few very
+technical issues regarding the standard library. More precisely, the `Monad`
+type class naturally inherits `Applicative`, which in turn inherits `Functor`;
+additionally, according to FTP, the `Foldable` and `Traversable` classes should
+be moved into the base library, thus implying that certain functions, such as
+`foldl` above, are then given their most general type signature.
+
+These proposals have a few -- again, purely technical -- advantages, the most
+notable of which being orthogonality. Previously, maintaining for example
+`Monad` and `Applicative` as unrelated classes would have required programmers
+to provide implementations for both `pure` and `return`, despite the fact that
+the two functions have equivalent semantics. Similarly, providing `Foldable`
+and `Traversable` as part of separate libraries resulted many times in name
+clashes between the standard `foldl` and the one in, say, `Data.Foldable`.
+
+The major downside of this change is however that it makes Haskell completely
+unsuitable for teaching functional programming in undergraduate courses. To
+give just an example, the [Programming Paradigms][pp] course (held in Romanian)
+at [UPB][cs-pub-ro], where I'm a teaching assistant, introduces functional
+programming using Racket[^2], then focusing on Haskell to illustrate type
+systems. By taking a look at the course's syllabus, the astute reader would
+notice that type classes are the very last topic approached by the course.
+
+This begs the question: how would the average teacher would thus use Haskell to
+explain simple concepts such as folds on lists? and furthermore, how would
+fundamental principles such as "types-as-documentation" be illustrated using
+the mess of a signature that GHC 7.10 (and later versions, I presume) provides?
+How is this even possible, when one of the first type signatures the student
+ever reads begins with `:: Foldable t =>`?
+
+To further twist the knife in this wound, it seems that trying to use standards
+such as Haskell98 or Haskell2010 is now impossible. Previous versions of GHC
+include a `haskell98` alternative to `base`, which makes it possible to run
+GHCi the following way:
+
+~~~~
+$ ghci -hide-all-packages -package haskell98
+~~~~
+
+Searching through the mailing lists to find if I could make this possible in
+the new GHC, I find out that the developers are planning to drop support for
+the two standards altogether[^3], because "nobody uses them anyway". This is
+the same kind of idiotic attitude that projects such as systemd are trying to
+push, and while [they're winning][systemd] in the face of community
+resignation, that doesn't make these changes any less outrageous.
+
+Right now, Haskell teachers are left with very few alternatives:
+
+* Putting political pressure on the GHC community to provide support for
+ Haskell98/Haskell2010[^4],
+* Reviving [Hugs][hugs], or
+* Replacing Haskell itself with a purely functional language that is more
+ oriented towards teaching[^5].
+
+It's nothing but bitter irony that Haskell, a language praised by the
+greats[^6], the language for which the term "[avoid success at all costs][spj]"
+was coined, is now falling prey to its own popularity, thus becoming in a way
+the C++ of functional languages[^7]. If that's the case, then sure, it's time
+to move on.
+
+[^1]: 7.10.2 at the time of writing.
+
+[^2]: It's actually mostly Scheme, using Racket specifics where it's more
+convenient to do so.
+
+[^3]: [The future of the haskell2010/haskell98 packages - AKA Trac
+#9590][haskell98-2010]
+
+[^4]: Erik Meijer is one of the people who seem [to be doing
+that][meijer-twitter], and he's [not the only one][lentczner].
+
+[^5]: Miranda?
+
+[^6]: Dijkstra himself wrote recommending the [replacement of Java with
+Haskell][dijkstra] in introductory computer science courses. But "trends" seem
+to be going [the opposite way][mit-python].
+
+[^7]: This is not an evil in itself, it just shows that the language is mature
+enough that it's starting to gather clutter, not unlike newer versions of C++.
+The chief difference is that C++ is standardized, so that code written twenty
+years ago still compiles. Regardless of this, both the existence of clutter and
+the so-called "ossification" mean that the language starts losing relevance as
+an instrument of research, and newer languages start becoming more interesting
+in this respect. And programming language research is not doing particularly
+badly at the moment.
+
+[haskell-prelude]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html
+[famp]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
+[ftp]: https://wiki.haskell.org/Foldable_Traversable_In_Prelude
+[pp]: http://elf.cs.pub.ro/pp/
+[cs-pub-ro]: https://cs.pub.ro/
+[haskell98-2010]: https://mail.haskell.org/pipermail/glasgow-haskell-users/2014-September/025280.html
+[systemd]: /posts/y01/02b-how-and-why-systemd-has-won.html
+[meijer-twitter]: https://twitter.com/headinthebox/status/652807907352911872
+[lentczner]: https://mail.haskell.org/pipermail/ghc-devs/2015-October/010068.html
+[hugs]: https://www.haskell.org/hugs/
+[dijkstra]: https://www.cs.utexas.edu/~EWD/transcriptions/OtherDocs/Haskell.html
+[spj]: https://www.youtube.com/watch?v=iSmkqocn0oQ&feature=share
+[mit-python]: http://lambda-the-ultimate.org/node/3312
--- /dev/null
+---
+postid: 03f
+title: Android, the bad and the ugly
+date: November 22, 2015
+author: Lucian Mogoșanu
+tags: tech
+---
+
+The field of operating systems engineering has been completely stuck in a rut
+in the last few decades: kernels [aren't what they mean][os-design], Unix is
+*the* standard -- and mostly rightfully so -- and only few people[^1] think
+beyond the current engineering mess and try to bring something on the table to
+solve actual real problems that should be solved by, oh, I don't know,
+yesterday.
+
+Android in particular is a half-baked idea initially designed for mobile
+phones and later extended for tablets, phablets and other devices for
+idiots[^2]. The fundamental idea itself is great: an operating system meant to
+run perpetually and provide immediate accessibility to whomever wants to use
+it, as e.g. you may need to be able to answer that phone call right now and
+you need to read that important mail, yep, you guessed it, right now[^3]. Its
+actual design and implementation are however bad, to say the least, and unlike
+other open source software such as, say, Linux, I don't see it growing and
+changing organically in the following years, unless Google decide to give up
+control over it; but anyway, less prophecy and more facts.
+
+Note that this post is the result of years of usage and only because it
+doesn't cover the good parts, it doesn't mean that there are none. No
+improvement ever arised from gratuitous praise, however, so if you see fit to
+apply the same critique to other operating systems, mobile or otherwise, feel
+free.
+
+## The usage model
+
+As it was designed for memory-constrained mobile devices, Android has a few
+neat doohickeys implemented.
+
+Firstly, only one "activity", i.e. an application or part of it, may be run at
+a given time. Secondly, fast application switching is done by keeping as much
+of it and as many "activities" as possible in RAM. Thirdly, the kernel
+implements a "low-memory killer" (essentially a sort of garbage collector
+combined with a caching mechanism) that kills the least recently used
+"activities" when the system runs out of free memory. So the reasoning behind
+this scheme is simple: you start as many applications as you like, and the ones
+you used most recently will actually be kept in memory; the others may end up
+being killed, but everything should be properly saved if they implement the
+save/restore functionality exposed by the operating system interface[^4].
+
+The issue with this model is that it doesn't take into account that the user
+will often end up wanting to use many applications over a small period of
+time. And while I agree that the user shouldn't be bugged with memory
+management issues, killing applications like that is a *major* source of
+non-determinism. Say, you recently ran a game which uses a lot of memory; then
+you run your feed reader and in turn use it to call the browser "activity" to
+read a post; then, after five minutes or so you finish reading, but you find
+out that for some reason the operating system decided to kill the feed reader
+"activity", which is then returned to its initial state, not the one it was
+supposed to be in after reading. Frustrating, isn't it? And all this without
+even mentioning the performance issues caused by reaping memory and re-starting
+the application.
+
+Oh, and heavens forbid you should ever try to listen to music on Youtube and
+use the browser at the same time. No, this won't work, and "implementing it as
+a Service" isn't a solution, because in a sane system not all background
+applications are services. A service is a service, not any application running
+in background, but y'know, actually running and doing useful stuff.
+
+Long story short, if you want me to use your system for general purpose
+applications, make it act like a general-purpose system, not some MS-DOS crap
+on a 80286.
+
+## The architecture
+
+Despite the fact that it was designed for memory-constrained mobile devices,
+Android's architecture is largely distributed: most of the operating system
+runs on top of the Linux kernel, and comprises a run time component coming
+mostly from Java, but it's also made up of various other types of system
+components, such as "services", "managers" and a plethora of other software
+handling everything from displaying the current application to managing sound,
+notifications and other system settings.
+
+This makes Android a very ambitious project, more so that it's been ported on
+a shitload of hardware platforms. At the same time, it makes it a proverbial
+hell of maintenance, compiling and interworking, resulting in zero benefit for
+the end user. Yes, all "modern software" is piled on layers upon layers of
+complexity, but this does not make Android a model for how software
+development is done.
+
+This so-called hell is well reflected in Android's maintenance cycle: new
+mobile devices get the newest version, while old devices are left to rot,
+although that new version of Android should -- at least in theory -- work on
+your crappy old device. This isn't (only) an evil market gimmick on the
+vendors' side; no, the fact is, testing costs, and the pressure of delivering
+even the small yet critical security patch to a million devices is so costly
+that your average corporation can't afford the trouble. And you lose.
+
+## The protection model
+
+I'm only including this because security is such a big topic nowadays; so,
+first, let's get one thing straight: Android doesn't have a protection
+model. Yes, applications are sandboxed and no, you can't exploit Android
+applications the way you used to exploit the old ones[^5], but as far as
+security goes this doesn't really mean anything.
+
+Android applications are subject to this system where the developer uses a
+so-called "manifest"[^6] to describe what permissions the application needs in
+order to use various components, e.g. the accelerometer, the file system, the
+phone dialer and so on. When the user installs or updates the application, and
+exactly before that happens, they're greeted with the list of permissions
+required. At this point, the user has the option to continue installing the
+application or cancel the process; so, what will the user select in most
+cases? Take a wild guess.
+
+This approach has two problems. Firstly, you can't disable permissions
+selectively[^7], so this "all or nothing" strategy is bothersome if you want to
+e.g. use Facebook without letting it send SMSs on your behalf. Secondly,
+despite efforts from the Android developers' part, permissions are not
+granular: "access to the file system" doesn't say anything about which files
+are accessible; making calls or downloading files doesn't impose any quotas, so
+you can download a 200KB application that then eats through your entire data
+plan in five minutes; I won't even go into the web access permissions which
+come as a complete privacy killer, nor into the wakelock acquision which can
+eat your phone's battery without you even noticing, but you get the general
+idea. Basically, all you're left with is trusting the application developers to
+not be malicious or utter incompetents.
+
+Additionally, there's the issue that once an application gets some permission,
+that permission can't be revoked or blocked without uninstalling. All the
+application needs to do is send an "intent" that it wants to use this or that
+and the system willingly gives it, just like that, without asking the user[^8].
+Surely, there are lots of scenarios where this makes sense, but there are
+others where it doesn't, and the user once again loses. Possibly even money,
+the real kind.
+
+If you've been reading this properly, by now you should be convinced that the
+"Android protection model" is a sham. It's a model alright, but it has nothing
+to do with protection nor security. Probably the only good security-related
+thing that ever happened to Android was the SELinux integration.
+
+## Conclusion
+
+If I were a good man, I would write another article with possible solutions and
+alternatives to the current issues with Android. Fortunately for me, I'm not.
+However I can say that whatever change will occur must come from a rethought
+and redesigned operating system, be it for mobile or desktop.
+
+Meanwhile the list could go on. I haven't even touched on the general
+usability issues, as I haven't said anything about power management or the bad
+marketing associated with Android phones, or smartphones in general. You
+probably know about some of those already; my post will only stand as a
+reminder of how mobile operating systems used to look back in 2015.
+
+At the end of the day, it doesn't hurt to take a closer look at what Google,
+Samsung, HTC and all the others are selling you. And by the looks of it,
+Apple are doing the same.
+
+[^1]: You see, no one makes machines, be they physical or purely theoretical,
+only for the sake of making machines. The sole purpose of the machines'
+existence is the well-being of people and not the other way around; or, in
+other words, people matter, machines don't, unless they're useful to us
+somehow.
+
+[^2]: People in the West are clinging so much to the idea that everyone and
+their dog should know how to code, but they sell devices without a proper
+keyboard. Well, no, sorry, that doesn't work. Tell me when's the last time
+some American company came up with a decent laptop.
+
+[^3]: I'd like to see sociologists struggling to measure the effects this has
+on people's lives. But I'm digressing; fast boot times are important for those
+of us who don't drink coffee.
+
+[^4]: Which they very often don't, at least not properly. This is a major flaw
+in Android's design, although the guys who designed this might think
+otherwise. The thing is, you don't usually trust the application to save and
+restore its own state, otherwise bad stuff may, or rather most probably will
+happen to it. If nothing else, this makes application programming more
+difficult, as opposed to what the guys at Google are claiming.
+
+[^5]: Oh wait, [you can][privilege-escalation]. Nevermind. But for the record,
+you almost always can, because most programmers are terribly lousy.
+
+[^6]: Essentially a spec file for requesting resources from the operating
+system. Not such a bad idea actually.
+
+[^7]: They say that the next iteration of Android, Marshmallow. will (finally)
+support this, though, and it will work even for "legacy" applications. I'm
+pretty sure this will come at some cost, we're just not aware of it yet. All
+engineering is trade-off, and software engineering more so, especially when
+done for the purpose of backward compatibility.
+
+[^8]: Oh, and these "manifests", "intents" and whatnot can be hacked, at least
+in theory. It all reduces to editing that spec file, and there, you have
+whatever it is that your "malicious app" wanted.
+
+[os-design]: /posts/y01/03a-the-linguistic-barrier-of-os-design.html
+[privilege-escalation]: http://thehackernews.com/2014/11/billions-of-android-devices-vulnerable.html
projects / thetarpit.git / commitdiff