Academics should stick to pure computer science

Every time the academics try to wet their flaccid noodle in the soft, warm crevices of actual programming, they prematurely squirt all over it, and don't get any of their gooey information inside. I'm coming at this from the context of compilers, but I'm sure it applies to most areas. I don't think that anyone could disagree that tomes such as TAoCP are anything less than holy scripture and should be read by anyone who thinks to call them-self a programmer, but beyond that, it's done nothing but waste time. For instance, pure functional programming. Like most academic things, it promises beauty and simplicity and millions of optimizations that can be done. Where are these optimizations? In the math of course. Problem is, most of them never bother to implement them, and on the rare occasion that they do, it's some toy that only shows that particular optimization on a particular instance on a particular program.

The damage comes in when legions of pseudo-intellectuals argue for the style used on the basis that it can merely be shown to allow these optimizations. The rate at which such things actually occur are probably less than one or two percent. Besides looking particularly ``mathy'' in syntax, the result is usually purposeless and never delivers one any of the promises that were theoretically possible.

HUSKUL sux and functional purity must be broken to do anything useful. What else is new?

Not every academic thinks pure functional programming is ``the future'' or a good idea.

You're putting the people who invented most of your compiler technology (from parsing to optimization to JITs), concurrency techniques, and GC algorithms in the same group as those who would say none of that has anything to do with computer science.

>>1

Every time the academics try to wet their flaccid noodle in the soft, warm crevices of actual programming, they prematurely squirt all over it, and don't get any of their gooey information inside.

Lovely prose.

>>3

You're putting the people who invented most of your compiler technology (from parsing to optimization to JITs), concurrency techniques, and GC algorithms

All of those sans concurrency were invented by necesscity by FP circlejerkers.

>>5

invented by necesscity by FP circlejerkers.

FP circlejerkers were writing their toy interpreters in Lisp while real academics were creating the things their compilers rely on.

>>6
Lisp compilers rely on Lisp.

?DIVIDE BY ZERO ERROR
READY.

It was the same thing when Object-Oriented Programming™ reared its ugly head.

You can do OO style in pretty much any language, and it can help to organize some portions of your code and allow you to tackle larger or more complex problems than before. But lock your entire language into a bad interpretation of OO, and you get shit like Java.

Likewise, you can do FP in any programming language, and it can clean the hell out of some of your data flows and data access issues, and even make it run faster because sometimes just copying the damned data is faster than trying to juggle mutations safely. But if you get your head too far up FP's ass to the point where that's all you see, you get fucked up mentally.

>>1
An academic's lifeblood is publishing papers. They have quotas to meet. Tons of the "academic" garbage you see is the shovelware of the academic industry. They know it's bullshit, but need to publish something to make their numbers look good.

Likewise, you can do FP in any programming language

Higher order function is a huge benefit of FP, and indeed you can have higher order functions or their simulations in most languages, but glhf simulating applicative semantics and maintaining referential transparency in C.
> equational reasoning in C XDDD

>>8
You can't really use OO's situation as an analogy to FP's, assuming that you take ``higher order function'' as the defining feature of FP like with OO's subclassing. Most FP languages aren't pure so what other choice do you have?
Unlike ``subclassing'' you can't go wrong with higher order function-it's actually fundamental to PL theory, and it won't create more problems than it solves. The only noteworthy problem of HO was the already solved FUNARG problem, and that was just a matter of implementation, not something inherent to HO.

OBJECT-ORIENTED PROGRAMMING with all its good and evil aspects, still has serious fundamental problems. One of the most disturbing would be this http://okmij.org/ftp/Computation/Subtyping/Trouble.html
In short, ``subclassing'' with ``overriding'' isn't really subtyping, because ``overriding'' violates subtyping's universal polymorphism. It's ad-hoc polymorphism in disguise, while convincing the type checker that a subclass instance still inhabits the superclass. No, it doesn't, and that means whatever you assert for a superclass will possibly no longer hold for a subclass AND CHECKING THIS IS AN UNDECIDABLE PROBLEM.
That is the subtle reason why all modern ENTERPRISE QUALITY INDUSTRIAL BIG DATA AS A PLATFORM CLOUD-ENABLED MACHINE LEARNED INTELLIWARES are so ridden with lurking unreproduceable BUGS

Alan Kay's idea of message passing on the other hand is fine, unfortunately most OO languages don't actually have message passing and instead shove A.m() down your goyim throat and call that ``message passing''. Too bad some of the few language got message passing right are Erlangs and its spawns, which identify themselves as FP languages.

