danielmason

(I'm not sure if you mean "design patterns" in the general naming of abstractions sense, or if you mean Gang of Four specifically. If the latter, I'll point out that many of the GoF patterns really aren't relevant to Javascript unless you're writing it in a very OO style)

The only thing I'd differ on is the semantic HTML advice. What you're saying is true modulo accessibility, but accessibility is (well, should be) table stakes for professional work. And while the community has come up with some really nice individual abstractions around tricky a11y concerns, I haven't seen a way to get good results without at least some knowledge of HTML semantics. I'm not implying you don't care about a11y -- it's totally possible I've missed some better ways of doing things.

To tie this back to Bucklescript, does this loosely describe the process of using Reason syntax to author Javascript? Reason file -> (Reason) -> OCaml executable code -> (Bucklescript) -> Javascript

As someone who's evaluating Typescript and Flow for a team of JS devs, my intuition is that having some typed code would give you beachheads of type safety, which seems like a reasonable win and an incremental path to improvement. I'm curious if this intuition is incorrect from the perspective of those who have used gradual typing in the real world.

This is also modeled after an architecture in a statically typed language that expresses possible actions as a single union type, in which every possible type must be handled. There's no similar compile-time guarantee in JS, but a switch statements with constants is a reasonable approximation of the idea.

There are two problems with your suggested approach -- specificity and coupling. The rules of CSS are such that .collection > li is a more specific selector than .collection-item. So if you want a particular item in the list to be red, you can't just give it a class name .warning-item and style against that -- you have to match or exceed the existing specificity. In the simple case, this isn't too bad, but it's surprisingly easy to end up representing deeply nested structures in your CSS which are very difficult to override.

The coupling problem is really just a way of saying that it might not be a good idea to describe the specifics of your HTML implementation in CSS. Class names are like an interface. One refactoring I've actually done a lot is switching out lists like the above for a combination of nav and anchor elements. It's great to be able to do that without needing to rewrite all the corresponding CSS, too.

These are tools designed to help you manage complexity and increase flexibility, not dogma. If you don't find your HTML needing to change much, or you don't need to make styles overrideable, then YAGNI. Hopefully it makes sense why framework authors, whose work is explicitly designed to be overridden, would choose this approach.

Anyway, I'm pretty sure that's a quibble on my part because your post still gave me an adrenaline shot of motivation to GET OUT THERE and MAKE PEOPLE LOVE ME!

I'm looking for jobs right now, and it's been an exercise in frustration. The coding jobs require CS degrees, 5 years of experience, tech interviews with big-O notation and data structures (trying to teach myself basic CS theory, but need a job now). The UI and design jobs require a smidge of front-end knowledge, but are mostly mocking and wireframing. I want to be able to employ all of my tools, but I feel like the hiring market makes me pick between being a front-end or a back-end guy, and I don't currently have enough specialization at either to get a reasonably good job.

How can I find companies that could use someone like me, when their job descriptions are specialized? Any thoughts or advice?

Your line of thinking seems to imply that every counterargument must be considered before drawing a conclusion. Since the possible counterargument space is basically infinite, we wouldn't be able to decide anything. That can't be right. You have to be able to identify patterns of reasoning that are common to a whole set of "thought processes working in any number of contexts," and recognize how certain patterns will invalidate any argument that relies on them. Which is exactly what he's doing. And why he can feel confident in calling certain beliefs irrational without having heard every possible argument in their favor.

Redgate's message is candid and addresses me like a grown-up. I think that's much better.

It turns out my aside does address this. If a theity is said to "care about the welfare of individual humans", the caring must actually be something that humans would actually recognize as caring. Otherwise, you're using the word to connote something that it doesn't, in order to piggyback on the emotional resonance of what it actually does.

Saying God may be caring but we don't know what that looks like is exactly equivalent to saying we don't know anything about God. The entire point of theism is to claim that you do know something about God.

The Problem of Evil, philosophically, has never been a refutation of the existence of God. It's a refutation of the existence of a particular kind of God.

