371–380 of 401 posts
Earlier quoted context omitted.
The addition of type annotations alone makes it a hugely different language.
The annotations that nobody actually uses? Call me back in 2030, when they become halfway popular.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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?
The old list of official aha's is: Monads, applicative functors, lenses. But really it's about spending time learning them well enough to use normally.
Earlier quoted context omitted.
Could you comment on these “aha” moments?
Basically you start to ingrain how to use the tools there for problems that you solve differently in other systems. Then you start looking for ways to get rid of the awkward parts of your code The old list of official aha's is: Monads, applicative functors, lenses. But really it's about spending time learning them well enough to use normally.
Earlier quoted context omitted.
I don't miss, `shared_ptr`. It is a disaster for anything other sharing a thing between threads (in which case, it is a way of managing the disaster you already have). Now `unique_ptr` is worth missing. And destructors are good too -- you couldn't have unique_ptr without them. But in it's own way, C has both: its just you just have to remember to call the destructor yourself, every single time.
Doesn't have to be threads, different contexts.
You start using `shared_ptr` because you are too confused about the code to know which of the two "contexts" is supposed to own the thing. So shared_ptr (might) fix your memory freeing problem, but it maintains (and sometimes worsens) the problems caused by having two different contexts that might or might not be alive at any given time.
With two different threads however, such problems are often unremoveable, which is why shared_ptr is the right solution mitigation.
Earlier quoted context omitted.
Our age difference explains a lot of your recalcitrance towards new (to you) things.
It amazes me that you dismiss someone with 20 years more experience than you as somehow knowing less. Python isn't new to me: it's old, and it's crap, and its "evolution" is towards a dead end. Stuff like nodejs will eventually supplant it if it hasn't already, and with good reason (not that I am a huge fan). Python was a novel design and a great choice ... back in the 90s. I mean, use it if you like it; use Forth or…
Python should be new to you, or at least newer than when you first encountered it. The fact that it's not means you have no clue what changed, so you have no clue if it's any better.
The only thing that needs to be abandoned is this fake idea that older people carry knowledge that can't be expressed except in the form of trust. If you've got reasons, let's hear 'em, but "I'm old" isn't a reason to do anything.
Earlier quoted context omitted.
It amazes me that you dismiss someone with 20 years more experience than you as somehow knowing less. Python isn't new to me: it's old, and it's crap, and its "evolution" is towards a dead end. Stuff like nodejs will eventually supplant it if it hasn't already, and with good reason (not that I am a huge fan). Python was a novel design and a great choice ... back in the 90s. I mean, use it if you like it; use Forth or…
You didn't die. Congrats, but that doesn't give you knowledge I don't have. Python should be new to you, or at least newer than when you first encountered it. The fact that it's not means you have no clue what changed, so you have no clue if it's any better. The only thing that needs to be abandoned is this fake idea that older people carry knowledge that can't be expressed except in the form of trust. If you've got…
Mind boggling really.
Earlier quoted context omitted.
That's relying on distribution package management to save you. Here is what happens when you add libraries in any other context: The library has a dependency on another library, and when you go look at the dependency, it tells you that it needs to use a specific build system. So you have to build the library and its dependency, and then you might be able to link it. But then, turns out, the dependency also has depend…
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?
Earlier quoted context omitted.
You didn't die. Congrats, but that doesn't give you knowledge I don't have. Python should be new to you, or at least newer than when you first encountered it. The fact that it's not means you have no clue what changed, so you have no clue if it's any better. The only thing that needs to be abandoned is this fake idea that older people carry knowledge that can't be expressed except in the form of trust. If you've got…
I already gave you reasons; the fact that you can't understand them because you're a language zealot isn't my fault. Mind boggling really.
Ladder of abstraction and Functional Programming [1] http://worrydream.com/LadderOfAbstraction/ [2] https://en.wikibooks.org/wiki/Computer_Programming/Functiona...