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
Ask HN: What made you change your mind about a programming language/paradigm?
201–210 of 401 posts
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#202Testing. 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…
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#203Re: Ask HN: What made you change your mind about a programming language/paradigm?
#204The 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…
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?
#205Earlier 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 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?
#206This 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.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#207Testing. 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…
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#208Earlier 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?
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#209Testing. 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…
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?
#210Earlier 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.
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.