mightybyte

> I think it may be a losing battle to show this as a counter example unfortunately.

Yeah, my intent wasn't to suggest that all non-haskell docs suck. But to show how other languages are much more howto/tutorial oriented, which I didn't appreciate as much before I had to look at ACE recently.

I was writing a reply to this, but it got long enough that I decided to make it a standalone blog post.

http://softwaresimply.blogspot.com/2016/12/on-haskell-docume...

Good point. This technique might also help to combat the multiple cameras.

Next up: people start getting into Zuckerberg’s home by holding up a life size picture of Andrea’s face.

We need to be able to talk about them, but it doesn't need to be here. There's value in places where you know you can come to discuss certain categories of things and avoid others. That is what's going on here.

I can somewhat understand this kind of crazy monitoring if the stakes are high and the score on the test is the only or finally-deciding factor. But online tests for interviewing candidates are never that. So in this case I don't think this level of invasiveness is justifiable in the slightest. It's just a screen. Cheaters will get filtered out at the next stage in the hiring process.

> Knowledge-based authentication (KBA) is out

Finally! This is my biggest beef. I've taken to generating long random strings as answers to these questions but in some cases that's insecure too because they present you with a multiple choice set of answers and then it's obvious.

Also glad they're getting rid of ridiculous composition rules, hints, and password expiration.

Yes, I understand the expression. What I'm asking is precisely what things he did that example that he would not have had to do if he were using a dynamic language like Ruby or Python. In other words, I'd like to understand specifically what you think are the extra costs he paid for using a static language.

I don't understand what you mean here. What in particular did you think he was going through just to please the compiler?

I think in this case it's a reasonable approach to writing the `dpll` function because that function doesn't actually care about the specifics of the types. This is a nice example of encapsulation and implementation hiding, a concept familiar to object-oriented and functional programmers alike. He could have easily gotten it to compile by stubbing things out as follows:

    data Clauses = Clauses
    data Symbols = Symbols
    data Model = Model
    isTrueIn = undefined
    isFalseIn = undefined
    findPureSymbol = undefined
    minus = undefined
    including = undefined
    findUnitClause = undefined

I think it's more a question of personal preference than right or wrong.

~20 years ago: Vim

Seven years ago: Haskell

A year and a half ago: Reflex FRP with GHCJS

These three events dwarf everything else in my experience.

Newer operations approaches may have helped make the state of affairs tractable, but it does not at all argue for that microservice architecture. There was literally no value gained from running a dozen web servers instead of two. And that being the case, the straightforward but "outdated" way of managing one or two servers manually would almost definitely be cheaper than learning and implementing the more modern approach.

I would like to propose a new variant on an old maxim: Premature microservice-izing is the root of all evil.

I've worked with an app that had been factored into half a dozen microservices. Each of these needed two EC2 instances for redundancy. They weren't using docker or any other container infrastructure and were treating EC2 instances as pets instead of cattle, which meant that a LOT of effort was spent maintaining the dozen or so instances. Each of these instances was running at < 1% load average! So in this case the microservice architecture was also costing a significant amount of money.

My takeaway: don't build an app from scratch using microservices, especially if all you're splitting apart is web handling which is almost never going to be where your application spends a significant amount of time. Instead, build apps in the straightforward monolithic way, and only split things out into microservices when there is a very clear reason that has been identified from performance monitoring or some other metric gathering.

Here's a talk the BuckleScript author recently gave on it.

https://www.youtube.com/watch?v=LC3KKHYbSQQ

This is a great way to build relationships. I have been a part a mentor for iMentor (https://imentor.org/) for the last four years. Their mentoring curriculum expects one email per week between mentor and mentee and every email starts with a "roses and thorns" exchange. They call it "highs and lows" but it's the same thing. I was surprised how significant this seemingly innocuous thing was to building a relationship with my mentee. I imagine it would also have a significant affect in a marriage or other long term partnership to help the people stay connected.

> Pulling off eye gouging and throat strikes are low probability and expose a fighter.

A throat strike is no lower probability or more exposing than pulling off a punch to the face. It's just a couple inches away...

I would say very often. For an example, let's look at the throat strike. Any time you could plausibly punch someone in the face, it could instead be a throat strike. It takes much less force to end a confrontation with a strike to the throat than it does to the face. This seriously changes the dynamics of the confrontation. This same reasoning also applies pretty well to eye gouges.

Now consider hits to the back of the head. If an MMA fighter exposes the back of his head to you, the quickest way to end it would be a palm strike to the base of the skull: lights out. But because that's illegal fighters will be a lot more likely to go for something like a rear naked choke, taking the fight to the ground and artificially inflating the value of grappling.

And that's just three of the many illegal moves.

> The present ascendency of Muay Thai and BJJ (Brazilian school of ji-jitsu) is a direct product of this sorting of martial arts effectiveness against competing disciplines. Karate and Kung-Fu's substantial drop are also related, as they are essentially unused in modern MMA.

It's important to keep in mind that many of the most effective self defense techniques are illegal in organized fighting competitions. These include eye gouging, throat strikes, biting, joint breaks, stomps, kidney shots, downward elbows, etc. IMO this seriously limits the ability of these competitions to predict how various styles will fare in real life or death self defense situations.

Why does any programming language have infix operators? Because they make some things easier to read. Fixity and precedence are not accidental complexity. They are the essential complexity of having infix operators. In order to evaluate "3 * 4 ^ 3 ^ 2 / 4 / 2 + 5 * 8" you must define the fixity and precedence of the operators involved. You don't usually have to think about defining these things in most mainstream languages because the language defines the fixity and precedence of those operators for you to give the behavior you expect. You still have to learn it though. Do you know how Python evaluates the above expression? (Change the carets to double stars...HN didn't render double star properly.) In my first programming class long before Haskell was created, the textbook had a C operator precedence chart. The concept is not new to Haskell. Haskell has just given you control over something that has been there the whole time.

