Live data from Hacker News

Ask HN: What made you change your mind about a programming language/paradigm?

news.ycombinator.com

261–270 of 401 posts

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#261
I have been using Python in anger for just about anything I could get away with since the year 2000. Shunning Java if I could help it, later the same with .NET etc. Feeling mighty snug with duck typing, using Python as sort of my Lisp substitute. (I managed to inflict Lisp on my colleagues once, but it was not a match made in heaven.)

So, recently I was tasked to fix a (pretty small) codebase in VB.net. It was not a pretty code, but not awful either. I went through it, cleaned up as I saw fit. (I had a lot of freedom to play around, since the code was basically in undead state. No one was going to come after me and say "why did you change so much" or anything like that.)

And I discovered some things. Visual Studio is magically good. (Take it for what it is, I am sure you have some fav IDE. As a Unix neckbeard, VS is unicorn magic.)

VB.net is nice. Auto variables, but still static typing. The full .NET toolset and datatypes, iterators etc. The fluffiness of the syntax doesn't matter when the IDE is closing your blocks for you etc.

Also VB.net is easy - it feels a bit like I imagine Python with types.

So, long story short - getting helped by the static types so many types, it felt downright awkward going back to Python for other projects. :-/

I am using MyPy now, which add some static typing as annotations, but I wonder if I'm just prolonging my stay in a local optimum. I should probably brake free from the stranglehold Python holds me in. But where do I go? I'm not a native Windows citizen.

IntelliJ looks great, but super complicated. Might try that and the Java world. Or Rust?

It's a big world and I'm not getting any younger.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#262

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

Yeah, if you are going for a microservices architecture, you need at least one person or dedicated team in an oversight / architecture role that keeps the design and growth in check. Primarily that means saying "no" when someone wants to create a new service or open up a new line of communication. It's an exercise in limiting dependencies.

