Core Decay is a spiritual successor to the Deus Ex series. It’s a very small team indeed working on it right now. Just one person working on it now, IIRC.
127 karma · joined May 26, 2008
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?
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.
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.
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.
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.
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.
Yup, it's really tight: <$> is fmap
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.
"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.
Now, why wasn't it? It was a solid OS, and there were two great products running it (N900 and N9).
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.
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.
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.
[1] https://github.com/OpenPDroid/PdroidBuildPatches/tree/4.2.0
> Frankly I think that level of privacy control has little appeal to the mainstream.
One might argue that the whole idea of privacy is of little appeal to the mainstream.
> The fake-/no-data approach of incognito (also one of the options that OpenPDroid offers) probably won't cause any compat headaches.
The idea of OpenPDroid is to provide fine-grained permissions together with the fake-data/no-data approach to enforcing them, which prevents apps from crashing when access is denied. And that also enables using the apps even when they might have potential violations of your own privacy policy.
[1] http://forum.xda-developers.com/showthread.php?t=2098156
Sorry for the double post, but I couldn't edit my previous reply anymore. You do have a point about SQL being more amenable to outside queries and reports, especially ad-hoc ones. However, take a look at Data.Acid.Remote (http://hackage.haskell.org/packages/archive/acid-state/0.8.2...) which allows you to connect to an acid store in your running application remotely: however, at this time you will have to provide your own security solution for that. Also, for ad-hoc queries to your data you can, probably, bolt on a dynamic Haskell evaluator/interpreter to your application: see http://www.haskell.org/haskellwiki/Safely_running_untrusted_... for a possible solution. That is, of course, not safe (as in Haskell-safe, see the section about exploits), but neither are ad-hoc SQL queries on your live data store.
Note that the "advanced" guide almost doesn't have any of the HOWTO advice from the OP link, however I've read and would recommend to read both: the "advanced" guide helps put things in perspective.
Also, I think the following quote from the "advanced" version is brilliant:
The human species is addicted to rule-making. Every human activity, without exception, including natural biological functions such as eating and sex, is hedged about with complex sets of rules and regulations, dictating where, when, with whom and what manner the activity may be performed. Animals just do these things; humans make an almighty song and dance about it: this is known as 'culture' or 'civilization'.