Earlier quoted context omitted.
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.
Could you comment on these “aha” moments?
Ask HN: What made you change your mind about a programming language/paradigm?
351–360 of 401 posts
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#352Changed my mind on OO after seeing how difficult it is for ordinary humans to design objects that can withstand the spec changes that are inevitable in any real project. Bad procedural code is a mess but bad object code can be completely irreparable.
This.. bird is an animal but now we add air planes. It too flies. Is bird an animal or flying object? Already problems.
Reusability was biggest reason I liked oop. But you can't do that if while world doesn't cleanly derives from singularity.
it gets screwy fast if world changes.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#353Earlier quoted context omitted.
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).
Yes, that's exactly what it implies. Like I said at the top of this thread, I'm not an expert on this approach (I've done my reading, but haven't yet spent time in the trenches), but my understanding is that you would embrace the duplication and eventual consistency. I do wonder how well it works in practice though, and how much time you would spend running cross-service reconciliation checks to make sure your independent data stores are still in sync.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#354Earlier quoted context omitted.
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.
Because given how GUI frameworks are implemented, one needs to add explicit workarounds to follow "only write code for which there is a failing test".
After all, writing the test needs to be possible, to start with.
So adapters, views, commands and what have you need to exist only to fulfill such purpose, and even then, their interactions with the GUI layer don't get tested.
So one is creating them, without knowing if they are the right elements for the GUI layout.
Hence why testing, 100% behind it, TDD not so much.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#355Earlier quoted context omitted.
not necessarily if you design a decoupled event driven approach where every service can just subscribe to the data it needs.
We actually tried this as well. It never made it out of testing. We ended up with copies of data in many places, which was annoying. We duplicated a lot of work for consuming the same events across multiple services and making sure they updated the "projection" the same way. However a much larger problem was overall bad tooling. Specifically the data storage requirements for an event stream eclipsed our wildest proje…
I appreciate you sharing this. I'm considering embarking on this approach with my team, and everything you are mentioning is what I was worried about when I first started reading up on the microservices architecture.
Now I'm seriously considering a somewhat hybrid approach: Collect all of my domain data in one giant normalized operational data store (using a fairly traditional ETL approach for this piece), and then having separate schemas for my services. The service schemas would have denormalized objects that are designed for the functional needs of the service, and would be implemented either as materialized views built off the upstream data store, or possibly with an additional "data pump" approach where activity in the upstream data store would trigger some sort of asynchronous process to copy the data into the service schemas. That way my services would be logically decoupled in the sense that if I wanted I could separate the entire schema for a given service into its own separate database later if needed. But by keeping it all in one database for now, it should make reconciliation and data quality checks easier. Note that I don't have a huge amount of data to worry about (~1-2TB) which could make this feasible.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#356Immutability. 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]
How do you mitigate overhead from making copies all the time with immutability? By using moves and changing ownership a lot?
Some languages deal with this better than others through structural sharing, which reduces overhead significantly. The performance hit is usually unnoticeable in those languages and only becomes a problem in very specific cases ie. processing large strings, appending items to long lists, etc... some of those will cause you to rethink the way you do certain things (that is part of the FP journey).
In languages like JS or Ruby though, you might need to compromise. Generally I start with the immutable approach and refactor if performance becomes an issue.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#357Earlier quoted context omitted.
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.
In a dynamic language "strong" vs "weak" typing really depends on the standard library. All the examples in the given link - for example - focus on the addition function in the standard library. So here are some counter examples:
Everything can be used as a bool. This was often used to check for None, but had some issues when used with - for example - datetimes which evaluated midnight as false. In part due to the fact the integer 0 evaluates to false.
Changing type unexpectedly is the key example given in your link (`"foo" + 3` is `"foo3"`). Meanwhile in python `foo.method()` can change the type of the variable foo. Which is a level of fuckery commonly found in javascript.
Let alone the fact that dynamic duck typing encourages weak typing over performing explicit conversions. This is embodied by "easier to ask forgiveness than permission" which says it's better to catch the type conversion exception than check if the type is an integer ahead of time. Which then leads to implementing javascript-esque add functions anyway.
I'll grant you python is stronger than some other dynamic languages, but it is still at least half an order of magnitude weaker than Julia, which is strong in ways approaching Haskell.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#358Earlier quoted context omitted.
Try code large a GUI project without OO.
As the other commenter already pointed out, functional reactive programming wiped the floor (React) of OO style approaches to GUI design. It turns out thinking about interfaces is made considerably easier with one way data flow.
If you’ll open https://reactjs.org/ you’ll read right on their main page:
> Build encapsulated components that manage their own state, then compose them to make complex UIs.
Components managing their own state is a textbook definition of OOP. They even use inheritance in their example on the main page:
> class HelloMessage extends React.Component
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#359Actually using go-lang for a project.
I really don't like the language. It is verbose, with really simplistic error-handling, over-reliance on accepting interface{} in methods (meaning arbitrary object).
More-over, I really like the basic building blocks of functional programming, being able to map,fold/reduce,filter my way through the data I am dealing with, and with the lack of generics the golang-attitude seems to be "just write the damn for-loop".
But after ~3 months of writing golang services, it is actually quite pleasant to work with. Especially after they introduced `go mod` for dependency management. Ecosystem is nice. Libraries are nice. I even enjou the damn multi-megabyte staticly-linked libraries. I know I could have them in other languages. But I would have to fiddle.
With golang, I don't have to fiddle. That is really nice.
Re: Ask HN: What made you change your mind about a programming language/paradigm?
#360Testing. 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…
My experience has been very much the opposite - integration tests are often very brittle, and finding the root cause is often almost a fools errand since stack traces are often no good for figuring out what went wrong, at least for web UI. While yes, unit tests do have a maintenance burden, they are often reproducible, less flaky, give you targeted debug information, and run extremely fast. There are heavy costs to i…
Ideally, you should have both unit and integration tests. See "Test Pyramid".