l_dopa · HackerTrans

3 ปีที่แล้วdiscuss

I always assumed this convention was just using "of" in the same sense as function composition. From wikipedia:

> The notation g ∘ f is read as "g of f "...

l_dopa

6 ปีที่แล้วdiscuss

> Classes as concept, are nothing more than extensible modules

If you're talking about ML-style modules, that really can't be farther from the truth, both in theory and how they're used in practice.

Modules can be used (among many other things) to implement abstract data types, which are conceptually a bit easier to compare to objects[0]. Then you'd have to go into structural vs nominal typing, functors vs generics, etc.

[0]https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...

l_dopa

7 ปีที่แล้วdiscuss

That's not entirely accurate. Abstract data types (e.g. ML modules) can also be modeled as existential types and don't have the same problems.

I think it's the particular combination of only having nominal typing, only allowing the oo-flavor of data abstraction, and encouraging programming with state and using inheritance for code reuse that leads to the object-spaghetti nonsense in heavily-oo Java/C++ codebases.

l_dopa

8 ปีที่แล้วdiscuss

One big difference is that java interfaces can't contain member types. They describe the methods of one particular type. Imagine you could define an interface for an entire java package.

Another big one is that module types are structural: you don't have to declare all the module types implemented by a module when you define the module.

l_dopa

8 ปีที่แล้วdiscuss

Type checking, type abstraction. If you're willing to throw those out, you can "get the same thing" with structs and void pointers.

l_dopa

8 ปีที่แล้วdiscuss

Actually, they're the "other side" of products types, which are sometimes called "records" or "structs". Maybe they're occasionally used to solve the same problem, but inheritance is unrelated. Inheritance is a variety of ad-hoc methods for sharing code with quite different semantics in every language where it's implemented.

l_dopa

9 ปีที่แล้วdiscuss

This is exactly what higher-order functions do, without the ad-hoc OO junk that's slightly different in every language.

l_dopa

10 ปีที่แล้วdiscuss

> I haven't claimed that equational reasoning is limited to pure languages

Sorry, I may have read that into your comment.

> the code itself needs to be pure

But that's also incorrect. Just because you can't replace an effectful computation with a value doesn't mean you can't reason equationally. You can also have benign effects that are unobservable, for example, memoization.

> Not sure how to parse that

I meant that functions with effects are just functions with computation type at the meta level. I.e. there's nothing more "mathematical" about only allowing nontermination in your language. It's just the simplest case.

l_dopa

10 ปีที่แล้วdiscuss

This is a really annoying meme in "pop" FP. Equational reasoning isn't limited to "pure" languages. Effectful functions, as you probably are aware, are just functions of type A -> T B.

l_dopa

10 ปีที่แล้วdiscuss

You're positing some new notion of complexity, without a definition, where lists are somehow fundamentally different than trees. Sorry, but that kind of claim requires more than just just an appeal to intuitions about how they might be implemented on a typical CPU. They're both just initial algebras.

The fact that your grand ideas about machine and language models doesn't apply to the lambda calculus should be a hint. We know how lambda calculus relates to typed languages: it's a degenerate case with a single type. Any differences in the complexity of type-inference or checking are between language models. You can't (without wildly waving your hands) formulate a meaningfully comparable problem for TM states.

l_dopa

10 ปีที่แล้วdiscuss

Why is the complexity of parsing well-formed states from strings somehow interesting? If you generalize to trees and pick the right alphabet, suddenly every element of your datatype is a well-formed lambda term.

It's also unclear if you're talking about the complexity of type inference or type checking, what annotations you're allowing, etc. Your claims about complexity re: states of typed languages are too hand-wavy to engage with.

And yet there's still a glaring error: for a very popular machine model, namely the C abstract machine, it's undecidable whether a state is meaningful (regardless of how you set up your parsing problem).

So, you have an interesting idea about the difference between machine models and languages but it clearly doesn't hold together. People have been studying the relationship between machine models and languages for quite some time, and it's relatively well understood. Machine models are one of the many ways to give semantics to languages. They just don't have many useful properties compared to more "abstract" approaches, and are mostly used to reason about implementation.

l_dopa

10 ปีที่แล้วdiscuss

  Languages are not so much a collection of features ...

If you want to define objects precisely, even just to have a language spec, they are absolutely made up of sums, products, recursive types, etc. Whatever useful metaphors one might have to work with objects doesn't change what they actually are. If you give the programmer access to these building blocks, you get ML.

  Calling them just domain specific ...

