Live data from Hacker News

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

news.ycombinator.com

201–210 of 401 posts

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

#201

Earlier quoted context omitted.

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

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

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

#202

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…

you can also unit test in a more blackbox way where you test your interal APIs instead of the implementation. It makes sense to have both in many cases.

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

#204
post #92

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

In Haskell there is a ghc flag to defer type errors.

https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_gui...

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

#205
post #114
post #83

Earlier quoted context omitted.

I think dynamically types languages are on their way out. There aren't many good arguments remaining in favor of them.

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 the future in my opinion.

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

#206

This is probably an unpopular opinion - Haskell, I used to think it must be cool (and useful) since people go on about it so much. I spent quite a bit of time learning it, and imho the usefulness to practicing programmers is marginal at best. It does present some useful techniques that are making their way into languages (e.g. swift optionals), but in general it didn't live up to the hype for me. I feel a lot of the…

I tinkered with it for years before finding the aha moments that really made it day more productive than my day job languages. Now I feel I could race a team of programmers in those languages and be far in front.

In what sort of application would you say that its better?

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

#207

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 will probably be the lone voice here defending mock testing but probably not for the reasons you'd expect. Does mock testing end up being brittle? Yes. Do you have to refactor the tests immediately after making small changes? Yes. Is there a cost to this? Yes. Mock based testing however is the only thing I've ever encountered that forces me to think very, very clearly about what my code is doing. It makes me inspec…

Outside in development with mocks is awesome. Just replace the mocks when you know what you are building ;-)

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

#208

Earlier quoted context omitted.

I tinkered with it for years before finding the aha moments that really made it day more productive than my day job languages. Now I feel I could race a team of programmers in those languages and be far in front.

In what sort of application would you say that its better?

Every one I've tried so far. Command line, server side, and some light web. I haven't tried mobile.

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

#209

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…

> Unit test suites would break all the time for silly reasons, like someone optimizing a function would mean a spy wouldn't get called with the same intermediary data, and you'd have to stop and go fix the test code that was now broken, even though the actual code worked as intended. Can you or others speak more about this? I was taught that verifying function calls for spies/mocks was good practice. But, I encounter…

This is usually called the classical vs. mockist, or test interactions vs. test final state debate.

Instead of mocks, some people prefer to build fakes / stubs which are versions of a dependency which are "fully operative" in a sense but with a simplified internal implementation. For example a repository that keeps entities in memory. (Not the same as an in-memory database! The fake repository wouldn't use SQL at all.)

Tests would check the final state of the fakes after the interactions, or simply verify that the values returned by the tested component are correct.

The hope is that fakes, while possibly more laborious to set up, allow an style of testing that focuses less on the exact interactions between components, and therefore is less brittle.

Some links:

- Mocks aren't stubs https://martinfowler.com/articles/mocksArentStubs.html#Class...

- From interaction-based to state-based testing http://blog.ploeh.dk/2019/02/18/from-interaction-based-to-st...

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

#210
post #120
post #87

Earlier quoted context omitted.

Genuinely asking: could you provide some specific example? What does CL has that Pythos doesn’t? (Disclaimer: i never worked on neither)

If I had to point to something, I would single out CL's powerful support for multiple dispatch. I'd hesitate to recommend CL to undisciplined programmers, because it is too easy to write code that works but you don't understand a week later.

(I hammered out that answer right before I had to run on stage. A couple other big items I forgot:)

A proper numeric tower. Python has complex numbers, but they don't seem well integrated (why is math.cos(1+2j) a TypeError?). Fractions are frequently very useful, too, and Python has them, in a library, but "import fractions; fractions.Fraction(1,2)" is so much more verbose than "1/2" that nobody seems to ever use them.

Conditions! Lisp's debugger capabilities are amazing. And JWZ was right: sometimes you want to signal without throwing. Once you've used conditions, you'll have trouble going back to exceptions. They feel restrictive.

(I've come to accept that in a language with immutable data types, like Clojure, exceptions make sense. Exceptions feel out of place, though, in a language with mutability.)

Other big wins: keywords, multiple return values, FORMAT (printf on steroids), compile-time evaluation, a native compiler (and disassembler) with optional type declarations.

Lisp is unique among the languages I've used in that it has lots of features that seem designed to make writing large programs easier, and the features are all (for the most part) incredibly cohesive.

Post reply on HN