When I code in Haskell, the first and most important step I make is to create rich types for the domain I'm working in. If you disambiguate your types, your code becomes more readable and the compiler is a lot better able to help you out when you make a mistake.
For example, rather than having an Invoice with a status field of Text or String, I have a type InvoiceStatus = Paid | Unpaid | Void. From there, you can write a very precise parser that takes exactly what you want and nothing else. When I apply this approach to each component of the thing I need to parse (or do it generically even), I don't really find myself having to munge javascript types into my data structures.
To expand on that, these "custom" types are really the only time you have to do any extra work for support with aeson. If you leave your status field as Text or String it's implicitly supported.
That said, aeson support for nullary types (i.e. types that hold no "extra" values, like InvoiceStatus above) is trivial and the types make a huge difference in the rest of your code.
I own the original inPulse and the charge lasts about 1 day. That's the main reason why I stopped wearing it. Definitely interested in something I can let go longer with an always-on screen. I'm not a fan of thinking about my watch's charge level.
While I'm not disagreeing with this, I wonder if it will impact the users of Milk Inc tools' willingness to participate in future projects. For services which run off of user's submitting content (reviews in the case of Oink), I'd imagine users may become hesitant to contributefor fear of the project (and thus their work) getting shot in the head.
I'm not saying terminating a project that didn't meet expectations is wrong, I'm just curious about the lasting implications.
I was one of the (seemingly) few people using Oink in Orlando, FL, and I thought it was great. I'll certainly be more hesitant to create any more content for a Milk product because it kinda feels like I just fired off information in to a black hole.
I figured it would be killed after how little people in my area were using it and I knew what I was getting in to, but I think I'll still let other people be the test dummies next time.
I'm having a hard time understanding the intent behind "You shouldn't need to know Haskell". Do you mean in order to complete the tutorial and understand what Yesod does? That's probably true. Being someone who's been studying and using Haskell in personal projects for the past maybe 10 months or so, Haskell's syntax and fundamental design decisions (while spot on, in my book) are different enough from most programmers' skill sets that I don't think they'll make it very far writing a non-trivial Yesod app without knowing Haskell. I'm fairly proficient/enamored with Haskell now but I'm certain I would have crashed and burned if I got my start trying to learn Haskell from Yesod.
My first dose of Haskell was attempting to write an XMonad config. That turned out to be a frustrating, several hour long ordeal for me that had me write off Haskell as undecipherable, alien hieroglyphics for quite some time after that. I'd urge anyone reading the tutorial who likes what they see to put in the hard time to get a handle on the language, understand what its good for and what it isn't and then return to web programming with it.
I am sorry if I didn't made it clearer. Of course, you don't need to know Haskell to follow this tutorial in particular.
But it is clear in my mind, you must know Haskell to do something useful with it. And in particular, make a web application, even if using a web framework.
As you stated, Haskell is not a language you could learn in 3 hours like I learned the bases of Python. It takes a very long time to learn, particularly when you're not used to functional programming.
But an intent of this tutorial was to promote Haskell. Clearly, if someone want to do something a bit more useful, he will very soon realize he must understand Haskell.
I added a specific advice in my conclusion similar to yours and pointing some essential resources.
Many people saw Ruby for the first time when they looked at a Rails tutorial. Many people see Python for the first time when they look at a Django tutorial. In both cases, you'd still need to learn more about the language to do something useful. I think the disclaimer "You shouldn't need to know Haskell" just means that the same thing works for this tutorial: you don't need to have seen Haskell before going through the tutorial, because you'll learn enough to follow the tutorial, even though you'll need to learn more later.
There's a 2009 Documentary called Vanishing of the Bees that covers this. It was quite alarming to see the impact it had on beekeepers in the US. If you have netflix, the doc is available for streaming and is well worth the watch.
I watched "Colony" also on Netflix which related the problem as well. But dramatized a bit too much by focusing on this one family.
Regardless, it was interesting to see how beekeepers were basically positioned against the legal team and the lobbyists of the chemical companies. The position of the chemical companies was basically to answer the problem with a question "Why would we knowingly damage agriculture in this country, we want agriculture to do well long term as well, right?". A very clever PR trick. They also said they conducted their experiments but found no positive results that links honeybee deaths to their insecticides (big surprise there).
Like this email, I've noticed Louis' personality permeates the whole experience. An interesting little tidbit: the password emailed to me after purchasing to access my content didn't work. I clicked the button to reset my password. I received an email with the text:
Apparently you forgot your password? Ok, so here's your new one, stupid:
My generated password was prefixed with "idiot.THENEWPASSWORD". It's little touches like this that I find really nice.
Also, needless to say, I would buy one of his specials in a heartbeat should a similar offer come up in the future. I watched the special last night and it was outrageously funny.
I wonder if the first passwords are deliberately wrong so that peope will request a new one (if they revisit instead of downlaoding/streaming immediately and never going back as they have no need to) in order to be insulted. Its the sort of thing I'd do...
This service may serve a purpose for men as an early indicator that their SO has communication issues. I cannot speak for anyone else but I for one would not want to be in a relationship where my SO was spying on me like she was my probation officer.
It is to some people - I know I'd be bothered by it. Mostly due to my own insecurities. I'd wonder "Why?", and wonder what I'm not doing that he wants.
For some it might been seen as a light form of cheating.
I think that it's a sensitive enough topic that if you're doing it without your partner knowing that you're likely treading into a potential problem.
(For the record, I feel like searching your partner's computer for anything is a gross violation of trust - more so than watching porn without the other person knowing)
It depends on what kind of relationship you have. Traditionally, and what seems right to most people is a relationship with a level of commitment towards the other. I'm not saying this is always true, but that level of commitment does have benefits, usually resulting in a stronger relationship because of the trust developed.
Associating watching porn with lack of commitment sounds like something out of the 50s. Nobody(*) contemplates leaving their SO for some person on a website (or in a movie, or on TV), and porn isn't an exception.
But actually, I wouldn't be surprised if somebody broke off an existing relationship to pursue someone they were fantasizing about online. If they're unhappy in their current relationship, online fantasy is a form of escape and leads to eventual idealization. By comparison, the real person can't compete as their flaws are evident.
Dime-store psychology perhaps, but on these topics nothing surprises me.
Probably closer to more like something out of the 90s. Also very much age / culture / internet age related.
I think many of the attitudes regarding porn has changed simply because it became so ubiquitous that it changed culture, not that culture somehow grew up and grew to embrace porn.
I'm fairly new when it comes to working with Erlang. We've developed an application we use internally for essentially doing distributed, fault-tolerant timers.
I, however, would caution against some of the platitudes you use about it being the future of concurrency. I also think it is kind of silly to imply that a coder isn't "worth their salt" if they aren't learning Erlang. It isn't a panacea. If you read some modern Erlang guides like Learn You Some Erlang, for example, you'll note that a responsible advocate of Erlang will caution against drinking too much kool-aid. Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching.
Developers worth their salt will not just hear the word concurrency and start writing everything in Erlang. It is much better to consider the problem and ensure that the problem domain matches Erlang's particular strengths.
I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions. We actually ended up needing to start a support contract with Erlang Solutions themselves to help us demystify getting a sane deployment process going for our app. This was an expensive endeavor. Yes, it was primarily because we were new to the language, but it also had a lot to do with a lack of community documentation/discussion about deployment procedures. I won't even get into the joy of trying to decipher Erlang's famously cryptic crash reports/stack traces.
tl;dr: Erlang isn't concurrency pixie dust. A developer isn't a failure if they aren't currently learning it, nor are they a success if they just decide to use Erlang for every class of problem. It is an interesting language to work with and solves certain problems very well, others not so well.
I think Erlang is great, and have been a big fan for a long time, but as you say, it has its limitations and it is nice to have a quite different alternative with Go for concurrent systems.
> Erlang, for example, is admitted as being a poor choice for lots of string manipulation because of the way strings are implemented in the language. I believe that same guide mentions that it may not be the best choice for heavy number crunching.
This are two areas where Go has a big advantage over Erlang while providing an equivalent (although slightly different and more CSP-ish) concurrency model.
> I also want to mention that in my experience, Erlang applications are pure hell to deploy for people who don't have years of OTP deployment under their belts. So much of having a manageable Erlang app depends on the developers being well versed in a lot of subtle, and very easy to get wrong conventions.
Another big contrasts with Go, where you just build a static binary, copy it to any target systems, and run it.
I disagree with Erlang "deployment hell".
The full OTP deployment process is too heavy for anything non Telecom or Embedded. But for regular Internet applications, you just creating self-containing tar.gz file with OTP release using "rebar generate".
Then you upgrade your cluster in round-robin manner.
There are some open-source tools to automate this process.
But it's easy to use any Fabric-style tool or just your own bash/ssh scripts.
If you're not using erlang because you don't like its string manipulation capabilities, then you're being foolish.
If performance is critical, you can do the string manipulation in C and plug it into erlang fine.
If you're trying to do concurrency in most other languages, then you've probably made a foolish decision, unless those languages are also message passing actor model.
Claiming that deploying erlang is pure hell is FUD, or an example of how you're doing it wrong and really shouldn't be commenting on erlang.
You're seriously proposing writing string manipulation code in C and plugging that into Erlang? And then telling other people (after quite well reasoned answers obviously based on actual experience) that they don't know what they're doing?
Have a downvote.
There are plenty of good solutions for concurrency. Erlang is one of them. Other message passing actor model solutions are another. Clojure would be another. Using Java's excellent concurrency libraries would be another. Go is reputedly another, although I haven't used it. There is no magic bullet, but there are plenty of good tools of different types.
I'm not convinced the Actor model is a concurrency silver bullet. I'm using it in Scala, and you still have race conditions and potential deadlocks to worry about.
It helps to 'segregate' your application so it's easier to reason about what data could be a race sometimes, but for me it just made multithreaded applications a little less hard, not easy.
The way I like to put it is that it takes concurrency from an exponential problem that no human can actually solve, to a polynomial one. It isn't a magic bullet, because nothing can truly fully abstract away concurrency, but at least it's in the class of sane answers.
This is grounded in the arguments about how many paths through your program there are; with conventional threading, it's exponential since at any time any thread may reach out and twiddle with something another thread has. Things that isolate threads confine interactions to just their communication points, which is more polynomial than exponential. You can still get yourself in trouble, but at least you don't start out in trouble.
A secret of rock solid concurrency is communication, but there are many sane concurrency models. Consider people are already fast efficient safe sane code over hundreds of cores on GPU's which looks nothing like Erlang. Still, when you actually start to care that your concurrent code is accurate not just FAST you need to validate your calculations and Erlang does little to help you there. So sure it's better than C, but turn up the memory errors and it still falls down hard.
It makes perfect sense not to use Erlang because of its string manipulation caoabilities if you're used to working with strings.
The programming languages we use and the problems we solve with them will influence the way we think about building applications in major ways. In many day-to-day operations, you won't feel the need of powerful string handling. Then at some point you find yourself handling unicode and you find out that the support for unicode is only partial, weirdly documented and somewhat confusing. Then you wish, for that string-heavy problem, that you had a language that handled them better.
Of course you can get Erlang to communicate with other languages, but it's not the same; it's more tedious, comes with its own share of problem.
Erlang is only one of the many available concurrency models: Actors, CSP, Join calculus, models based off pi-calculus, etc. Erlang's model has grown from pragmaticism, but is far from the only good option out there.
Deploying Erlang isn't especially hard (hopefully less than before after re-documenting a few features like releases and relups), although live code upgrades of releases is way too complex for the common project without some solid OTP experience.
Every suffiently large Erlang applications include parts written in C.
In our case we do JSON parsing in C, we use ZeroMQ, etc.
When you need save memory and/or CPU when processing strings, you can use binaries, IO-lists and in some cases even atoms. The default string representation as linked-lists is good for 50% of applications, but you shouldn't use it when memory consumption or performance is matter.
I'm sure Google considered this but I hope that by default, my feed subscriptions are shared with nobody in my Google+ circles and that I have to opt those people in. Doing otherwise would be the equivalent of dumping the contents of your browser bookmarks for all your friends to see. There may be some things people subscribe to that they'd prefer others didn't know about.
sharing is already opt in on Google Reader. So you would have to click "share" and then (most likely) select a circle, there will probably be a default circle but it won't just start spamming G+ whenever you read an article
I realize that. The problem is that they block things by URL in whatever web proxy they use, and if content for Google Reader is coming from a blocked url, it's not going to work for me anymore.
It works both ways; I can actually send mail from my Gmail account via Google Reader, even though they block Gmail. I can't read it, of course, but it's a bit of a hole in their security plan.
Who is they? are you worried about not being able to access reader anymore because access to G+ may be blocked? That is interesting. Do you have trouble with the new share box on google search because it is a G+ product? Where are you from?
Our company gives them money but the main thing is that we have a lot of small private projects that are more like prototypes and will never see the light of day. We are not permitted to open source them and probably wouldn't if we could because they'd be worthless to everyone but us. The pricing plans for additional private repos is pretty steep with github so we had to pay for a crappy repository hosting service to dump all of our second tier projects. GitLab would be pretty neat to allow us to store our second rate stuff on our own servers and the stuff we use every day on github.
Why not use bitbucket.org instead if you have a bunch of small private repositories? They allow for unlimited private repositories, and it has been working quite well for me.
So they re-opened that offer? When they closed it I had to endure about six dire e-mails when all I wanted to say was screw you, I've already re-hosted my stuff.
For example, rather than having an Invoice with a status field of Text or String, I have a type InvoiceStatus = Paid | Unpaid | Void. From there, you can write a very precise parser that takes exactly what you want and nothing else. When I apply this approach to each component of the thing I need to parse (or do it generically even), I don't really find myself having to munge javascript types into my data structures.