Live data from Hacker News

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

news.ycombinator.com

341–350 of 401 posts

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

#341

I didn't like python at first. The mentality of "hardware is cheap, there's no need to be that fast" drove me away from it full speed. However, I was short on time for something, and I gave it a try, then I actually liked it a lot. It's very practical and fast enough for most cases. The string processing capabilities has blown me away, however it didn't change my love for higher performance, compiled languages. Now I…

> It felt slow, heavy, bloated, unnecessarily Enterprise.

You can avoid the "unnecessarily Enterprise" by not writing code in the Enterprise fashion.

Not every class needs to be an extension of an abstract class that implements an interface. Not every class needs a factory class. Not every operation needs to be abstracted. If you have a class that has just a constructor and a single function, you probably don't need a class and can just write a function.

Most complaints about Java are really complaints about some idiotic Java paradigms that seem to have been invented by someone that measures productivity in LoC written or classes implemented.

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

#342

Earlier quoted context omitted.

I guess... though I’ve always found C++ libraries to be light years easier to manage than python. To be honest, the per-language package management seems wasteful and chaotic. I must have a dozen (mutually compatible) of numpy scattered around. And why is pip responsible for building FORTRAN anyway?

You think dealing with C++ libraries is easier than "pip install "?

Yes, definitely. In C or C++, I use my distro's package manager to manage the libraries, not some other tool.

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

#343
post #88

Earlier quoted context omitted.

I started using python 3 with mypy, which provides (optional) static typing, and my gosh has it reduced the time I spend looking for stupid problems by orders of magnitude. I got a somewhat direct comparison when I mypy-ified a small program where I used a lot of async and await (basically implementing own event loops and schedulers, it was interfacing very custom hardware that handled very different but interacting…

as a serious question, why even use python if you have to go through hoops to make it work even half as well as other languages? are you reliant upon some python only library?

In my experience, Python is usually used because of a low barrier-to-entry and the availability of a lot of libraries. It's great for slapping something together quickly to do something useful. However, if you want something that's high-performance and well-engineered, it just isn't the right tool for the job usually.

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

#344
post #312

Earlier quoted context omitted.

Agreed. As part of the transition process from Python 2 to 3, I pushed for typing on all of the critical components. I had to fight the management a little on the commitment, but in the long run it's saved us a ton of time identifying and preventing bugs and its made the entire codebase much more cohesive.

does the management agree with that assessment? these kind of changes are often hard to evaluate because ot is not easy to compare. did development really go faster because of types, or do we just think it did? i agree that typing saves time but i am struggling to produce evidence for that

It's not very hard to find the evidence before you move to static typing.

Just think about this not uncommon scenario: "The program crashed two hours into testing because apparently, we somewhere set this element in this deep structure to an integer instead of a list, and are now trying to iterate over that integer. But we cannot easily fix it, because we don't know yet where and why we set it to an integer."

The compiler would have immediately given you an error instead.

So, collect all the errors that are, e.g.:

- Addressing the wrong element in a tuple,

- any problems arising from changing the type of something; not just the fundamental highest level type ("list" or "integer"), but small changes in its deeper structure as well, e.g. changing an integer deep in a complex structure to be another tuple instead,

- "missed spots" when changing what parameters a function accepts; this overlaps with the former point if it still accepts the same arguments on the surface, but their types change (in obvious, or subtle "deep" ways),

- any problems arising from nesting of promises and non-promise values,

and many, many other problems where you can trivially conclude that the compiler would have spit out an error immediately, and explain to management how various multi-hour debugging session could have been resolved before even running your thing.

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

#345
post #119

Earlier quoted context omitted.

Hah, I had the same thought when I first started using Python for some personal stuff many years ago. I enjoyed using it and it was quick to get some code out but I thought to myself "surely if you build anything large with this language it will be a massive pain to maintain". Fortunately(?), I never worked for a company that used it for a large codebase so I never found out if my assumption was correct or not.

You need a QA strategy to match the technology in use. No static type checking means many mistakes will need to be caught in another way. For instance with automated tests, or design-by-contracts. Which might also catch some things that static typing would not cover. In a non-trivial system with solid engineering, QA concerns quickly go beyond details like which programming language is used. Like how to QA entire sys…

That's a very good point: different languages require different QA strategies (do statically typed languages require less unit tests?).

My initial thought when working with Python wasn't from a bugs/QA point of view but merely looking at the productivity of a developer working on a large code-base. Things like accurate auto-complete, code discovery, architectural understanding, knowing what 'kind' of object a function returns and so on become more important once the codebase and the amount of engineers working on it increases.

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

#346

I didn't like python at first. The mentality of "hardware is cheap, there's no need to be that fast" drove me away from it full speed. However, I was short on time for something, and I gave it a try, then I actually liked it a lot. It's very practical and fast enough for most cases. The string processing capabilities has blown me away, however it didn't change my love for higher performance, compiled languages. Now I…

> It felt slow, heavy, bloated, unnecessarily Enterprise. You can avoid the "unnecessarily Enterprise" by not writing code in the Enterprise fashion. Not every class needs to be an extension of an abstract class that implements an interface. Not every class needs a factory class. Not every operation needs to be abstracted. If you have a class that has just a constructor and a single function, you probably don't need…

Java's "unnecessarily enterprise" feeling didn't come from the paradigms that increase the LoC (abstraction, interfaces, factory classes, etc.), but from the way it developed, where it used and how it behaved.

This feeling is also reinforced by the prime editors of that time: Eclipse and Netbeans. Both are behemoths which were written in Java, heavy, resource intensive and somewhat slow. In the 2000s, Java wasn't that fast and refined, and it showed and felt profoundly, at least by me.

With the open sourcing of Java and the performance jump happened with Intel's Core i series CPUs, Java got a lot lighter. I've never had hard feelings against any programming language, and I hold no grudge against Java, but I currently don't need it, so I'm not using it.

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

#347

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 have the same experience. Integration tests are the best. They test only what really matters and allow you to keep flexibility over implementation details. When your TDD approach revolves around integration tests, you have complete freedom to add, remove and shift around internal components. Having the flexibility to keep moving around the guts of a system to bring it closer to its intended behavior is what softwar…

Fyi, I'm definitely stealing your analogy.

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

#348
post #333
post #332

Earlier quoted context omitted.

GUIs don't lend themselves to unit testing at all, because the requirements aren't mathematical, but are instead based on human factors. For GUIs, the proper approach is to unit-test the functionality underneath, not the GUI itself.

Which leads to convoluted architectures just to be able to follow "only write code which there is a failing test for".

How are these convoluted?

After all, any program out there does something. If you know what it's doing, you know what it should do, and what it shouldn't. That means you can test it.

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

#349

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…

Sorry for your pain, you have some studying up to do. There's already best practices on these. Checkout 12factor

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

#350

Earlier quoted context omitted.

>but white space just is not one of them. This position is hard to maintain after you've spent an hour trying to debug a nonsensical error just to realize you opened the python file in an editor that used a different tab/space setting than the file was created in. Significant whitespace is one of the biggest misfeatures in programming history.

I've been writing Python for over 20 years, and I don't think this has happened to me one single time. I'm not some kind of super programmer; I make as many mistakes as anybody else and spend too long debugging stupid mistakes occasionally. I've mixed spaces and tabs before on a handful of occasions, and it's always told me straight away what the problem is. Here is an example of mixed spaces and tabs for indentation…

Here's an example of an incomprehensible error related to mixing whitespace, where its not obvious its a mixed whitespace issue:

https://repl.it/repls/MotionlessLustrousScan

Post reply on HN