Seeing redux dev tool replaying state changes with a connected router. This is what completely sold me on react/redux.
Ask HN: What made you change your mind about a programming language/paradigm?
151–160 of 401 posts
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#152Python. Having picked it up and dropped it like fire during the 2.7 era, I never looked back. For a long time, my main all-purpose scripting language was Ruby.
Then I had to write Python3 for my current project and wow. Type annotations, async, mypy, context managers, actually supporting unicode, the language improved over the last decade.
Not to say list comprehensions are any good beyond the most mundane tasks, but you can write a decent library that has the equivalent of ruby enum and array methods to bypass that limitation now.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#153Immutability. I didn't really understand the benefits of having immutable data structures until I tried building a service with no mutations whatsoever... and noticed I didn't get any weird, head-scratching bugs that took hours to reproduce and debug. That led me to go down the Functional Programming rabbit hole - thus changing my entire view on what code is/could be. [edit: spelling]
To add to this: functional programming. Getting rid of state in objects was a DREAM for me.
I used to think: come on you better than though hipsters... this shit looks ridiculous, and it isn't intuitive... There's no way it's worth it to learn. It's just the new fad.
Oh, how I was so so wrong.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#154The Smalltalk feedback/living-in-the-debugger coding style. I was happily coding in Python, C#, Java etc when I ran into Squeak, and then Pharo and Dolphin Smalltalks. This style presents the smallest barrier between idea and working code for me.
Smalltalk is great. I haven’t used it in years, but I miss the feeling that everything is part of one big Smalltalk environment.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#155Earlier quoted context omitted.
One downside to static typing is the overhead required when writing/running programs. For example, let's say you have a class `Dog` that you want to rename to be more generic so you now call it `Animal`. In Python you can test out snippets of code with `Animal` without necessarily having to worry about other pieces of code still referring to `Dog`. You would just need to make sure that the code you want to run happen…
In C# with Visual Studio and Resharper: * Have cursor on 'Dog' * Ctrl-R-R * Type 'Animal' * Press Enter Done. And your code won't be littered with 'old' types and other garbage.
Very similar with C++ and Visual Assist, the shortcut is Shift-Alt-R.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#156The more code I write in dynamically typed languages, the more I believe that static typing is a must. Generally speaking, I noticed that I'm shifting more and more away from "stop annoying me and let me do what I want, I know better!" part of the PL/API design spectrum, and towards "better safe than sorry". Static typing, runtime checks, data schemas, design by contract, fail fast etc. Yes, it's overhead, but it's p…
One downside to static typing is the overhead required when writing/running programs. For example, let's say you have a class `Dog` that you want to rename to be more generic so you now call it `Animal`. In Python you can test out snippets of code with `Animal` without necessarily having to worry about other pieces of code still referring to `Dog`. You would just need to make sure that the code you want to run happen…
typedef Animal Dog; // until refactoring is complete
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#157Testing. Unit testing to me seemed akin to drinking 8 glasses of water every day. A lot of people talk about how important it is for your health, but it really tends to get in the way, and it doesn't seem to really be necessary. Too frequently, code would change and mocks would need to change with it, removing a good chunk of the benefit of having the code under test. Then I started writing integration testing while…
I would disagree. Unit tests make sure your code is clean and composable. It's hard to write unit tests if you have hundred line methods etc. It usually forces you to write smaller chunks of code. Integration tests make sure it works in test/prod. You can have a complete spaghetti mess and still pass your integration tests. You can also have good unit test coverage but break prod.
They serve two different purposes.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#158Microservices. They seemed really cool until I worked on a few large projects using them. Disaster so epic I watched most of engineering Management walk the plank. TLDR: The tooling available is not good enough. The biggest cause lies in inter-service communication. You push transaction boundaries outside the database between services. At the same time, you lose whatever promise your language offers that compilation…
> Keeping 30 backend applications up to date and playing nice with each other is a full time job. CI pipelines for all of them, failover, backups. This isn't normal. You should just have a single CI pipeline, failover and backup approach that is parameterised for each microservice.
It's not that easy in my experience. They use different databases. Different versions of frameworks. Some written in different languages. We tried to have a "one size fits all" CI pipeline but that fragmented over time.
The overhead was huge compared to "traditional" apps. Just updating a docker base image was a weeks long process.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#159Microservices. They seemed really cool until I worked on a few large projects using them. Disaster so epic I watched most of engineering Management walk the plank. TLDR: The tooling available is not good enough. The biggest cause lies in inter-service communication. You push transaction boundaries outside the database between services. At the same time, you lose whatever promise your language offers that compilation…
> Keeping 30 backend applications up to date and playing nice with each other is a full time job. CI pipelines for all of them, failover, backups. This isn't normal. You should just have a single CI pipeline, failover and backup approach that is parameterised for each microservice.
Doesn’t that mean you have to use the same language, libraries, and DB for every service?
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#160Microservices. They seemed really cool until I worked on a few large projects using them. Disaster so epic I watched most of engineering Management walk the plank. TLDR: The tooling available is not good enough. The biggest cause lies in inter-service communication. You push transaction boundaries outside the database between services. At the same time, you lose whatever promise your language offers that compilation…
> "all the services needed to talk to each other" I'm not an expert by any means, but I'm pretty sure that statement indicates a problem.
I don't think so. This kind of thing comes up constantly in RDBMS. New requirement means we need to join thneeds and widgets data together. In a regular database, even NoSql, this isn't a hard problem.
When the services have their own datastores, well now they need to talk to eachother