And the easiest way to do that is to not build a microservices architecture; instead (and I hope I'm preaching to the choir here) build a monolith (or "a regular application") and only if you have good numbers and actual problems with scaling and the like do you start considering splitting off a section of your application. If you iterate on that long enough, MAYBE you'll end up with a microservices architecture.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#263
post #237

Testing. 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 had this experience as well, but then I began to realize that, as the codebase got bigger (let's say, for your metaphor, I was exercising more) that I really actually did want unit tests (that I needed more water). As the codebase gets larger and more complex (and interesting!), I want unit tests to fail because of small changes. That's actually useful feedback, whereas the simple, brutal failure of an integration…

This has been my experience too. On a project I'm working on now, I went majority integration tests. I have about 200 of them and they now take 2 minutes per run. VirtualBox and Jest doesn't help. To stay sane, I've had to run only relevant tests. They're great for a final sweep but they do slow down the feedback loop quite a lot.

For future tests and projects, unit tests do have a place and I'll make better use of them.

A good learning experience, none the less.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#264

Earlier quoted context omitted.

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

not necessarily if you design a decoupled event driven approach where every service can just subscribe to the data it needs.

"every service can just subscribe to the data it needs."

Doesn't that imply that each service then has to store any data it receives in these events - potentially leading to a lot of duplication and all of the problems that can come with that (e.g. data stores getting out of sync).

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#265

Earlier quoted context omitted.

Service Oriented Architecture is a much more fitting name. ;)

Microservices are just SOA done right; services should have a single responsibility, be replaceable, have a schematic etc.

Services having a single responsibility sounds like good advice, but how do you turn a number of services with a single responsibility into a working application? Any process that touches multiple systems will become a lot more complicated. Single-responsibility services is good advice but it's too easy for short-sighted developers to obsess over that - instead of the bigger picture. Yes it makes it easier to carve out your segment of an application, and yes that codebase will be easier to maintain, reason about, and maintain, but someone has to keep bigger picture in mind. That's often lacking.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#266
post #252

DDD - Domain driven design. My entire career pivoted the day I worked with a team that was building a large financial system (ie: multiple teams around the world, hugely complex set of business domains, zero margin for error). The entire approach to code, thinking, and organisation meant that a code base that could easily be a mess at 1/10th the scale, was maintainable and actually increased velocity of the teams ove…

What language/framework did your team use for that project?

It was C#, NServiceBus framework. Nowadays I'm doing similar work in Typescript. The approach is somewhat technology agnostic

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#267
1. Python. I was amazed at how awkward it was to scale a Python program and coming from C type strictness, how much time I would spend running a program again and again to get over silly typos and stuff. I absolutely refuse to use Python for anything beyond one page long program. It's still awesome for transforming data, but nothing beyond. It really felt to me like "the king is naked" because everyone around me was/is heavily using Python and I just couldn't stand it (and I've been using Python here and there for over 15 years now). I felt like I was doing something wrong - no, guys, you were doing something wrong. Not even talking about the pathetic performance and the abysmal concurrency; just the quality of tooling and static checks. (much of the critcism obviously applies to other dynamic, scripted languages like JS, but at least everyone admits JS is shit up front, not so with heavy Python users).

2. C# and its tooling. I consider it the apex language. If there's a useful feature or convention somewhere else, Microsoft will make sure it makes its way into the C# standard in the next version. Super elegant, readable, straightforward and powerful. Superb tooling all around, from the blink fast compilation to catching most issues with static analysis before you even get to build. Linq and fantastic abstractions. Now that .NET Core is open source, there's very little reason left not to use it as the go-to language for backend programming. It got me excited about programming again, because my ideas would translate nearly instantly into high quality, high performance code that I could almost always rely on to run right the first time.

3. The Linux kernel. I've been doing kernel development in many opportunities for the last two decades and it's always a great example of an elegant, no bullshit codebase. It's a window into the working of many great minds. Early on, it got me educated on proper error handling in low level code (goto stacks).

4. Actors for concurrency. I started using the actor pattern in a commercial embedded RTOS I designed, and it was the answer for all my concurrency needs lots of time later. If you're extensively calling lock/unlock in your user code, you're doing it wrong and it won't scale.

5. Functional programming principles, most notably immutability and avoiding stateful objects. It makes complicated logic so much more scalable and avoids ripple effects when doing modifications to the program flow.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#268

Microservices. 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…

A micro service should not depend on another micro service! I see the same mistake in plugin and module design patterns. When you make one service depended on another services you add complexity. Some complexity is necessary, but everything (scaling, redundancy, resilience, replacing, rewriting, removing, etc) will be more easy without it.

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#269
post #142

Earlier quoted context omitted.

Yes, then you're just doing bad OOP with sockets instead of a language that was designed for it.

Heh, definitely some truth to this. What saved us before, was our forest of code could depend on the database to maintain some sanity. And we leaned on it heavily. Hold a transaction open while 10,000 lines of code and a few N+1 queries do their business? Eh, okay, I guess. Maybe we didn't have the descipine to make microservices work. But IMO our engineering team was pretty good compared to others I've seen. All our…

Really, whenever someone blames "discipline" be suspicious

Not even the army has perfect discipline, even with hard training. They have cross-checks, piles of processes and move slowly for the most part

(Software development shouldn't aim to be like the army though)

Re: Ask HN: What made you change your mind about a programming language/paradigm?

#270
post #114

Earlier quoted context omitted.

I have a very high opinion of Julia's dynamic type system. Some static type systems are not very expressive, e.g., Elm, which encourages hacky workarounds. Julia's type system encourages specificity, which exposes problems early.

That's because it's a strong type system (as opposed to python's weak one where objects can change their shape anytime). Even calling it dynamic is a sort of lie since the compiler is always able to reason about the types it is given due to the way Julia's JIT compiler works. It's "dynamic" in the same way passing around `void*` (or `object`) is "static". That being said Julia's type system is definitely the way of t…

Python is strongly typed.

See here: https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic...

"objects can change their shape anytime" is a function of dynamic typing and is orthogonal to strong or weak typing.

Post reply on HN