>>11
Uh.

Therefore, from the OO point of view, neither a Bag nor a Set are a subtype of the other. This is the crux of the problem. Bag and Set only appear similar. The interface or an implementation of a Bag and a Set appear to invite subclassingof a Set from a Bag (or vice versa). Doing so however will violate the LSP -- and you have to brace for very subtle errors.

Well, yeah. Implementing a subtype that is not really a subtype is a bug. I'm not sure what Oleg's point is: surely, he doesn't expect the type system to catch logic bugs?

I also don't see what your point is: I can recreate the exact same problem with Erlang-style classes or with higher-order functions or whatnot: as long as it allows me to pass a Set to a function expecting a Bag I have this problem.

>>12

Well, yeah. Implementing a subtype that is not really a subtype is a bug.

It is a logic bug, but the reason you can implement a ``subtype that is not really a subtype'' is only because the type system allow it. Let me restate it: because the language allows overriding.
His point is: you can have system with subtype that must actually be subtype iff there is no overriding. Which is not very practical of course, so he proposed a way to actively prevent such pitfall.

How is A.m() not message passing? Any kind of procedure is message passing. Procedures that return a value are a Send-Receive-Reply.

he doesn't expect the type system to catch logic bugs?

Yeah? That is exactly the kind of shit you expect your type system catches.

as long as it allows me to pass a Set to a function expecting a Bag

That means the type system either is unityped or has subtyping
Now read some Luca Cardelli's introductory papers to type or something, since you clearly don't understand what everyone else is talking about

I also don't see what your point is: I can recreate the exact same problem with Erlang-style classes

My point was according to Alan Kay OO should be more about Erlang-style message passing than about subtyping. I also didn't even mean the problem above doesn't exist in Erlang in case you misunderstood something, it's already a unityped language so talking about ``type'' pitfall is as silly as talking about you're waifu's STDs.

>>14
It is not. If method invoking is ``message passing'' where . is the passing operator and m is the message, then clearly there's no object replying to the caller by ``passing message back''. In system with actual message passing, messages are actual first class value, and an object/actor/process dispatches reaction to messages by matching on their structure.

>>16
First class functions = first class messages.

>>17
First class messages can be anything depends on the implementation.

But that's beside the point. The point is function call =/= message passing, because it is asymmetric: a caller can invoke a method on an object, but where is an object invoke a call back in response to the caller?

>>18
s/invoke a call/invoke a method

>>13

His point is: you can have system with subtype that must actually be subtype iff there is no overriding. Which is not very practical of course, so he proposed a way to actively prevent such pitfall.

What is subtyping without overriding? Doesn't that mean just no subtyping for all practical purposes (poor man's composition + delegation doesn't count)? Also, where did Oleg propose a way for preventing that problem?

>>15
I'm sorry but anyone who uses the word "unityped" nonironically is brain damaged.

>>20

What is subtyping without overriding?

Only extending the superclass. With overriding it's called subclassing. And yes it is not practical.

Also, where did Oleg propose a way for preventing that problem?

Subclassing errors, OOP style and practically checkable to prevent them

"unityped" nonironically

Faggotquote pls go back to /g/
Also for your information ``unityped'' is a valid, actual term used in type theory. Type theory as originally in mathematics only defined for terms, so when brought that to programming language they also just defined it for terms, and any language without ``static type'' is called unityped or more commonly ``untyped'', since there's only one kind of term. The type-tag checking for value during execution viz. dynamic-checking, or as you'd usually call it, dynamic typing, is a whole different discipline.

>>20
It seems you are so wired to the notion of common OOP language's subclassing that you totally misunderstand what subtyping actually is.
It is not about objects of class A' extending class A behave differently from objects of class A, but about a parameter expecting a value of type A can also use a value of type A' without breaking any invariant.

With subclassing i.e. extending AND overriding, you'll have a more relaxed constraint: no ``without breaking any invariant''.
Also read Oleg's article more carefully. Actually you should read his reference on Cardelli's paper first to prevent further misunderstanding.
On that note try searching for ``On binary methods'' too. It's about another problem, not with just OOP, but with subtyping.

>>21

Subclassing errors, OOP style and practically checkable to prevent them

