Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solid Relevance

blog.cleancoder.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Solid Relevance

#31

Post by lerptime »

buzzerbetrayed wrote: post #29
lerptime wrote: post #25

Earlier quoted context omitted.

He's not talking about machine level code. He's talking about while loops in regular programming. I don't think the person was aware that there are paradigms that avoid looping. To be more pedantic and get even lower level than machine code, at the theoretical level the basis of computation can be either procedural or functional. See lambda calculus and Turing machine for more info.

You don't think Uncle Bob knows there are paradigms that avoid looping? Sorry, but that is absurd. This isn't some random internet blogger. Uncle Bob has proven himself knowledgable enough to know something as basic as that, even if he is a controversial figure. And please let me know if "the person" refers to someone else. I've read the comment chain all the way up and can only make sense of what you said if "the pe…

I don't know about uncle bob. But certainly what he said is untrue. Programming doesn't even have "while loops" as a primitive. From that wrong statement I assume uncle bob doesn't know much.

Of course I could be wrong. I don't know the guy. But that statement alone is enough for me to make a negative judgement against him.

Re: Solid Relevance

#32

Post by jdmichal »

lerptime wrote: post #22
AlchemistCamp wrote: post #20

Earlier quoted context omitted.

> All things should be ungrouped as much as possible. Why?

Because you cannot predict the future of your program. Coupled logic that seems correct now may need to be uncoupled in the future. By having every sector of logic be ungrouped it leads to maximum reusability for the future. Technical debt is at the lowest possible level in projects where every piece of logic is uncoupled. In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. By hav…

I think you're basically describing the idea of having pure computations on pure data objects as much as possible? In which case, I believe that's fairly idiomatic in functional languages. And it's becoming more common in languages like C# and Java that started out OOP but have introduced enough functional niceties to make that style more idiomatic. I've been doing it in Java for at least three years. Here's a comment I wrote about it from then:

https://news.ycombinator.com/item?id=14687947

Re: Solid Relevance

#33

Post by to11mtm »

AnimalMuppet wrote: post #28
elric wrote: post #17

Earlier quoted context omitted.

I believe you're referring to his statement that essentially no new programming paradigms have been discovered since the 60s? Are you saying you disagree? Basically every major programming paradigm had been discovered by the 60s. I'd be happy to hear otherwise.

I think that generic programming wasn't really a thing until Stepanov with the STL in the 1990s. There may have been glimmerings of it, but I know of no actual, significant implementations before that. Corrections welcome...

> Corrections welcome...

You're cool.

Most think ML[0] did it first, and dare I say did it right first. It gets rid of entire categories of boilerplate (interfaces come to mind) because types are fully inferred. In other words, if `funpost(request)` uses .User, .Body, .Time, from request, the only requirement is that the 'request' object has those properties with correct types further down the chain in usage. Other languages can do this but not typically to the degree in ML's type system (known as Hindley-Milner [1]). There are times it can't quite figure it out but it is, again, less frequent than in others.

[0] - https://en.wikipedia.org/wiki/ML_(programming_language) [1] - https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...

Re: Solid Relevance

#34

Post by to11mtm »

lerptime wrote: post #30
AnimalMuppet wrote: post #27

Earlier quoted context omitted.

Very, very wrong. > In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see wha…

No you're very wrong. >No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. All this logic must exist regardless of whether it's coupled or…

> Let's be clear though. I am saying that the lower levels of your application should be ALL uncoupled logic. Then you build logical layers on top of your primitives that consists of compositions of your logic that build higher and higher. So a person on layer 5 only needs to go to layer 4 to understand it, and does not need to go to layer 1 to understand every primitive.

Yep. If you do this right you only need to understand one or two layers at a time. Great example of this is the Akka Toolkits for JVM and .NET; Every time I've hacked on a given subsection, the amount of domain knowledge I've had to have was 'Basics anyone using Akka has to know' and then just the layer I was working with and maybe one other.

> The problem is OOP does this all the time. It couples state with logic. These two things should be uncoupled.

Agreed. And dare I say, when you start going from coupled state+logic, and go more towards functional... you'll find you can possibly shed a layer or two in your overall design.

Re: Solid Relevance

#35

Post by ch_123 »

> His points were that the Open-Closed principle isn’t very important anymore because most of the code we write isn’t contained in large monoliths and making changes to small microservices is safe and easy.

