Live data from Hacker News

How I became a better programmer (2017)

jlongster.com

131–140 of 150 posts

Re: How I became a better programmer (2017)

#131

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…

I personally loathe JSX, not because of JavaScript, but because it's a wholly unnecessary different syntax for JavaScript that just forces me to deal with SGML/XML problems in a new and more painful way, because it has crept into the application logic as well.

Re: How I became a better programmer (2017)

#132
post #83

Earlier 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…

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

#133
post #51

Earlier 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."

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)

#134
post #3

The 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'…

> If you learn to program in one language, it's easy to learn another.

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)

#135
post #28

Earlier 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.

Be fair to the original comment, which referenced people saying something about learning a language, and it making learning any others easy, not about learning many languages, and it making learning any others easier.

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.

That sounds great but in real life, when your boss wants his crud app fixed yesterday and the previous dev left no documentation for random code, you have to do what you have to do.

Re: How I became a better programmer (2017)

#137

Earlier 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.

It's orders of magnitude harder to get users to download a program than it is to just give them a link and have everything right there, no?

Re: How I became a better programmer (2017)

#138

Earlier 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,…

My first language was Pascal. I'd like to think I learned good habits up front. But I'll fully admit, when I first started writing PHP, I definitely treated it as a "script". My code barely used functions at first. It was a big top-down autoexec.bat style recipe. It took quite awhile for me to come around to treating PHP like a real programming language. I think a lot of it came from the fact that I'd edit, and refresh the browser page. Whereas with Turbo Pascal, I'd save my work, and compile. Once I did come around to writing more application-style with PHP, I was more interested in other things (Java and Ruby at the time)

Re: How I became a better programmer (2017)

#140

Earlier 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…

Your 2nd paragraph says what I meant to say, but much more sussinctly. Thank you.
Post reply on HN