nendroid

>Yeah, I suspected that you and lerptime were the same person.

to get around the post limit. Keep it on the DL.

>When you make such a statement, you sound like someone with fairly limited experience. In particular, from your example, I suspect that you've never worked in a multi-threaded embedded system. somethingToBeInSyncTo, done that way, means that any other thread holding a reference, holds a reference to the old value, while this thread has the new one. And updating running threads with new values on the fly is... problematic.

I find that you're the one who seems inexperienced. My example is thread safe ... makeNewState is a combinator. It makes no mutations. Like IO, and mutations, the problems with threading happen with mutation. Thus, locks and other procedural commands used to deal with threading live in the void IO function.

We're more referring to coupling functions with external data and mutations via objects. If you're talking about synchronizing two threads, this again needs to be handled with parent IO function outside the logic of your pipeline combinators. You can still segregate logic away from threading and IO.

My combinator in this case is useable for your example case of synchronizing two threads. If you organized your code in ways where my combinator will be unusable than you have failed to decouple your logic away from threading, IO and mutation.

>You seem to think that FP is the one right answer. You are mistaken. There are places where it's the right answer, or at least a very good one - the best definition I've seen is when your program looks like a pipe.

All programs are pipes from IO to IO or from one state to another state. Purity lives in the pipes, impurity lives in the IO nodes between the pipes. The goal is to keep the impurity as small as possible and have most of your logic live in the pipe, as combinators are the most composeable primitive. I also never said FP is the one right answer. Most programs need to modify state. In FP everything is immutable so your program cannot be pure FP in most cases. What I am saying is to segregate state and IO from logic. Example:

    void addOneToState()

can be broken down into

    int addNTo(int n, int m)

    void changeStateTo(int x)

I have split the code above into a method that is devoid of logic and only updates state and logic that lives as a stateless combinator. All programs are made from a series of pipes and tubes. You just need to find the pipe and modularize it and seperate it from the parts that can't be pipes.

>At that point, bundling the data to the functions is warranted.

It's never warranted. There is no benefit. Whether you couple it or uncouple it from data the logic still exists, the only difference is coupling. Adding coupling does not improve your code in any other way other than adding coupling.

>And if you're going to say "don't structure the data that way", well, there are times when that's the nature of the problem, not just the nature of the program to solve the problem.

There is no data structure that has to be coupled with logic. However you structure your data it can always be decoupled from logic. Always.

>where your program has state, and there are multiple parts to the state, and those parts have to be kept in sync with each other.

This doesn't change anything.

   State makeNewState (State oldState) {
        newY = addNTo(oldState.y, 1)
        return New State {
              x = oldState.x
              y = newY
              somethingToBeInSyncTo = newY
        }
   }

   void updateState(State x)

y is still in sync with somethingToBeInSyncTo.

If you look at it objectively. There's a very clear reason why OOP inevitably fails.

Maybe a better way to put it is that SOLID is an ideal that OOP aspires to be but fails.

Either way SOLID is a bad set of axiomatic design principles. It's sort of an arbitrary group of rule of thumb principles picked to spell out SOLID.

There's a style of programming with no concept of loops or jumps. It's called functional programming. There's other styles that are drastically different as well.

Most of these styles aren't new though.

I feel that SOLID doesn't even work well with OOP. Overall it's just saying "be more modular" in a programming paradigm that's one of the least modular styles ever created.

I disagree with Martin very much. Programs can be made easy to change without introducing complex OOP abstractions.

There is a simple rule that Martin fails to ever mention.

Use combinators as much as possible and segregate as much logic as possible from IO. That's it.

SOLID is just a random arbitrary acronym about some principles that are somewhat obvious. However most people don't fully understand these principles deeply. What happens is if you are using OOP you are not using SOLID to its full extent. Ironic that SOLID comes from OOP.

Either way SOLID are arbitrary rules of thumb. Grouped together arbitrarily to spell out SOLID and kind of maybe sort of right depending on your opinion.

   1. SRP. Gather together the things that change for the same reasons. Separate things that change for different reasons.

I disagree. Unless this thing is talking about namespacing which is more of an aesthetic/psychological thing... You should not organize your program this way where logic of one thing is tied with the logic of another thing. All things should be ungrouped as much as possible.

You should also separate all things that "change" and all things that don't "change" and try to keep the things that "change" as small as possible.

All logical modules in your program should be separated as much as possible at the lowest layer, nothing should be grouped... and higher layers should be compositions of lower layers. But the basis of your program at the lowest layer: everything should be separated and nothing should be grouped.

In other words use combinators as MUCH as possible. OOP's promotion of methods that operate on shared mutable external scope actually prevent you from doing this.

  2. A Module should be open for extension but closed for modification.

Agreed. The problem is if your program is OOP your modules are objects which group methods together through shared mutable state. It means that you cannot extend one method without modifying the entire object.

So basically OOP practitioners can never modify an addOne method into addTwo. They can't even add an addTwo method into the object as that constitutes modification. What they can do is inject that entire object into another object. Either do this or use inheritance which OOP says is just bad.

