Ideally, using formal methods [1], one can write a provably correct program. Just because software can have bugs does not mean it must have bugs. Human contract law has no analogue.
Personally I'd be wary of any electronic contract that wasn't formally verified. The DAO exploit is unsurprising.
I set up a FreeBSD box at a computer shop I worked at in high school. We had a T1 and static IP, so I set up some routes to make it internet accessible (my boss wanted to use it to host pictures for his eBay transactions).
I set it up, threw it under a table in the corner with nothing but a power and ethernet cable, and moved on.
I was surprised when 5 years later he called to ask why it had stopped working. I told him where it was, he rebooted it, and it came back.
(My memory was a little fuzzy but I probably set it up in 2001-2002 and it ran until at least 2007-2008)
Does the course cover Functors, Applicatives, Monoids, and Monads? What about other higher-level functional constructs (Arrows, Zippers...)?
From what I've seen, I think Scala is a nice language. One thing I don't like is particularly that it's a bit kitchen-sink-ish: there's a whole lot of syntax and semantics to learn, seemingly due to the OO side of the language. By comparison Haskell is quite simple. All the higher-level constructs are implemented in plain Haskell, so you can easily understand them but thanks to a flexible, uniform syntax, using them doesn't feel clunky.
To me the main reason for not learning FP through Scala, however, is that the community isn't organized around teaching FP in the same way that Haskell is. It sounds like this course is an exception. But otherwise, I found that trying to learn about Monads from the scalaz documentation was not satisfying, and we all know that "A Monad is a Sheep with Curly Hair" blog posts are a dime a dozen (in Haskell and Scala). Learn You a Haskell made the concepts, and also their benefits, clear to me for the first time. Now I'm working through Real World Haskell to build my chops and reinforce my understanding.
While trying out both languages and picking which one to learn, I came across an interesting post on Gilad Bracha's blog which had a lively discussion including a comment by the [claimed] original author of Scalaz [1], which made it clear to me that it would be easier to start in Haskell and move to Scala than vice versa. I think I (and the OP) are both seeking to gain a strong foundation in FP concepts. To summarize, in my experience most Scala resources on the internet (blog posts that come up, etc.) aren't quite as good in this regard; at this point a lot of the Scala programmers using these techniques are probably Haskell programmers anyway.
That being said, the internet is a huge place. If there's a Scala equivalent of this post [2] please do share it! I agree with other posters here that Scala has quickly gained a significant amount of industrial acceptance. I'd imagine that I'm more likely to write Scala professionally in my lifetime than Haskell. But I also believe I'll be better off approaching it having learned the FP concepts in Haskell first.
>Does the course cover Functors, Applicatives, Monoids, and Monads? What about other higher-level functional constructs (Arrows, Zippers...)?
Nope. It's very intro level, though the students basically begged Odersky for a part II, and he seemed very open to it.
And I totally didn't mean to imply that I thought people should learn Scala instead of Haskell. I was just sharing a FP resource I found helpful.
Not actually having mastered the higher level functional constructs yet myself, I really don't have a firm opinion about which is the "better" approach. Personally, I've looked at both languages and I know that each helped me understand the other. So if I have any opinion, it's that if you get stuck, it's probably a good idea to approach it from another angle, like the author is doing.
If you prefer something a little more simple, Spectacle is a free program similar to ShiftIt and SizeUp. Basically it's shortcuts to put windows in any half or quarter of your screen, centered, maximized, or send to other monitors.
A Spectacle fork on the HN front page* was the reason I submitted Slate (which I also have no affiliation with).
Now the circle is complete!
The more attention paid to these excellent apps, the better. We sorely need a solid, mature, and open tiler on OS X. Slate is the best option I've used so far, and by far the most thought-out, featureful, and configurable, but it's not perfect. I've run into memory leaks a few times and some of the features are still a little quirky.
I just used Spectacle, it work well. Spectable is helpful and easy to use.
But after that, i try Slate. At the beginning, it quite complex to config. But after 5 minutes, i really love Slate. Slate is more flexible then Spectable.
The same here... Spectacle is very simple to setup... But Slate is so much more flexible. After some minutes I covered all my uses of Spectacle and introduced some new ones (moving windows around is just amazing...). Great job from Slate developers, keep up with the good work!
What functionality does prelude provide? Unless I'm missing something, the website suggests that you can find out by "reading the source."
I had a similar experience once with the emacs starter kit [1]. Though it's a noble effort and probably does have a ton of great features, there are some problems: you pretty much get all or nothing (ESK split it out into a "core" and "per-language" set of libraries but still, there's a lot of stuff) and it's hard to tell which things are emacs builtin and what is customizable. If you disagree with a customization you're SOL; I knew enough about emacs to know that some things had been customized, and I didn't like them, but it was nigh impossible to find out where they were customized and how to turn them off.
It reminds me of the libraries vs frameworks discussion [2]. Emacs works well with libraries (with little elisp functions counting as "mini-libraries"), and the ESK/prelude seem like frameworks.
I'm not trying to pick on these toolkits in particular. They are probably a good way to start out with emacs--I know that the ESK provides a bunch of features to make it more "friendly" out of the box for someone who is coming from something like TextMate.
Most "old-school" emacs people I know have their own .emacs that have accumulated over years and years of trying to solve specific problems or customize that one thing that's annoyed the crap out of them for a while. My .emacs is not pages and pages, but it does have some good stuff in it.
What I'd love to see (and maybe I'm inviting myself to do this) would be a tool (maybe ELPA is this tool, though It's hard to know) which allows you to search for, browse, and install elisp snippets to help you out. ELPA is good for bigger libraries (i.e. major modes) but not for "how do I create an unfill-paragraph function?"
For what it's worth, I've come around to this viewpoint. I rewrote ESK for version 2, and the emphasis was on packaging as much functionality in independent packages as possible. So as of v2, the Starter Kit is mostly just about providing a default set of packages and turning on a few flags that it's just crazy to leave off (like ido). But this way more of the functionality is available to everyone, not just users of ESK.
Anyway, it certainly needs more documentation, but these days I recommend the Starter Kit more as a source of inspiration than something people should just use outright, at least if they're not in a hurry.
Thank you so much for ESK! It's really helped me get started in emacs. Also, could you think about adding undo-tree as a default for ESK? I really feel like that would be a worthy addition.
Glad you like it. I think rather than further development on the Starter Kit, effort would be better spent towards coming up with a good overview of the ecosystem, documenting available packages and how they work together.
And pushing improvements (like saner defaults, and documentation for some of the under-documented built-in packages) upstream to Emacs itself.
For those reasonably comfortable with Emacs, I think you should build it from source, and get into the habit of fixing tiny documentation problems as soon as you come across them. Mind you, I have submitted a couple such patches to the ido built-in help and they have languished un-noticed for 2 months.
P.S. Another thank-you here for the starter kit -- I no longer use it, but I did for a year or so and it did teach me several features I wouldn't have known about otherwise.
Pushing upstream is absolutely the best way to get things more widely used, but unfortunately changes to the defaults often get strong pushback from long-time users. It's a very politicized process; if improving Emacs itself were easier the Starter Kit never would have existed.
"Short Story: el-get allows you to install and manage elisp code for Emacs. It supports lots of differents types of sources and is able to install them, update them and remove them, but more importantly it will init them for you."
I'm one of the el-get devs. I'd say the main advantage of el-get for the gp is that just installing it doesn't modify your emacs config in any way. In contrast to something like the ESK, it is not an opinionated set of defaults to help new users get started. It is literally nothing but a system for installing and initializing elisp code. Many of the recipes provide some initialization code to set up the code being installed, but you can completely replace that code with your own if you don't like it (or you can decide not to use the provided recipes at all and just write all your own).
It's definitely a more hands-on, low-level tool than ESK, designed for those who want the fine-grained control of a manually-built emacs config without all the manual labor of git-cloning (or hg cloning, or downloading and untarring, or cvs checkout-ing) the several dozen elisp repos that your config uses. It definitely matches my use case, which is why I kept submitting so many pull requests that the original author finally just gave me a commit bit :).
Note that I'm not saying that el-get is in any way better than ESK (I've actually contributed to ESK as well even though I don't personally use it, since ESK uses my ido-ubiquitous library). El-get is just designed for a different purpose.
Netflix has algorithms that decide how quickly your next dvd is sent. More accurately, it uses a score to rank the group of people who have the same DVD at the top of their queue in order of who should be allocated the next available copies.
This score is based on a number of factors, with the objective being to maximize subscriber happiness (one example question is whether is it more valuable to have quick turnaround for a frequent subscriber who is already happy with the service, versus an infrequent user who might be on the fence--it is not obvious who would be more sensitive to and negatively impacted by a delay in receiving the next DVD).
(Source: I work with people who previously worked at Netflix. This is not confirmed fact but a loose understanding based on casual conversations.)
Your latter point is a tautology. You win arguments by making really good ones and gaining an advantage over those you don't. By the measure of "able to win arguments" the former viewpoint is better than the latter. If you're using other measures to evaluate viewpoints, you shouldn't do so in the framework of arguments.
Regarding this particular argument and how difficult it is to value ones that sound valid: at the time, this argument was quite cogent and I would have agreed with it. The author made a well-researched, well-formulated, convincing argument. He (along with many others, I'm sure) was later proven wrong, but at the time of the argument, he had a convincing case. Nothing wrong with that, in my opinion.
Often old articles with predictions that turned out to be horribly wrong come up on here. I think that whether the person turned out to be right or wrong is not very relevant. When you make an argument you are stating your opinion at that time, and so the quality of the argument should be measured in that context. That isn't to say that you can just make wild predictions without risk of losing credibility; again, your prediction can and should be measured at the time you make it, and I think that baseless ones should be critiqued appropriately.
"The author made a well-researched, well-formulated, convincing argument."
The author presented a number of fairly well known facts, but made the mistake made by many writers in treating Apple much like Gateway or another PC vendor. He threw out what sounded like facts when talking about PC Vendors having something like a 10% gross margin, but clearly was way off in assuming that figure could be used to predict Apple's sales requirements for profitability. Even most people vaguely familiar with Apple knew it as a premium brand (generally with higher prices and higher margins).
When a writer doesn't know what he's talking about, he can make an argument that seems to have substance by throwing in facts that apply to something else.
Strangely, while the author was aware of problems with Macs sold as commodity items in places like Sears, and he opens quoting Steve Jobs talking about the bad experience of people shopping for computers, he seemed clueless to the notion of stores with good presentation in upscale locations reaching people besides the Mac faithful. So in addition to using PC-vendor margin numbers, he assumes the buyers are only those needing to upgrade from existing Macs.
Not taking into account the stores going after converts shows a serious lack of insight.
From the article:
"What's more, Apple's retail thrust could be one step forward, two steps back in terms of getting Macs in front of customers. Since most Mac fans already know where to buy, ..."
The funny thing is, most of his arguments against success do seem like they'd apply to the Microsoft stores.
Ideally, using formal methods [1], one can write a provably correct program. Just because software can have bugs does not mean it must have bugs. Human contract law has no analogue.
Personally I'd be wary of any electronic contract that wasn't formally verified. The DAO exploit is unsurprising.
1. https://en.wikipedia.org/wiki/Formal_methods