Earlier quoted context omitted.
> I did not like the whole Redux experience Out of curiosity, anything specific that concerned you? If you haven't looked at Redux lately, a lot of stuff has changed. We have a new official Redux Toolkit package [0] that is now our recommended approach for writing Redux logic, our new React-Redux hooks API [1] is easier to work with than the classic `connect` API, and we have an updated list of recommended patterns i…
For me it's simply the bulkiness of it: - Babel transpilation aspect (time it takes to build, difficulties associated with ad-hoc debugging in production) - Bundling/packaging aspect (same reasons as above; time it takes to build, debugging difficulties). - Huge number of unnecessary dependencies which adds risks/vulnerabilities to projects. You could argue that it's not React's fault, that it's more about the toolin…
How I became a better programmer (2017)
131–140 of 150 posts
Re: How I became a better programmer (2017)
#132Earlier quoted context omitted.
I initially followed the same path... then I just ditched completely PHP and its ecosystem and then never felt the need to write my own ORM/Router/libs again.
Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience. As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and…
C imposes similarly rigorous proving grounds for developers, but without pushing new developers into bad habits that would come back to bite them later. If you want people to start with more requirements for hard thinking about how to not build a deathtrap, choose C instead.
As for the benefits of rendering server-side, they are legion, and most important among them is the fact that pushing everything to the client-side part of the system means not really knowing what your code will do in the wild, imposing whole new classes of frustration on users, and piles of other horrors. Yes, we could benefit from falling back on far more default-server-side technologies and using JavaScript only where it's needed, I think, for the sake of the users first and foremost.
JavaScript is great for some things. It's terrible for others, and all too often trying to use JavaScript for everything means coupling the wrong tools for many jobs together with the wrong place to run code, too. Even when I enjoy JavaScript work, the simple act of checking online documentation for the JavaScript tools I'm using ruins the whole experience for me as I realize how we're punishing our users when we don't think about how we're using JavaScript from a user's perspective.
Re: How I became a better programmer (2017)
#133Earlier quoted context omitted.
> anyone writing a UI in 2020 to have a damn good reason to not use react and redux. Avoiding JavaScript is all the reason anyone needs. UI =\= website
The most charitable interpretation of their point is any UI where you were going to use Javascript heavily anyways which is what Redux+Redux competes with. To take your point to absurdity, you could also just say "nope, write a native client instead."
Re: How I became a better programmer (2017)
#134The points on the fluff in particular resonate with me because idespite being a fairly good software engineer, I would say it was only recently I truly started seeing past the fluff. However, typing this out, I realise I would have said the same thing 10 years ago, and 5 years ago, and I probably will again another 5 years from now. I think the truth is that we're always missing the forest for all the trees -- only a…
> then languages Perhaps a slight digression, but: I think there are very few people who can really say they can 'see through' the difference between languages. C++, Erlang, Prolog, and Haskell, are very different languages, all the way from the shallow matter of syntax, through the type system, and even down to the fundamental model of computation. When I hear someone say If you learn to program in one language, it'…
That's often the case: many people who think that don't really use the strengths of the languages they use.
On the other hand, I've written a basic lambda calculus parser for fun and gone on to write (non-distributable, if I care about people) software using it, also for fun; I've written idiomatic, well-formed code in BASIC, C, Perl, Ruby, Scheme, Standard ML, and a wide range of other things; and I've basically added features by removing code. At some point, even if you know what you're doing, there comes a point where, kinda-sorta, it becomes easy to learn others.
It just takes a lot more than learning only one language to get to that point. Whether the person who first coined that comment about learning languages meant it as a simplification of a wise concept or was a blubdev who never really figured out the significant differences between programming languages is a question I'd like to see answered definitively, based on knowledge of the individual rather than guesses.
Re: How I became a better programmer (2017)
#135Earlier quoted context omitted.
Sure, but it will still be a while before you aren't just writing Python in Rust.
However the more languages you know and the more they're spread across different paradigms the shallower the learning curve will be for any language one wants to pick up.
Re: How I became a better programmer (2017)
#136"The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done." I couldn't disagree more, the grown up programmers use a strategic approach, not a tactical one. As Jonh Ousterhout put it in his book A Philosophy of Software Design "The first step towards becoming a good software designer is to realize that working code isn't enough."
100% agree. The "hacks" and "get stuff done" approach gains quick and short benefit, which probably fits a freelancer/contractor role. Maintainable and testable code should be implied. It's not about how fast you get to code to production, it's about how fast code/product can be adapted to new or unexpected requirements.
Re: How I became a better programmer (2017)
#137Earlier quoted context omitted.
The most charitable interpretation of their point is any UI where you were going to use Javascript heavily anyways which is what Redux+Redux competes with. To take your point to absurdity, you could also just say "nope, write a native client instead."
What is absurd about native programs? I think trying to turn a web browser into an OS is absurd.
Re: How I became a better programmer (2017)
#138Earlier quoted context omitted.
Haha me too. I think PHP was a great rite-of-passage as a developer back then: inconsistent standard API, all the session and cookie access built in, with all the security gotchyas, evolution from major versions 4 to 5, obsession with Frameworks, growth and development of ZF and Symfony etc. Great experience. As I left the ecosystem, I realised I approached writing code in a very defensive, overly structured way and…
Regarding PHP, if you want it as a rite of passage it should come after writing software in better languages with better tools. PHP-first means bad-habits-first. C imposes similarly rigorous proving grounds for developers, but without pushing new developers into bad habits that would come back to bite them later. If you want people to start with more requirements for hard thinking about how to not build a deathtrap,…
Re: How I became a better programmer (2017)
#139Also teaching something is a good way to learn more and more about an specific subject
Re: How I became a better programmer (2017)
#140Earlier quoted context omitted.
I'm one of those people, but there's more nuance than that to it. I've learned about 20 different languages to some degree, from Python to brainfuck to Elixir currently. When I learn a new language, I go to the source material, so for elixir I used the tutorials at the elixir home page and their API documentation. I read the tutorials, writing each line of code into my editor, running each, modifying it to see how it…
I'm with you on this - I don't know so many languages but have studied a wide range, and am fluent in several programming and human languages. What I've found that is that once you learn more than one language with different paradigms , it becomes easier to learn another one with a similar or another different paradigm. As you pointed out, there are only so many ways a language can be designed/structured, and becomin…