Oh, I missed that. I don't find it impressive at all: all operations always produce objects of the base type and you have to manually cast it back to the derived type every time (constructing a new object, and that's the only place where customization can happen). It doesn't look as stupid as it actually is only because it's pre-C++11, now try to write some code manipulating sets accidentally using auto and see what happens. I mean, the only good thing about this approach I can see is that it makes any inheritance retarded, which also covers inheriting Set from Bag.

As for his second example with an abstract base class, I totally don't see anything that would prevent me from making an abstract IBag, then implementing it with concrete CBag and CSet and hitting the original problem again.

I think that you guys don't see the forest for the trees here. It boils to this: you decide that you want to pass a Set object to a function that takes Bags, either you can do that or you can't. If you can (and I don't care how, use higher-order functions for all you want) then you have a bug because you shouldn't have done that. If you can't then nobody will use your toy language because you have to cut out everything useful to forbid yourself from doing that.

Also for your information ``unityped'' is a valid, actual term used in type theory.

I know, that's what I meant by brain damage.

>>23

I think that you guys don't see the forest for the trees here

Well since you totally missed the point of this whole abstract masturbation, GLHF with that. It's not like I can or even want to convince you to break your whole understanding of programming for some irrelevant argument by Oleg or something, and it's ok, really, since in the end you'll probably never have to concern yourself with such problems.
But as an aside, relocate your ass back to /g/, ``please''.

>>22

It is not about objects of class A' extending class A behave differently from objects of class A, but about a parameter expecting a value of type A can also use a value of type A' without breaking any invariant.

Not quite, the interesting question is whether you can make your function polymorphic so that it also returns A' (and yeah, forget about dynamic polymorphism for a moment, you'll get all the same problems if you make it a template and always work with concrete types, so that's just a red herring).

By the way, to focus this discussion on something actually practical: what's your opinions on integers being a subtype of reals? Or, like, what do you think you can use subtyping for, even?

>>25

the interesting question is whether you can make your function polymorphic so that it also returns A'

But based on what clues would the polymorphic function decide to return a value of which particular subtype? And the set of subtype is inherently open too. I don't know if you can achieve that with dependent type, but throwing dependent type into the fray sounds horrible!
On that note function type is already covariant on return type, i.e. f'::B->A' <: f'::B->A, so I guess your polymorphic function taking a function of type B->A to construct the return value of type A, since it can take a function of type B->A' instead too.

>>26
s/taking/can take

>>24

It's not like I can or even want to convince you to break your whole understanding of programming for some irrelevant argument by Oleg or something

It's not irrelevant, it's factually wrong from what I can tell, so your haughty sarcasm is a little bit out of place ;-)

>>26
Of course I meant an A -> A functions and the like, should add :: Bag T -> T -> Bag T also work with Set and return a Set?

>>28
Yes it can take a Set T, but no it still returns a Bag T, since without runtime checking there's no way for the caller to know which subtype of Bag T would the return value be. It can only know it's of type Bag T. You have means to return the value of any subtype of Bag T, like I suggest with passing constructor function, but that's exactly why it'll still be treated as Bag T only.

And also since you misunderstood the whole deal about type and subtyping, I guess I won't reply to any further question. Hope you found my previous post useful.
And I agree that you should go back to /g/ too. ``Please''.

>>29

Yes it can take a Set T, but no it still returns a Bag T, since without runtime checking there's no way for the caller to know which subtype of Bag T would the return value be.

I'm talking about compile time polymorphism, like, let Bag be a type class or something, I don't actually speak Haskell. Think where in C# or static_assert(std::is_base_of(...)) in C++.

Forget about runtime, it's a red herring adopted by certain brain damaged people to insulate themselves in their delusions.

>>31
Very e/g//g/ins /g/roski

Did /prog/ just get 31 posts into a thread from confusion over interfaces?

>>33
This is /dpt/ now in case you haven't caught the drift

>>18

but where is an object invoke a call back in response to the caller?

This is the return.
Send: Procedure call
Receive: Procedure execution
Reply: Return statement

Why are you talking about trash languages?

>>34
What's a ``/dpt/'' and why shouldn't you go back there?

>>32
I understand why you'd feel upset about Oleg being proven factually wrong, but maybe don't resort to shitposting like that?

>>3

compile time polymorphism

If it's at compile time, then it's either just type inference or the compiler is producing bloated shit binaries. Really polymorphism can only happen during runtime.

>>39
You meant type checking. Type inference is a different thing, friendo. Anyway, from the theoretical perspective it doesn't matter whether the compiler faithfully generates fully specialized code or dispatches again at runtime.