Instead. Use combinators. You have an addOne combinator? Create an addTwo combinator. Recompose your combinators to form the higher level logic you wanted.

  3. A program that uses an interface must not be confused by an implementation of that interface.

Yeah I mean sure. Don't have your flatten Function be able to operate on an integer.

  4. Keep interfaces small so that users don’t end up depending on things they don’t need.

Agreed the problem is, the definition of an object in OOP usually ties muteable state and logic together. Your average object has a getter and setter which are tied together by external scope, so by definition OOP ties together things that shouldn't belong together. You are not keeping your interfaces small.... by definition it is already too big.

If you defined the logic as I said above separating state changes away from combinators you'd have even smaller interfaces. One for changing state. And the other logic is stateless.

  5. Dependency inversion principle.

I mean yeah. Write your logic in layers. The problem is OOP people only use this principle at the module level.

The better way to program is to have all your methods follow the dependency inversion principle. You can't do this if methods are modifying external scope shared by another method. Use combinators and by definition every sector of your program is following this principle not just "modules"

Which is the majority of applications nowadays.

You deploy to the cloud. The customer downloads a web page and that functions as a client that communicates with the python server. Just like how most programming is nowadays.

But if you want a customer to download an app, which is much more rare nowadays than you can do what Eve online does or iron mail. They deliver actual client side python apps. I don't know what they use internally or how they did it, but pyinstaller is one option you can use to build a python executable.

I think the government itself should record all trials not for public release but for archival, evidence and review. How else do you being down a racist or corrupt judge?

The effort required for this makes it not worth it.

If I want a library in python it takes about a second to install with one command, and these libraries tend to be safe so you're not going to get any resistance if you want to try out 10 libraries in the next hour or so, which is sort of impossible with c++. Also these libraries are easily uninstalled and isolated from other python apps you have. No need to use massively complex package managers like nix to handle isolation.

Fuzzing a library just isn't something that's done in python. The developer just installs it and manually tests it 5 or 6 times in a shell and it's part of the ecosystem in 5 minutes.

If you accidentally leave unused libraries in your code and it gets pushed to prod it's a non-issue.

I switched to c++ because I was ok with the verbosity and also the complexity and also dealing with memory. But literally every single corner of the c++ ecosystem is a pain in the ass to work with. It's getting to the point where I'm just annoyed all the time. If you want high performance apps go with rust or golang. C++ is just not worth it.

For a C++ dev moving to python is like night and day. Imagine a programming environment where you only have to deal with the intention of what your app should do and not all the yak shaving that comes with it on the side. I know some and they tell me they would never go back to c++.

I do have experience. It's my main language and my current job. C++ really sucks to work with for a developer even with types.

For building cloud services where apps are bottlenecked by the database, the user experience is roughly the same as C++ but the developer experience with python is much much much more easier.

This attitude where consumers have to run the apps or install a runtime to run the app on there personal machines is much more rare nowadays.

No it doesn't... but it's far less likely to occur. Web development practices usually avoid this problem as state is handled externally.

Nah it's a big unicorn startup down in Irvine, so the codebase is still relatively new. They use C++17 so pretty modern as well.

> I still believe analogies have more value than being mere approximations to an unimaginable world

I didn't say this. Although my example is actually impossible to understand without an analogy, I am saying an analogy can help you understand something you currently don't understand.... it does not need to be impossible to understand without an analogy.

The quotes in my link are actually mostly things and concepts you completely understand. Nothing new is learned... the analogy is deception.

Python developer here just switched jobs to one that does C++.

Let me warn you right now. It's not worth it. At all. Don't go down this path. Memory management is easy, but that's not the only crap you have to deal with.

Templating and the whole C++ ecosystem with Cmake compiling to make is a giant headache. It takes about a week to integrate a new C++ library in source code and people are worried about installing or "trying" out new libraries because of memory leaks.... while in python I'll install an entire library in seconds just to try out a function.

I would say if you made an app in python and the same exact app in C++, the C++ app would perform waay better. No question. But the developer experience and effort required to make that same app is much much more painful.

>Like every programming language out there, C++ is a tool. And like every tool out there it has its uses.

And like every tool some tools are crap and other tools are good. Not saying C++ is crap but I'm definitely saying that it is unwise to use this analogy to believe that there are no crap tools out there.

There's this thing that happens among programming languages where everyone likes to think all programming languages are just apples and oranges and everything is equal.

The truth about the world is equality is rare... some things are good and others pure liquid shit. Programming languages are not immune from this property of the universe.

Now about C++... What you say about it is true. I completely agree. However, much of the good of C++ comes with a pile of crap that you have to deal with that's often not worth it for the majority of projects. In my opinion C++ is only good because there's no alternative unless you count Rust or D.

1. No, I don't disregard analogies, I'm just able to recognize and isolate analogies from a topic or a point. For learning, I agree an analogy is very useful.

Analogies are tools for illustration, not for proving a point. To use a tool to illustrate a concept that is already well known (learning for example) is often pointless.

