Comments URL: https://news.ycombinator.com/item?id=15698833

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=15399103

Points: 4

# Comments: 0

Maybe just a matter of perception but it looks verbose to me.

Comments URL: https://news.ycombinator.com/item?id=15256454

Points: 3

# Comments: 0

I took that to mean that the frameworks are doing the optimization. But the article doesn't give examples of the frameworks. The only examples of code transforming optimizations are Uglify and Babel. So I thought maybe these were the things the author has in mind and not actual frameworks. I was genuinely confused and prefaced with the aside about pedantry because questioning these kinds of semantics can come across as pedantic.

The second half of my comment stands regardless.

Not to be pedantic, but are UglifyJS and Babel "frameworks"? Not a Ember user, so maybe Ember has some sort of built-in source code transformer and that's what the author is referring to?

I think the basic idea that JavaScript developers, especially those working in a browser environment, will increasingly write source code that compiles to JavaScript "bytecode" is not a recent idea. A much more nuanced reflection on that idea can be found here: http://composition.al/blog/2017/07/30/what-do-people-mean-wh....

With all the hand-wringing about "JavaScript fatigue", it's a little bit sad that prominent JavaScript developers use titles like "Compilers are the New Frameworks". The tone of this title is the tone of a bell ringing for the next round of JavaScript fad musical chairs.

Comments URL: https://news.ycombinator.com/item?id=15200612

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=15107120

Points: 3

# Comments: 1

> So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?

I'm not frustrated with responses to criticisms I've made. In fact, I haven't made any criticisms (except of course, the ones in the last comment :P). So I don't have any experience of anyone not making room for me. But I have observed some smart people with well-articulated suggestions get shut down. It's not that their suggestions weren't accepted but it was the way that their ideas were received. I haven't actually seen someone who isn't Evan C. contribute something significant that isn't "doing X like Evan would do it." In the entire world of this language, there seems to be 1 architect and a community of implementers. Now, there's nothing wrong with being an implementer. I am an implementer. But it seems easy to see that cultures are healthier when there are a diversity of ideas.

I think that your characterization of the Elm community as a "group of likeminded individuals celebrat(ing) their common point of interest" is actually close to what I'm talking about. It's great when a programming language community is passionate about the language. If people enjoy using that language, it's certainly a good sign. But I wouldn't trust the judgment of a group of people who can't critique what they love and are unwelcoming to those who do.

The counterpoint here is Dan Abramov and the Redux community. Dan is continually pushing people to understand why they are using Redux and not to see it as a solution for everything. That kind of transparency, and the continual acknowledgement by Redux maintainers that there is more than one good way to do something, is the kind of intellectual honesty that I'm using as a standard in my assessment of Elm.

> How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is?

I couldn't say and it wouldn't change my opinion of Elm.

In the blog post you linked to ([2]), you say:

>Ah, the dreaded switch statement. For some reason, this is one of the most disliked aspects of typical Redux code, and I have yet to figure out why.

The Redux docs take the position that switch statements are an implementation detail. The documentation author(s) provide an alternative approach, the action type to handler map, in the Reducing Boilerplate section. I think Redux advocates get a little bit impatient with the criticisms of Redux that amount to "I don't like switch statements". I share that point of view. Switch statements are an implementation detail and aren't worth arguing about when the Redux architecture does not depend on them. When I came up with redeuceur, I wanted to isolate independent operations. For me, breaking a larger function into smaller functions means less cognitive overhead. I would have used the createReducer idea from the docs but I needed support for arbitrary computed conditions rather than a simple action type map. So, it's not about getting rid of switch statements but more about making it easier for my average mind to keep track of things.

All of that being said, are you sure you're not being disingenuous when you say "I have yet to figure out why?" The strength of the animus against switch statements in Redux reducers might be a product of received wisdom or unreasonable bias. But the additional cognitive overhead of things like `break` vs. cascading `case`'s, and `default` is a reasonable basis for preferring `if` statements or something more declarative. As near as I can tell, the original Redux examples used switch statements because they were aesthetically pleasing to the author. There's nothing wrong with this. But it shouldn't be a surprise that people prefer a construct with less complex behavior, even if the complexity of a switch statement is manageable to someone with solid JavaScript experience.

Comments URL: https://news.ycombinator.com/item?id=14696714

Points: 4

# Comments: 3