ac's comments

First of all, thank you for making and sharing this. I have a few technical questions, if I may.

Does Bearer perform data-flow analysis? If so:

1. Is the analysis inter-procedural?

2. Is it sound? (Does it only report findings that it’s absolutely certain in but missing others; or does it report all possible findings even if some of them report false positives)

3. How are sources and sinks of information specified?

4. I see it supports JavaScript and Ruby. Any plans on adding other languages? Is the current analysis implementation amenable to adding support for other languages?

5. What’s the analysis behavior around dynamic language constructs (e.g. eval)?

6. What’s the analysis behavior around missing symbols/dependencies?

+1 for s2n. It's one of the select few C codebases that is actually a pleasure to read.

I've been using it for a while. It's been the most convenient solution, and worth the price. Before that I used a 3rd party Send-To-Kindle bookmarklet, and Instapaper via Calibre in the past.

Pros:

+ QR-codes at the end of articles to go back to them

+ Clean configuration

+ Scheduled delivery

+ Reliable

Cons:

- Often misses images and, sometimes, even text from the original page. To be fair, I have found to be the problem of every web->ebook converter out there.

- It says it supports Kindle Back Issues, but they don't seem to work for Crofflr ebooks even on a top-of-the-line (Oasis) Kindle.

Matter of taste:

~ I'd prefer for every article to be in a separate book so I can read out-of-order, and delete and bookmark them separately. But the navigation interface within the single book (issue) is very nice.

Does the library export data from the web service or from the device itself? Also, do you know if the device can be prevented from syncing with the cloud?

PS: Thank you for your contributions. I've looked into 3rd party open source sync libraries for activity trackers before, and the state was dire.

I assume you are looking at the table on slide 7. I think that is the percentage of all who completed relative to those who started it, so whether many CS undergrads go intro industry (which is most likely the case) or not is irrelevant. However, I can offer anecdotes from my experience (recent PhD in CS). First, it is usually easy to find good jobs in the industry while you are doing your PhD. I think half of students in my department that did machine learning and computer vision didn't finish their PhD and went off to work at Google and the likes. It is very tempting, because the hours in a PhD program are long, stress is high and money is never good. And many CS PhD end up working in the industry anyway. Second, writing a lot of code isn't necessary if you're doing pure theory --- but even then you might be making small prototypes or using proof assistants, so a no-programming research in CS is rare. Whether you need to master many new skills depends on your background and what you want to do for your dissertation.

Could you, please, explain what .service files are and how they eliminate the need for bash scripts etc? Couldn't find anything in search results.

> As a PhD student [..]. The hiring process we mentioned completely ignores teaching skills [...]

As a PhD student myself, I have observed the hiring process at my department many times. Here teaching experience counts, and teaching skills are evaluated: the candidate has to give a talk, which is used to evaluate how well the person can teach. I'm pretty sure it's the same in other universities.

Also, if you're interviewing for a teaching professor position, then you have to give a mock lecture with actual students in attendance.

I sympathize with your ideals about how things should be, but at some point one needs to accept the reality. There's no way to magically find time in professors' time for a review of papers "out of the left field". There aren't any incentives for that, and I don't imagine any universities investing extra money into that. I mean, most professors aren't formally paid for administrative tasks, unless they hold some kind of official title (Department Director, Dean etc.). What they're paid for is research and teaching.

One relatively easy way to fix that would be to publish reviews along with the papers. While you and I would both agree that many reviews are rubbish, many others still are quite insightful and can serve a more expressive indicator of quality than journal/conference ranking and citation count.

Depends on the publisher. Both ACM and IEEE allow publishing a copy on your website, don't know about Springer or Elsevier. Most authors in CS that I know publish copies as soon as they are accepted for publication.

It's not the departments that pay for subscriptions: it's the universities themselves (usually, the library).

> * Publicly recommend to all scientific boards that the hiring process should judge applicants by the merit of their publications, not by their journal's ranking.

Unfortunately, that's just not practical. Science has become (always been?) so hyper-specialized that adequately judging impact of publications outside your speciality, let alone your field, has become very hard, unless it's a Huge Deal, in which case nobody would care to gather the board for the hire. (I'm talking about Computer Science, no idea about other fields.) Basically, you need to follow the current state-of-the-art to adequately judge the novelty, importance and merit of the paper. You might have a person from that field on the board, but that's unlikely -- departments usually try to diversify the range of research directions in their hiring decisions.

But, suppose, you require the board to carefully review all the publications on their own merit anyway. Suppose that reviewing one paper thoroughly takes at least 4 hours --- more, if you don't know anything about the area. And, say, an average applicant has 20 papers. You need at least 80 hours to judge the merit of one candidate's publications. Considering that hiring committees consist of professors, who are often already overloaded with teaching, research and administration, it's simply unrealistic to require them to spend so much time on one candidate.

Journal and conference rankings are helpful, because the ranking usually correlates with the quality of the peer review (though, recently, there have been some embarrassing examples to the contrary). So, the hiring committees can and do make use of rankings and citation counts as a proxy measure for the quality and merit of the candidates' publications. That might not be very thorough, but, at least, it scales.

Not the parent poster, but I have custom agendas too. The two I use the most are "Today" and "Weekly review". "Today" has the ordinary day agenda block, but sprinkled with habits tracking, as well as the separate list of NEXT actions, sorted by priority and complexity. The view is structured to answer the "What should I be doing right now?" very quickly.

The "Weekly review" is made for a (slightly tweaked) GTD review. It allows me to review all the finished tasks in one plays, which I archive or refile for future reference (this is to mitigate the downside of mixing TODOs with notes --- you might lose important info when you archive a DONE task). Next block reviews the tasks where I'm waiting on something or someone. I can update their status and close them if whatever I was waiting on has happened. Then there are new tasks from my inbox (org-capture) that I refile and assign priorities/schedules/deadlines too. Then there is the agenda for the next week, so I have a chance to plan my work and schedule more tasks if I have the capacity. Then there is the review of all the NEXT actions. Then there are the SOMEDAY tasks, which I review and occasionally promote to TODOs or NEXT actions.

I'm also tinkering with agenda views that give longer term perspective for project planning. However, I'm already running into the limitations of agenda views.

Most of it is inspired by Bernt Hansen's (cited by the OP) and Sacha Chua's configs, though they are doing even more sophisticated stuff at times.

> fmap has a tight relationship with <$>

Yup, it's really tight: <$> is fmap

> Am I the only one who noticed they had articles published in August 2014 on that site?

It's probably the papers that have just been accepted for publication, but haven't actually been published yet. The submission-reviewing-publication process is very slow and usually takes at least 5 months in CS conferences. So, many authors make the papers available right after they get an acceptance notification from the program committee. So, my best guess is that the publication date refers to the date those papers would be published officially.

>> I'm kind of shocked there hasn't been a horrified response from HN Haskell fans.

"What an ignorant fool?! How could he abandon the holy grail of Haskell?!" -- like that? :)