Haskell lets you make your own infix operators so that you can get the same benefits in other domains than the ones that the language designers decided to provide for you. Therefore it follows that Haskell also needs to allow you to specify the fixity and precedence so that your operators will fit together in the way that is appropriate for your domain.

> Let me explain it a bit further: to read someone's code, first I have to see what symbols they have defined and what fixity they have ascribed to each of those. Now I have to keep all that additional unnecessary cognitive load in my brain to just be able to get a hang of their code with their fixity rules associated with their symbols.

The same is true of C, Java, Python, etc. The only difference is that those languages have a closed set of operators while Haskell's is open. There is a small amount of cognitive overhead, but I think you're greatly exaggerating it. In six and a half years of professional Haskell development I can count on one hand the number of times this has been an issue. And it can be trivially resolved by adding parentheses or by decomposing the expression into separate expressions.

> How about Haskell's notion of fixity of the symbols/operators/names?

Every language has implicit fixity and precedence for infix operators. What's different about Haskell is that you can actually define infix operators yourself. And if you're going to define your own you need to be able to also define the precedence of your operators. Fixity has always been there. You just didn't realize it.

> No examples, no evidence

I described a very specific example of something Haskell can do that JS cannot in this reddit thread:

https://www.reddit.com/r/haskell/comments/4ujg5i/what_are_yo...

It is almost impossible for the Haskell metadata widget I described to have bugs. But I've seen production bugs in the corresponding JS code twice in the last few months. You simply cannot get the kind of correctness guarantees in JS that you have in Haskell.

