41–50 of 788 posts
My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definite…
You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with.
You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style.
All of that is friction introduced because you haven't learned to live with the default style.
Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time.
By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
> ORMs are the devil in all languages and all implementations. Just write the damn SQL This week wrote an article on this, since I found there's a lot to explain wrt this topic: https://dev.to/cies/the-case-against-orms-5bh4 On HN: https://news.ycombinator.com/item?id=42922014
I actually disagree with about half of this. > Typed languages are essential on teams with mixed experience levels Essential, meaning 'cannot exist without', it's not. I've seen this work a number of places. > Blind devotion to functional is dumb. Managing/limiting state is always a worthwhile pursuit. I'd think he would agree since he seems to value simplicity > People who stress over code style, linting rules, or o…
I don't think you're grasping the nuance he's putting out there. Instead you're choosing to be overly pedantic over the word essential.
Earlier quoted context omitted.
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definite…
Edit: This comment was based on misreading the parent comment. I've left it up, but I should have been more careful. You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with. You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more li…
> REPLs are not useful design tools (though, they are useful exploratory tools) I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop. I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. Thi…
If you want to argue the point with non lisp people, I'd go to javascript or SQL as great examples where you really use repl's quite a bit.
It felt good to read someone who thinks like me, honestly. Also the observation of "The trouble with functional programming is functional programmers" is absolutely correct . This needs to be said more. Way more. P.S.: You can ask why, and I can answer honestly, without hostility.
Maybe say it less but it explain it more. I don't get it at all.
From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others.
Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet the rest at where they are". This is very true. The problem is, the people in the first camp can't cater to either group. First group has strong opinions and want a solid (not hostile, solid) discussion about how they can improve and how that tool works, and the second group doesn't care.
Also, every programmer has an understanding of the machine, and they program on top of that abstraction. For me, "C virtual machine", or the modern hardware is very easy to grasp. For every line of code, I can have an educated guess about how my code will run (e.g. how will the branch predictor will behave or got inadvertently poisoned), hence imperative languages and the primitive memory management is easy for me. For others who think more meta, functional paradigm is a natural think to construct in their brains. Not meeting them at where they are is again off-putting.
All in all, nobody wants to be constantly nagged to feel "stupid" about not understanding functional programming or how unelegant imperative is, and most of the functional programmers are doing this, even without knowing it.
Some of my friends who do functional programming are more reasonable people. Who sit down and look at some code or problem say "oh, this looks an interesting problem and interesting solution, can I show you how it's done in functional way", and we can go from there, and go a very long way from there.
I have never picked up Common LISP because of an academic who praised functional programming like it's the second coming of Christ. I still have the first chapter of the LISP book printed on my desk. I'll start it after 15 years, but now I don't have the time I want to spend on it.
Lastly, from an architecture/elegance perspective, I believe a good imperative program in C/C++/Go is somewhere between Bauhaus and Brutalist architecture depending on what domain you're targeting (lower the level, more Brutalism), and I find that naked nature of imperative code directly tapping into the hardware or the kernel efficiently very elegant and well-designed. For the same majority of functional programmers this is ugly and shall be got ridden with a flamethrower. Also, an imperative programming language is no lighter on PLT and mathematics which the same majority finds mouth wateringly elegant.
TL;DR: If the majority of functional programmers can be a bit less arrogant, meet in the middle and learn why we love what we love, we can build better languages, ecosystems, and a better world to live in, but no, functional elegant, imperative bad.
Robert Martin's Talk: "What Killed Smalltalk can Kill Ruby, Too": https://youtu.be/YX3iRjKj7C0 which notes a similar mechanic about Smalltalk.
Earlier quoted context omitted.
remind me why they don’t work? because “throws Exception” propagates virally to every method in the codebase?
Well, if you don’t handle them then… yes? What else can be done?
Earlier quoted context omitted.
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definite…
Edit: This comment was based on misreading the parent comment. I've left it up, but I should have been more careful. You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with. You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more li…
HN discussions on that post: https://news.ycombinator.com/item?id=25887373 (4 years ago|686 comments), https://news.ycombinator.com/item?id=32162716 (3 years ago|58 comments), and https://news.ycombinator.com/item?id=41633156 (4 months ago|56 comments).