IMHO, Open-Closed applies just as well to entire microservice architectures as it does to individual classes. For example, I've seen services for general-purpose tasks such as job scheduling or generating PDF reports which required devs to change the code to add a new job type or report type. These services were replaced by services where the new application-specific types could be defined through an API, which meant that those services were "done" and reduced the amount of work required to use them.

Re: Solid Relevance

#36

Post by commandlinefan »

lerptime wrote: post #31
buzzerbetrayed wrote: post #29

Earlier quoted context omitted.

You don't think Uncle Bob knows there are paradigms that avoid looping? Sorry, but that is absurd. This isn't some random internet blogger. Uncle Bob has proven himself knowledgable enough to know something as basic as that, even if he is a controversial figure. And please let me know if "the person" refers to someone else. I've read the comment chain all the way up and can only make sense of what you said if "the pe…

I don't know about uncle bob. But certainly what he said is untrue. Programming doesn't even have "while loops" as a primitive. From that wrong statement I assume uncle bob doesn't know much. Of course I could be wrong. I don't know the guy. But that statement alone is enough for me to make a negative judgement against him.

Well, all electronic computers all the way back to the Mark II have had unconditional branches (jumps) and conditional branches: I guess you're strictly correct that "while loops" aren't technically primitives, but conditional branches are and the only reason you'd ever use one is to perform the equivalent of an if or a while.

Re: Solid Relevance

#37

Post by commandlinefan »

ajuc wrote: post #18
commandlinefan wrote: post #16

Earlier quoted context omitted.

Well, at the risk of being pedantic, I think you're being pedantic: at the machine-code level, all those function calls resolve to jumps and their recursive base-cases are terminating cases of loops. Functional programming is a great way of organizing loops and jumps, but they're still loops and jumps.

At the machine code level there's no Iteration just GOTO :)

Well, there's unconditional goto (jmp) and conditional "goto" (branch).

Re: Solid Relevance

#38

Post by AnimalMuppet »

to11mtm wrote: post #33
AnimalMuppet wrote: post #28

Earlier quoted context omitted.

I think that generic programming wasn't really a thing until Stepanov with the STL in the 1990s. There may have been glimmerings of it, but I know of no actual, significant implementations before that. Corrections welcome...

> Corrections welcome... You're cool. Most think ML[0] did it first, and dare I say did it right first. It gets rid of entire categories of boilerplate (interfaces come to mind) because types are fully inferred. In other words, if `funpost(request)` uses .User, .Body, .Time, from request, the only requirement is that the 'request' object has those properties with correct types further down the chain in usage. Other l…

OK. That's still in the 70s, though, not the 60s (going back to elric's question).

Re: Solid Relevance

#39

Post by AnimalMuppet »

lerptime wrote: post #30
AnimalMuppet wrote: post #27

Earlier quoted context omitted.

Very, very wrong. > In fact the very phenomenon of Technical debt arises from logic that's hard to uncouple. No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see wha…

No you're very wrong. >No, one kind of technical debt arises that way. Not the only kind. There's another kind that arises when everything is in such small pieces that nobody can tell how the pieces relate to each other. You can easily understand each piece, but you have to go through a chain of a bazillion function calls to see what's actually going on. All this logic must exist regardless of whether it's coupled or…

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.

And there are places where FP is the wrong answer - 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. At that point, bundling the data to the functions is warranted, because it limits the number of functions that can put the data in an inconsistent state.

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.

Re: Solid Relevance

#40

Post by to11mtm »

AnimalMuppet wrote: post #38
to11mtm wrote: post #33

Earlier quoted context omitted.

> Corrections welcome... You're cool. Most think ML[0] did it first, and dare I say did it right first. It gets rid of entire categories of boilerplate (interfaces come to mind) because types are fully inferred. In other words, if `funpost(request)` uses .User, .Body, .Time, from request, the only requirement is that the 'request' object has those properties with correct types further down the chain in usage. Other l…

OK. That's still in the 70s, though, not the 60s (going back to elric's question).

If you want to get pedantic I'd argue Generic programming is a subset of metaprogramming. To that end I'll go ahead and state that Lisp (1958) is probably the language I have done the MOST programming I would describe as 'generic'.
Post reply on HN