I meant that the particular way they're combined to get OOP is domain-specific.

Again, I'm just asking: why mess with the basics? Why require encoding simple, universal concepts in terms of an ad-hoc object system? You can still have an object system on top, if you find that helps with the really complicated cases, but why encode the parts of your code that are simple in terms of much more complicated, derived concepts?

l_dopa

10 ปีที่แล้วdiscuss

It sounds like we agree that lexically scoped immutable values are easier to understand, either precisely or with fuzzy metaphors. I'm not sure what "ideal" FP is or how it might have a certain "mathematical view of the world". The features I mentioned are just a subset of semantics that every high-level language programmer already knows, but are pointlessly hobbled in popular languages.

Why should expressing something basic like a tagged union require a detour through the quirks of a particular object system? Ditto for polymorphism, modularity, etc, etc. Clearly we disagree on how useful objects really are in practice, fine. Why not add these domain-specific features on top of a core language with simple semantics? It worked fine for lisps. Luckily, after a couple of decades of "everything is an object!" nonsense, that seems to be where newer languages (Rust, Swift) are headed.

l_dopa

10 ปีที่แล้วdiscuss

You're still, at some point, simulating the steps of some abstract machine in your head to understand what the debugger is telling you.

The simplest case is replacing an expression with its value, given an environment of lexical bindings that are apprent from the source program. Not much investigation necessary. That's FP.

For OO code, you just need to keep track of a lot more context: the state of the receiver of the currently executing method, its heirarchy of parent classes, the runtime class of each object because late binding is pervasive. Of course you can write code that doesn't use any OO features, but the languages clearly aren't designed for it. See: any number of "functional C++" articles.

And, of course, you can get the same kind of highly dynamic behavior in FP languages by explicitly using open recursion, higher-order state and hiding everything behind existentials. But very few codebases do that because the vast, vast majority of the time just one of these features is enough to solve a problem.

l_dopa

10 ปีที่แล้วdiscuss

"Pure" functional programming isn't the only alternative. There's plenty of benefit from just using a language with reasonable semantics (e.g. ML) that doesn't force you to contort simple programs into bizarre "OO" patterns.

Whether or not you want your language to enforce segregating (most) effects is a separate issue, about which reasonable people can disagree.

l_dopa

10 ปีที่แล้วdiscuss

The problem's not on your end -- a lot of these blogs are just junk, probably the vast majority of ones that fall under "advocacy". As far as I can tell, the author's objection to conditionals is based on a misunderstanding of a different blog post[0]. It's nonsense.

Really understanding where FP is coming from requires an introduction to programming language semantics[1]. Interesting stuff, but not immediately useful to a working C programmer.

[0] https://existentialtype.wordpress.com/2011/03/15/boolean-bli...

[1] http://www.cs.cmu.edu/~rwh/pfpl.html

l_dopa

10 ปีที่แล้วdiscuss

> The only plausible way to fix a bug in an ANN is to incorporate said bug in the training set

My point was not something about manipulating weights directly vs. augmenting the training set. The analogy is roughly, find a misclassification : add particular input to training set :: find a bug : add a patch/test case. I'm playing devil's advocate, of course, and there are obvious, important differences.

> The difference is that all human written systems was once understood by a human

But that's not one of them! In practice, we create software systems by getting some rough intuition about an interface, wiring together some components, then checking the results empirically. Basic components that everything else is built on, C compilers for instance, are based on ambiguous, even contradictory specifications.

l_dopa

10 ปีที่แล้วdiscuss

Is knowing, for example, that there's a race triggered by a new optimization in compiler version X that happens under conditions Y and Z really a qualitatively different type of understanding than "the weights are such that the ANN computed this incorrect output for these inputs?"

In both cases we can only fix a particular instance of an error and effectively have no way to show that similar errors don't exist, or even that we didn't introduce new bugs with the fix.

l_dopa

10 ปีที่แล้วdiscuss

Assuming you're in some client code that shouldn't rely on the implementation of m, it's an https://en.wikipedia.org/wiki/Abstract_data_type

l_dopa

10 ปีที่แล้วdiscuss

You're describing subtyping which, like modularity, does not require inheritance or really any other part of "OOP".

I think that supports the article's point that C++, Java, etc. only support certain language features in an ad-hoc way tied to their object systems, making them, among other things, poor teaching languages.

comments