Software Mimicry • Hacker News Board

Re: Software Mimicry

#11

Post by Smaug123 » Sat, Nov 19, 2022, 5:51 PM UTC

LAC-Tech wrote: post #10

In Design Patterns in Dynamic Programming, Peter Norvig notes that strategies are just trivially replacable with higher-order functions (HOFs). So that's where this trope is from! A few things: 1. The "just replace it with a higher order function" thing obviously falls apart when your strategy has multiple methods. In which case, the FP programmer might be tempted to supply a record where each field is a function, an…

Isn't your point 2 exactly what OP said?

> I think it’s more interesting to think of the GoF-language as mimicking HOFs with the strategy pattern facsimile. The strategy pattern reimplements HOFs as a code-level idiom.

Re: Software Mimicry

#12

Post by Smaug123 » Sat, Nov 19, 2022, 5:53 PM UTC

arh68 wrote: post #9

So are the birds mimicking the bees, or is it the other way around? Maybe I'm just missing the point. I mean, is int[] a mimic of ArrayList , or vice versa? Of course they're similar, of course they're different. Is "mimicry" just a pejorative thing?

A definition is given as literally the first paragraph of the post.

> Mimicry is when software X reimplements at a higher level a core feature of software Y. The produced facsimile has some, but not all, of the same properties, enough to “look like” it’s the same thing but missing many of the nuances. This exists in every kind of software. One language can mimic another, a library can mimic a language, a database engine can mimic a product, etc.

I don't see how your question even fits into that definition.

Re: Software Mimicry

#13

Post by LAC-Tech » Sat, Nov 19, 2022, 6:13 PM UTC

Smaug123 wrote: post #11

LAC-Tech wrote: post #10

In Design Patterns in Dynamic Programming, Peter Norvig notes that strategies are just trivially replacable with higher-order functions (HOFs). So that's where this trope is from! A few things: 1. The "just replace it with a higher order function" thing obviously falls apart when your strategy has multiple methods. In which case, the FP programmer might be tempted to supply a record where each field is a function, an…

Isn't your point 2 exactly what OP said? > I think it’s more interesting to think of the GoF-language as mimicking HOFs with the strategy pattern facsimile. The strategy pattern reimplements HOFs as a code-level idiom.

No more than HOFs are mimicking objects.

It's two schools of thought - everything is functions & data, or everything is objects & methods.

Re: Software Mimicry

#14

Post by zasdffaa » Sat, Nov 19, 2022, 6:38 PM UTC

LAC-Tech wrote: post #13

Smaug123 wrote: post #11

Earlier quoted context omitted.

Isn't your point 2 exactly what OP said? > I think it’s more interesting to think of the GoF-language as mimicking HOFs with the strategy pattern facsimile. The strategy pattern reimplements HOFs as a code-level idiom.

No more than HOFs are mimicking objects. It's two schools of thought - everything is functions & data, or everything is objects & methods.

Closures are implemented as objects under the skin, but that doesn't make them equivalent conceptually to me. I suppose it's down to syntax, after all if you ignore that you can have anything you like in assembler, but it won't feel very high level.

Re: Software Mimicry

#15

Post by layer8 » Sat, Nov 19, 2022, 7:18 PM UTC

zasdffaa wrote: post #14

LAC-Tech wrote: post #13

Earlier quoted context omitted.

No more than HOFs are mimicking objects. It's two schools of thought - everything is functions & data, or everything is objects & methods.

Closures are implemented as objects under the skin, but that doesn't make them equivalent conceptually to me. I suppose it's down to syntax, after all if you ignore that you can have anything you like in assembler, but it won't feel very high level.

Closures are a poor man’s objects. Objects are a poor man’s closures.

Re: Software Mimicry

#16

Post by zasdffaa » Sat, Nov 19, 2022, 7:45 PM UTC

layer8 wrote: post #15

zasdffaa wrote: post #14

Earlier quoted context omitted.

Closures are implemented as objects under the skin, but that doesn't make them equivalent conceptually to me. I suppose it's down to syntax, after all if you ignore that you can have anything you like in assembler, but it won't feel very high level.

Closures are a poor man’s objects. Objects are a poor man’s closures.

What's the "poor man's" stuff? Is there a better way I don't know of

Re: Software Mimicry

#17

Post by Jtsummers » Sat, Nov 19, 2022, 8:15 PM UTC

zasdffaa wrote: post #16

layer8 wrote: post #15

Earlier quoted context omitted.

Closures are a poor man’s objects. Objects are a poor man’s closures.

What's the "poor man's" stuff? Is there a better way I don't know of

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

Comes from that koan.