For someone who wrote a lot of compiler and program analysis code in Haskell I can hardly imagine myself writing the same in C++. That said, I can totally understand the author's perspective. As the author writes, "I really wanted to like Haskell. [...] But when it comes down to it, I am an object-oriented programmer, and Haskell is not an object-oriented language." And I think that's the core of his troubles. I can imagine it's hard to write Haskell with an OOP mindset and expect it to be easy. I'm not saying pure functional programming is superior to imperative object-oriented programming -- they are just different and require different mindsets. Before I learned Haskell in the university the only language I had done any substantial amount of programming in was C++. And I had to make quite a switch in how I think of algorithms. I remember a lot of my classmates struggled with writing even the simplest programs in Haskell. But after some time I've really started understanding the Haskell way of thinking and, to me, it's easier to program in this language than in C++ which I regard as unnecessarily verbose and baroque.

Personally, I wouldn't even think about writing a compiler in C++ unless I was feeling masochistic. That said, I have never written a compiler in C++. So, should my experience in writing compilers in C++ have been greater and my experience with Haskell lower, it would have made sense for me to use the tool I knew how to use best (C++). Since I don't know how to write a correct compiler in C++ as fast as in Haskell, the only feeling I can express towards the author is pure and unadulterated awe.

PS: On that note, I've been shocked to discover that a horrified response from Haskell fans is expected. Haskell community is one of the friendliest and non-opinionated I've known, so I wonder why Haskellers are perceived as being akin to closet trolls.

> Maemo/Meego wasn't really an option.

Now, why wasn't it? It was a solid OS, and there were two great products running it (N900 and N9).

If you have time, Steve Awodey's book "Category Theory" is both beginner-friendly and helpful. You can get a PDF of an early pre-print online. He covers monads towards the end. If you are an experienced Haskell programmer, I've seen a few "Category Theory for Haskell programmers" tutorials around. That all said, I don't think that knowledge of Category Theory is a prerequisite to effective programming in Haskell (or any other language that features monads).

Yes, I think you should avoid Haskell (and any language with managed memory) on embedded systems or in very performance critical applications. Beyond that, it's going to be a choice of whether there are enough well-supported libraries that help your cause versus some other language. It would help to know in what domain is your new project is going to be.

You've mentioned web apps, so, to be specific, I think the Haskell web app frameworks (Happstack, Yesod and Snap) are mature. There aren't nearly as many utility libraries, as there are, say, for Rails. But that, in my opinion, is compensated by greater correctness guarantees and performance.

I'd encourage you to join the haskell-cafe [1] mailing list: it's a great place to get help if you get stuck.

[1] http://www.haskell.org/mailman/listinfo/haskell-cafe

> Instances can't be explicitly imported either.

You can import only instances by saying "import A.B.C.Instances ()" where A.B.C.Instances is the name of the module where the instances are defined.

Depends on what you are doing. The library eco-system used to be a weak link in Haskell, but I see it improving. To clarify, there were (and still are) a lot of broken and/or poorly documented and/or unmaintained libraries on Hackage. Or several libraries for doing the same thing where there is no indication of which library is the best choice. I suspect that is, to some degree, the case in any open-source eco-system, thought. Recently, though, thanks to the effort of the giants like Edward Kmett there have been an influx of great well-documented libraries on Hackage. And of course, you are welcome to contribute new packages/improvements to existing packages.

Working with DBs is easy, especially if you use HaskellDB. There are bindings for non-relational DBs, as well as a DB written in Haskell (acid-state).

As for the language itself, you might find it tricky to develop computation intensive applications with large run-time data-sets due to garbage collection (but that is true for any garbage collected language). Other than that, it's one of the best performing languages in the Debian PL shootout. And the fact that concurrency is (comparatively) easy means you can make use of those extra cores.

Monad transformers and monads are fine, you just need to learn how to use them.

To sum up: it depends on what you do and what you consider a "real world application". Might be a good idea to elaborate. For example, are compilers, games, web apps, automated trading systems, android apps considered "real world"? Because any of these has been done in Haskell.

Well, I'm exploring the process myself. From what I understand, you need to patch the CM source tree for your device with the patches found at [1] (choose the branch that corresponds to the correct Android version; CM 10 is AOSP 4.1.2, CM 10.1 is AOSP 4.2). Then build the source tree and install on your phone, similarly to how you did with the unmodified CM10 firmware. If anyone has more experience with getting OpenPDroid to work with CM, please, correct me if I'm wrong.

[1] https://github.com/OpenPDroid/PdroidBuildPatches/tree/4.2.0