In terms of utility, much of the utility of analogies is similar to the utility of art, music or humor. You can enjoy humor, but humor itself doesn't offer any greater insight or a topic.

2. Analogies are useful for illustrating things that cannot be imagined by the human mind. The extrusion of a 3 dimensional cube into a 4 dimensional cube cannot be pictured by your minds eye. You can only visualize the analogy: The extrusion of a 2 dimensional square plane to a 3 dimensional cube. The entire field and existence of higher dimensional geometry is inferred from analogies.

Note that these are only good for things that are not known by you. Much of literature and speeches use analogies for things that are well known. For a list of examples where analogies are mostly useless see here:

https://www.goodreads.com/quotes/tag/analogy

You want to encode as much context into the name as possible without breaking abstraction. Meaning that the definition of the function should not be part of the name. Only the API of the function and context should be encoded into the name.

So for example:

    areaOfTwoDimensionalBox

is better than:

    area

is better than:

   widthOfBox_times_heightOfBox

Careful. Analogies are a common form of deception. Used often in religious speeches, political speeches, blog posts and more.

The speaker offers zero substantial information yet manipulates the audience into feeling the speech was "good" through the use of analogies. There is sort of a catharsis when the person listening to the speech connects the dots between two unrelated concepts, and this subtle emotion is used as a form of manipulation often deliberately when the speaker is incredibly intelligent and often accidentally as is what I believe is the case here.

It's easiest to see the deliberate case in religious speeches or sermons if you're not religious yourself. Often you will find that religious principles or sayings have no proof and you will often find that the analogy is deceptively used in place of evidence or proof where no proof exists.

A baby can crawl in random directions. Of course I'll protect him from crawling off a ledge. But when he has the capacity to understand and judge I coddle as little as possible and expose as much possible. 5-6 is around the right time.

At 3 I don't let him run across the street. At 5 I tell him to look both ways and I tell him what happens to someone who doesn't, then I let him play outside.

Scientists can't prove anything. They can only make statistical correlations and establish causation to a degree.

When I use the word "prove" i don't mean like proving things in math. Nobody means this, it's obvious to everyone what they mean. Prove in this context means well established. For example if I say scientists have proved the theory of gravity.

What's going on here is extreme pedantry. Prove has meaning in different contexts, you have chosen the most technical pedantic context to suit some misguided purpose rather than the most obvious context. There's no point in taking this further.

6 year old.

At 3, he just had a playstation.

Whatever works is what I believe. I feel lots of parents just don't have the balls to not coddle their children, and they justify this fear with rude comments like this.

FYI the two blind kids actually knew each other when they were kids, and I "kid" you not the kid that was the "libertarian" bullied and beat up the other one because he was thinking "wtf, why is this other kid helpless."

Listen to both podcasts. Worth it for any parent as it gives a true more "scientific" perspective on the coddling going on with kids today.

Doesn't make sense because kids today are exactly the same as kids in the past.

This is science and its about research that the scientist did to prove something.

You have to analyze the reality of this world. First off open source cannot exist without closed source.

Imagine if everything in the world went open source. Then nobody would be getting paid, everyone would starve because they're giving away there work for free.

Most things in this world are profit oriented products produced as a direct result a capitalism. Open source is an offshoot phenomenon in software arising because software is both easier than other forms of engineering (see thousands of bootcamps) and also easily copyable.

However it should be known that most software developers need to have a job in closed source software in order to pay the bills.

Whenever you see something open source you have to know it's an offshoot phenomenon. These are side projects spawned by intense interest but ultimately still a side project to a person's main line of work which is ultimately profitable. Be surprised that there are 3D printers because it's abnormal. The fact that there are no open source 2D printers arises because there's lack of interest and because there's no profit in open source 2D printers.

Your kid will be corrupted by society anyway. What's this whole thing about protecting children from the reality of the real world anyway?

A bit off topic but a serious question. What's your logical reasoning for blocking the content now. It's just slowing down what he will be able to see (by deliberately going around you) within a couple years. I never understood this with parents.

One thing (out of many) I always hated about linux is the upgrades. I have to reinstall the entire operating system just to upgrade.

I'm using manjaro now, I want see what happens when there's a big version change.

WSL 2 is making windows one of the best operating systems to run linux applications on.

>Second, Python 2 to Python 3 was horrible, and created political problems which hadn't existed before. Now, at the end of the transition, we can see how badly it was managed; Python 2 could have been retrofitted with nearly every breaking change and it would have been lower-friction.

This doesn't make any logical sense. Your saying take the breaking changes in python 3 and put it into python 2? That's just a version number. You can call it version 2.999999.8 and do all the changes in there and the outcome is identical.

No. Every breaking change must have a downstream change in every library that uses that breaking change. That's the reality of breaking changes. No way around it.

Tell me of such a migration as huge as python 2->3 that was as successful. For sure there were huge problems along the way and it took forever. However I have heard of very very few migrations in the open source world that ended up with an outcome as successful as python.

>First, the excellent readability leads directly into hard-to-read code structures.

I don't agree with this either. You refer to fortran but most programmers here haven't used it so you'll have to provide an example for readers to see your point.