Groundhog (http://hackage.haskell.org/package/groundhog) is a nice "ORM" for Haskell. If you need something more flexible you can drop down and write raw SQL with postgresql-simple (http://hackage.haskell.org/package/postgresql-simple). There's also a corresponding mysql-simple package.

There are several HTTP clients:

http-streams (http://hackage.haskell.org/package/http-streams)

http-conduit (http://hackage.haskell.org/package/http-conduit)

wreq (http://hackage.haskell.org/package/wreq)

You're already doing the most important thing, which is working on learning Haskell on your own time. But I think there are some things you can do to significantly increase your rate of learning. Far and away the most important idea here is to interact with other Haskell developers so you can learn from them. You're right that doing this at a job would be the best, but there are other things you can do.

1. IRC. Join the #haskell channel on Freenode. Lurk for awhile and follow some of the conversations. Try to participate in discussions when topics come up that interest you. Don't be afraid to ask what might seem to be stupid questions. In my experience the people in #haskell are massively patient and willing to help anyone who is genuinely trying to learn.

2. Local meetups. Check meetup.com to see if there is a Haskell meetup in a city near you. I had trouble finding a local meetup when I was first learning Haskell, but there are a lot more of them now. Don't just go to listen to the talks. Talk to people, make friends. See if there's any way you can collaborate with some of the people there.

3. Larger non-local Haskell events. Find larger weekend gatherings of Haskell developers and go to them. Here are a few upcoming events that I know of off the top of my head:

Hac Boston - http://www.meetup.com/Boston-Haskell/events/231606922/

Budapest Hackathon - https://wiki.haskell.org/Budapest_Hackathon_2016

Compose Melbourne - http://www.composeconference.org/2016-melbourne/unconference...

MuniHac - http://munihac.de/

Hac Phi - https://wiki.haskell.org/Hac_%CF%86 (2016 is coming but hasn't been announced yet)

The first event like this that I went to was Hac Phi a few years back. Going there majorly upped my game because I got to be around brilliant people, pair program with some of them, and ultimately ended up starting the Snap Web Framework with someone I met there. You might not have a local meetup that you can go to, but you can definitely travel to go to one of these bigger weekend events. I lived a few hours away from Hac Phi, but I know a number of people who travel further to come. If you're really interested in improving your Haskell, it is well worth the time and money. I cannot emphasize this enough.

4. Start contributing to an open source Haskell project. Find a project that interests you and dive in. Don't ask permission, just decide that you're going to learn enough to contribute to this thing no matter what. Join their project-specific IRC channel if they have one and ask questions. Find out how you can contribute. Submit pull requests. This is by far the best way to get feedback on the code that you're writing. I have actually seen multiple people (including some who didn't strike me as unusually talented at first) start Haskell and work their way up to a full-time Haskell job this way. It takes time and dedication, but it works.

5. Try to get a non-haskell job at a place where lots of Haskell people are known to work. Standard Chartered uses is Haskell but is big enough to have non-Haskell jobs that you might be able to fit. S&P Capital IQ doesn't use Haskell but has a significant number of Haskell people who are coding in Scala.

The concerns you're talking about here were primarily deficiencies in tooling, not an inherent problem with the PVP. Many of those deficiencies have been fixed (for example, --allow-newer) or there is work in progress that will fix them (cabal new-build, cabal.project files, etc).

The whole PVP debate really boils down to one simple question. Do you believe that a properly functioning dependency solver is important for the community? If you answer yes, then I think it's pretty straightforward to get from there to the conclusion that version bounds are necessary. And by the contrapositive, if you are arguing against upper bounds, then you are actually arguing against the usefulness of a solver. If you answer no, then we should debate the merits of having a solver.

Check out CapitalOne. They have a nice credit card that pays 1.5% cash back with no foreign transaction fees. I describe in another comment how I use their 360 Checking and Savings. The debit card from the 360 checking account has been a fantastic no-fee way to get cash when I'm traveling.

Full disclosure, I do not own stock in CaptialOne or are affiliated with them in any way. I am just really happy with their banking services.

I used to use GnuCash to track everything, all credit card purchases, mortgage principle and interest...literally everything about my finances. But now I have reduced my footprint to the point where I spend substantially less than I make, so tracking everything like I used to do seems pointless. Using something like mint.com can be a way to get something almost as good as GnuCash with much less effort. But I never felt comfortable giving them all my online banking passwords, so I stayed away from that.

As far as spending goes, I buy just about everything with my Citi Double Cash credit card which pays 2% cash back on all purchases. I have an automatic transfer that pays the balance in full every month, so I never have to worry about late fees or interest payments. Any other bills, deposits, etc that can't be put on the card are set up as automatic deposits/withdrawals, so managing everything takes essentially zero effort. Almost all of this stuff happens via my CapitalOne 360 (formerly ING Direct) high interest savings account. They give me instant transfers between that and my 360 checking account as well as have a feature where overdraft on the checking account gets handled with no fees from the savings account. This means that I am able to keep the vast majority of my cash on hand in a savings account, so I maximize the returns of that money too.

Since my spending habits are now naturally restrained and I'm not concerned about tracking where my money goes what I do now is my own simplified take on a cash flow report. Every month I record in a spreadsheet the balances of all my cash accounts (two checking and one savings account). I also record the sum total of any deposits I make to investment accounts. I don't record the actual value of the investment account because then there would be lots of fluctuation due to the market. All this takes me like 5-10 minutes every month. From these four numbers I can derive a very accurate picture of exactly how much money I am saving every month, and when I subtract this from my actual after-tax paycheck amounts, I know exactly how much I'm spending.

The information I get from this report tells me the only number that really matters for early retirement: your savings rate, as a percentage of your take-home pay. From this you can get a really good idea of how long it will be before you can retire (https://networthify.com/calculator/earlyretirement).

CrossFit. It is the most time efficient all-around fitness program I have run across. And they're the ONLY methodology I've seen that has an actual measurable definition of the fitness they seek.

I've been writing Haskell professionally full-time since 2010. Before I started pursuing Haskell I looked into Scala, but it seems to be trying to embrace too many paradigms, which has resulted in a gigantic unwieldy language. In the 6 years that I've been using it professionally the Haskell ecosystem has matured tremendously. Obviously the third party library support can't be as good as popular languages like Ruby, Python, etc simply because of manpower, but I find that these days there is an open source package for just about everything I need. Furthermore, due to Haskell's purity and strong type system it is MUCH more likely that these libraries will work. It is also usually quite easy to make improvements when needed.

This. So much this.

There are at least two reasons scope is important. First, the larger a name's scope, the more likely it is that short names will end up conflicting with other names at some point. Of course conversely, the smaller the scope is, the less likely it will conflict with something and the shorter you can make the name. And second, if the definition of something is a long ways away, then it becomes harder to find it to figure out the context. But in the example above, `u` has very small scope and its definition `users.map` is right there and makes it very easy to see what u stands for.

It's also important to realize that long names have a cost. Above the obvious small cost of typing time, it is also harder to disambiguate them visually.