As an aside, one of the most common answers to the Problem of Evil is that God's justice is beyond human comprehension. I think it's interesting that this dovetails the debate of philosophy into semantics. That is, if God is just, but not in a way recognizable to humans, is it even semantically meaningful to call Him just?

The reason I responded to your initial post is that it seemed to suggest you support Dawkins' ideas but not his methods. I was pointing out that his methods actually follow logically from his ideas. In your follow-up post, I realize that you weren't making an idea/method distinction -- you actually just disagree with him. So it turns out that this is really just a bog-standard debate about theism.

I was all fired up to post a response, but the more I thought about it, the more I realized that a refutation would really just resemble a series of excerpts from Dawkins' book. In other words, I think he's already addressed your position quite convincingly. If you read it and didn't feel the same, I'm unlikely to do better.

But one last point. You've misattributed the "boil down" of the book. Dawkins is doing something like this:

  1. Here's why it's illogical to be a fence-sitting agnostic
  2. Here's why it's illogical to posit God as an explanatory philosophy of the universe
  3. Here are some specific problems with common theist arguments
  4. Okay, now that we've got all that out of the way, here are some interesting theories on how things got to be the way they are

My personal context: I'm also an agnostic, but I am what Dawkins would describe as a Temporary Agnostic in Practice, whereas you seem to be what he would describe as a Permanent Agnostic in Principle. I disagree with Dawkins on many things, but I found his arguments against fence-sitting agnosticism to be persuasive.

The crux of Dawkin's position is that the question of the existence of God is entirely resolvable. So your statement above is actually a direct disagreement with his position, not a critique of his methods. Have you read The God Delusion?

I think Mint is a good example of design driving success. Mint is largely built on the Yodlee platform, but they made the interface their primary focus. I don't get any information from Mint that I can't get on my bank's website. But since signing up for Mint, I check my accounts twice as frequently, classify all of my purchases, track my financial history, and set budgets. I didn't have to wrestle myself into these habits, either -- they came naturally because Mint made them easy and available. And honestly, I would never have trusted my bank account information to a site that looked like early-days eBay.

1. Value -- a good designer will take the time to understand the the target audiences. Many target audiences aren't looking for value, they're looking for status or something just as intangible. Implementing a visual design which communicates something the target audience isn't searching for is closely akin to pricing your product incorrectly. In fact, design approach is almost completely analogous to retail product price stratification.

2. Trust -- this again depends on audience. Sometimes "labor of love" is the most relevant trust mark, but in other cases it's "well-established" or "industry leader."

3. Accessibility -- this is kind of a 'duh' for any experienced web developer. Most design-oriented site you go to are built for modern browsers only, but that's because all their visitors are using Firefox. Any good web designer still knows how to fix an IE6 margin-doubling bug, for example.

4. Flexibility -- um, it really is possible to design sites with good UI and flexible content. Would anyone here make the argument that Craigslist would have failed with proper whitespacing, appropriate font selections, and logical visual hierarchies? Those can all be accomplished with a single stylesheet.

5. Function -- this really is the point of design. Most good designers would tell you that. Design without utility is bad art. I love user interface design because I can build things that look good and work well. The two go hand-in-hand.

I may be reading too much into the comment that "in general, aesthetics simply don't matter." If that's really true, do you have a good explanation for Apple's success? How about Nike?

Isn't this just an example of a bandwagon effect cognitive bias? How does the ubiquitous nature of bad copy make it any more effective? If anything, that's 180 degrees from true.

If every marketing statement could be taken at face value, this would work fine. Unfortunately, everyone has access to the same thesaurus I do. How am I distinguishable from my competitors if both our sites read like a checklist of abstractions?

Your point about the request processing number really drives this home. Whether someone prefers the word "powerful" as a stand-in for a demonstrative figure depends entirely on whether they're already inclined to believe whatever you say. If that is a good description of your average first-time visitor, then, um, I wouldn't waste much time on writing copy anyway. Just have a headline reading "This is exactly what you need." and a sign-up button.

We have had persistent bugs and inconsistencies. By itself, this wouldn't be a huge issue, but their level one support is untrained, powerless, and seemingly reluctant to help. In all my support calls to them, they have yet to put me on the phone with someone who understands my problem and has the power to fix it.