danielmason

8 yıl öncediscuss

This might be broadly true. But I think in the context of what tptatek is talking about -- that is, getting low-ceremony mileage out of React -- it's not. The reason is React's main abstractions of declarative components and one-way data flow are already well-suited to describe most of the UI problems you'll face.

(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)

danielmason

8 yıl öncediscuss

As someone who's pretty far down the rabbit hole on a bunch of these fronts, I think this is wonderful advice. Many of these are tools to solve very specific problems, and you should make sure you have those problems first.

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.

danielmason

10 yıl öncediscuss

Thanks, that's very helpful!

danielmason

10 yıl öncediscuss

Reason describes itself as "a meta language toolchain to build systems rapidly", which seems a little vague to me. Am I understanding correctly that Reason is both a (kind of) alternative compiler for OCaml's build toolchain, and a dialect of OCaml in its own right?

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

danielmason

10 yıl öncediscuss

I'm sympathetic to the worst-of-both-worlds problem, but can this actually be true? In the case of types, constraints actually are the benefit, right? Do you mean that if you don't have compile-time assurance for 100% of the code, the value of whatever % type coverage you have isn't very useful?

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.

danielmason

10 yıl öncediscuss

I'm not sure I understand what you mean by "the client loses most the advantages of your library being in TypeScript in the first place." Your library still exposes a more clearly-defined API by making types explicit. And saying that the downstream consumer doesn't get the benefit of compile-time type checking if they've chosen not to use type checking is...kind of a truism?

danielmason

11 yıl öncediscuss

Are you being serious? That's exactly what's being implied. Which part of tangentially involved in tech juxtaposed with unlike women with Math, CS, or EE degrees would lead you to read that differently?

danielmason

11 yıl öncediscuss

Doesn't the OO approach just move the work of the switch statement into the class declaration of the model? In practice, OO is about encapsulation, and FP is not. So it's probably not too surprising that the author chose not mix metaphors.

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.

danielmason

11 yıl öncediscuss

There's a reasoning behind this. You may not agree with it, but it's good to fully understand the problem it's trying to solve.

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.

danielmason

14 yıl öncediscuss

I'm sorry not to add value to the discussion, but I wanted to say the back-and-forth has been a very educational look at some of the practical trade-offs that framework designers have to make.

danielmason

15 yıl öncediscuss

That's sort of what I was trying to say, except maybe I have a more pessimistic estimation of how many organizations are open to being convinced. Of course you have to sell yourself, but it still matters who's able to buy. Startups may have the most flexibility in this regard.

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!

danielmason

15 yıl öncediscuss

Same, except I don't really enjoy writing documentation. :) I posted my full thoughts in a separate post, but I'm looking for a job, and every job description I read makes me feel like I'm at a crossroads where I have to pick something to give up and something to get better at.

danielmason

15 yıl öncediscuss

I might be considered a larval Designineer. I started off as a visual designer, then learned HTML and CSS, then Javascript, then out of necessity began maintaining an old ASP Classic codebase. As soon as I started to understand the code I was reading, things got easier. Then I built a small data-backed web app and I was totally hooked. In the last two years, I've learned to build nontrivial web apps from the ground up. SQL, MVC, Backbone, UI, design. I'm pretty proficient at each level of the stack, but only insofar as it's related to the web. Eg. I know C#, but I wouldn't have the first clue about how to write a native Windows application. So I end up feeling like my knowledge is the proverbial mile wide and inch deep.

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?

danielmason

15 yıl öncediscuss

I suspect the scarcity of your skillset is the main contributor to your relative scarcity of opportunities. At a previous company I helped found, we realized that we were trying to find people who were pretty good designers, front-end developers, and really good on the phone with clients for support stuff. We didn't have the margins to split these into different roles, and that was the insight that allowed me to realize that our revenue model was fundamentally broken. It's not that these people don't exist, it's that you can't design your business around reliably finding them. So maybe you're left with a handful of startups who are able to find a place for you because they recognize your value and adapt, not because they had planned on finding you in the first place.

danielmason

15 yıl öncediscuss

"What a human would write" isn't the purpose of the comparison. "This gets put in, this comes out" is. Did you not read the heading on the overview page? It doesn't even say "comparison" anywhere. The second paragraph talks at length about how CS compiles to readable Javascript. Then the examples show you that readable Javascript. You're missing the point.

danielmason

15 yıl öncediscuss

That seems like a pretty empty criticism when the article itself is basically a dust-cover synopsis of his book. He's illustrating particular points using representative commonly-held irrational beliefs, not laying out a point-by-point case against each.

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.

danielmason

15 yıl öncediscuss

It seems like most messages of this type try to pretend that it's not about money. The worst is when a company uses lines like "mutually beneficial" or "we're confident this will be better for our customers." When I read that, I'm not just getting unpleasant news -- I'm getting unpleasant news from someone who thinks I'm stupid.

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

danielmason

16 yıl öncediscuss

You do not and can not know how what I was calling a Theity cares. It is itself a very primitive idea that the caring must manifest as heavyweight, visibly-obvious intervention into everyday life.

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.

danielmason

16 yıl öncediscuss

I'm inferring a distinction that Kurzweil doesn't make explicit, but I'd guess he regards "theism" as a claim that the creator possesses specific (highly anthopomorphic) traits, eg. love, or personal interest in our lives. I doubt he would recognize much difference between the unknowable theity that you describe and his own "artilect." (quoted because I think it's a stupid word). For theists, the concept of God necessarily carries the baggage of what God is like.

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?

danielmason

16 yıl öncediscuss

Question for you -- is it a breach of etiquette to respond to something several days old? If so, I apologize, but I was away for a bit and I found your response interesting.

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

In other words, the part of his book that you single out is the part that he attaches heavy disclaimers to. The fact that you chose to focus on it suggests to me that your belief that "it's impossible to know for sure one way or the other," is even more of a gut-feeling assertion that you're accusing him of.

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.

comments