OOP is TRWTF

topspin

Data.Functor.Const also uses it to do a const for types in a type-safe way

Interesting. Could you explain why you would possibly need const when everything is immutable, anyway?

Oh, and did I mention you can do simple forward automatic differentation with types in Haskell too? It's like templates in C++ but much safer due to compile time checking.

My C++ templates are compile time checked (what else would they be?), and coincidentally so is my AD library.

_P_

@topspin said in OOP is TRWTF:

Interesting. Could you explain why you would possibly need const when everything is immutable, anyway?

Immutability has nothing to do with const. It's just one of the most funadmental blocks that you can build out of functions generalized for all types: e.g id :: a -> a, const id :: a -> b -> b and const :: a -> b -> a. They're things that you get essentially for free.

As for Data.Functor.Const it's used in profunctor optics (aka the infamous lenses), and lenses/optics is FP's ways of composing accessors for nested records to achieve OO-like CRUD operations. Or as that joke goes, "when you use optics you're using object getter/setter technology in Java". In profunctor optics, turns out getter and setter is differed by whether Data.Functor.Identity or Data.Functor.Const is involved.

Okay, lenses are really complicated constructs (so much that people have been saying lens is basically a DSL of its own. It also attracts some "monad tutorial"-like tutorials too), but there are easier ways to utilize types in FP to your advantage. Functor combinators is a good example.

My C++ templates are compile time checked (what else would they be?), and coincidentally so is my AD library.

But implementing AD with dependent types is easy and simple. You just create a new datatype data FD a = FD a a (so there's an extra number as the information), then implement Num typeclass of Num a => FD a that will keep track of the additional information when you do the calculations, and now you can automatically do calculations along with the derivative just by passing FD instead of a normal Num instance. A simple implementation only takes like 10 very short lines, and even a full-blown library is not very big: Numeric.AD

I doubt you can achieve the same simplicity and brevity with C++ templates.

dkf

@_P_ said in OOP is TRWTF:

But implementing AD with dependent types is easy and simple.

I'm assuming you didn't mean Active Directory there. Nothing to do with that is easy or simple unless you're very lucky…

topspin

@_P_ said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

Interesting. Could you explain why you would possibly need const when everything is immutable, anyway?

Immutability has nothing to do with const.

Well, from the name I assumed it had something to do with declaring constants, like in other languages.

int i = 0;
const int j = 1;

Didn't realize you were talking about cricket again.

Gąska

@LaoC said in OOP is TRWTF:

@Gąska said in OOP is TRWTF:

Haskell program starts with just one instance of RealWorld and new instances cannot be created without disposing of the old one, and new one always gets created whenever any outside interaction happens

An immutable singleton by any other name would smell as sweet.

Immutable singleton wouldn't be able to change.

dkf

@_P_ said in OOP is TRWTF:

Immutability has nothing to do with const.

Immutability has to do with hurricanes.

dfdub

@_P_ said in OOP is TRWTF:

Otherwise things like this happen after optimization.

So, what you're saying is that deep inside the internals of the standard library, what @topspin feared above actually happens?

@topspin said in OOP is TRWTF:

How is it guaranteed that these are in the correct order and executed exactly once?

I mean, it doesn't really matter to the user of the monad (unless they run into a related bug), but now you've made me feel uneasy about the magic inside the IO monad.

topspin

@dfdub A bug is still just a bug, but more importantly, even the compiler hackers don't understand how it works.

boomzilla

@dfdub said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

It's more that the compiler / runtime is free to evaluate that stuff lazily and in whatever order it likes (though obviously it needs to evaluate the parameters for a function before the function itself can execute).

Nope, Haskell doesn't evaluate function parameters before calling the function.

Eh, yeah...should have said before they get used, I suppose. Which is never, because this thread has convinced me that avoiding Haskell forever is definitely the right life choice.

_P_

@boomzilla You can run, but you cannot hide.

boomzilla

@_P_ said in OOP is TRWTF:

@boomzilla You can run, but you cannot hide.

YMBNH

LaoC

@_P_ said in OOP is TRWTF:

@boomzilla You can run, but you cannot hide.

I thought he couldn't run, just evaluate it?!

Captain

@topspin said in OOP is TRWTF:

Interesting. Could you explain why you would possibly need const when everything is immutable, anyway?

const a is the constant function, which returns a for any input b. Pretty sure it's defined as const a b = a.

error

@Gąska said in OOP is TRWTF:

It's probably as wrong as all earlier attempts, but I hope I'm inching ever so closer to the truth.

See: my signature

topspin

@Captain said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

Interesting. Could you explain why you would possibly need const when everything is immutable, anyway?

const a is the constant function, which returns a for any input b. Pretty sure it's defined as const a b = a.

That’s a lot easier to understand.

error

@Captain said in OOP is TRWTF:

A Haskell program is more like a data structure that another program (the runtime) traverses.

This sounds like XSLT, which is literally a transformation program represented non-procedurally as an XML document.

IMHO it's a better language than it gets credit for (XML is )

Captain

@error I don't know about XSLT's evaluation model, and in a sense, every program is a data structure that gets traversed. But Haskell's runtime uses that structural data in a different way than most languages, in such a way that it makes sense to point to "the program is a data structure" as a distinction.

error

@Captain said in OOP is TRWTF:

@error I don't know about XSLT's evaluation model, and in a sense, every program is a data structure that gets traversed. But Haskell's runtime uses that structural data in a different way than most languages, in such a way that it makes sense to point to "the program is a data structure" as a distinction.

So basically, XSLT takes 2 input XML documents and produces a third document (XML, HTML, or text). The source document gets traversed as a DOM tree. The transform document defines a set of templates with an XPath expression defining a pattern to match (like CSS but more expressive). Each time a node is encountered in the source document, it finds the most specific pattern a template matches, and evaluates that.

Then that template gets traversed, and nodes within either perform flow control, output a new node to the output document, or tell it to continue traversing the source document.

Since it involves 2 parallel DOM traversals and a DOM emission, some coders have trouble following it. You really have to think about it differently than a traditional program.

svieira

@boomzilla said in OOP is TRWTF:

@Captain every so often I try to figure out what this monad shit is about and then I'm hit with a bunch of Haskell notation and I give up. I guess I'm too to wrap my mind around the syntactical paradigms or something. And it's usually after some functional hipster is telling me about all these problems I have that I never really noticed as such before.

I CBA to read the whole thread, so I don't know if you achieved enlightenment, but two points:

To understand what Haskell is doing with monads think of them as continuations instead (async / await on dinosaur steroids). This talk from 7:40 through about 10:00 really sums up why you'd care to use them.
The syntactic sugar doesn't matter - to really understand monads you have to understand Category Theory (from what I can tell, I don't understand them). But you don't have to understand them to use them, just have an analogy.

boomzilla

@svieira said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:
@Captain every so often I try to figure out what this monad shit is about and then I'm hit with a bunch of Haskell notation and I give up. I guess I'm too  to wrap my mind around the syntactical paradigms or something. And it's usually after some functional hipster is telling me about all these problems I have that I never really noticed as such before.
I CBA to read the whole thread, so I don't know if you achieved enlightenment, but two points:

To understand what Haskell is doing with monads think of them as continuations instead (async / await on dinosaur steroids). This talk from 7:40 through about 10:00 really sums up why you'd care to use them.

Yes, thanks, that's what I got from a C# link that was posted.

The syntactic sugar doesn't matter - to really understand monads you have to understand Category Theory (from what I can tell, I don't understand them). But you don't have to understand them to use them, just have an analogy.

I think I would have an easier time learning category theory than I would figuring out Haskell syntax, actually.

Gąska

@svieira said in OOP is TRWTF:

To understand what Haskell is doing with monads think of them as continuations instead (async / await on dinosaur steroids).

I'd go a step further - every argument of every function is like a continuation, and Haskell avoids calling continuations whenever possible.

dfdub

@error Sounds more like Prolog than Haskell to me.

Gąska

@dfdub Prolog is automated reasoning in first order logic. @error's description sounds like it's standard procedural programming, except not as a single program, but a kind of a function library where functions are looked up by XPaths and applied on parts of the source document.

error

I guess all procedural languages traverse a tree (usually an AST). What's different in XSLT is that there are at least two trees (you can import more documents), and instead of an instruction pointer you have a context node or nodes in the tree, which are selected by matching patterns.

You can imagine something like a call stack but it would bounce back and forth between the source and transform (and additionally imported) documents.

Maybe not a great similarly but still an interesting mechanism.

dkf

@svieira said in OOP is TRWTF:

To understand what Haskell is doing with monads think of them as continuations instead

I understood monads (mostly) but now you're saying that they're continuations (which have a real tendency to confuse me)? Thanks a lot…

Watson

@error

Really old (hey, it's talking about XML technologies), so I guess they got bored and moved on.

The Functional Programming Language XSLT - A proof through examples

HardwareGeek

@boomzilla said in OOP is TRWTF:

this thread has convinced me that avoiding Haskell forever is definitely the right life choice.

I think the time has come for me to ignore this thread, because ^^^^ is the only thing I've understood in the whole thing.

topspin

@HardwareGeek said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

this thread has convinced me that avoiding Haskell forever is definitely the right life choice.

I think the time has come for me to ignore this thread, because ^^^^ is the only thing I've understood in the whole thing.

You wouldn’t believe how often I felt that way when you start talking about Greek, etymology, music theory, and all the other useless trivia only you seem to know.

HardwareGeek

@topspin It's not at all useless. How do think I became Viscount Pedantic Dickweed of the Noble Order of the Garter?

topspin

@HardwareGeek It was meant more as praise than as an insult.

Also, voiceless dental fricatives and mid-central unrounded vowels? That might have been @djls45, though, not quite sure.

sockpuppet7

With modern c++ and rust, wasting cpu cycles and memory with these garbage collected, bytecode interpreted languages is TRWTF

pie_flavor

@sockpuppet7 Good thing they're few and far between. It's mostly JIT now.

sockpuppet7

@pie_flavor and mostly slow and garbage collected, at least 2x slower than a proper language

pie_flavor

@sockpuppet7 The slowdown isn't GC-related, though. Half the time it's faster than reference counting. And JIT is better than precompiled if it can map stuff efficiently; precompiled can only optimize for the lowest common denominator whereas JIT can optimize differently for every system. It's all about the indirection. C# when you only use structs and static dispatch isn't quite as fast as C but it's a lot faster than cromulently object oriented C#, and you can squeeze similar speeds out of Swift so you know there's no advantage to not using GC in such a scenario.

dkf

@pie_flavor said in OOP is TRWTF:

The slowdown isn't GC-related, though. Half the time it's faster than reference counting.

In my tests, I've found that GC is usually faster than reference counting, but reference counting gives smaller variance in performance. You can make RC do even better if you use a better-than-standard allocator (assuming your application's thread model supports it) but that's getting quite seriously deep into the hackery, and well past the point where C++ ceases to be nice and friendly. (Allocating everything on the stack is nice in performance terms, but really doesn't fit all applications well.)

Also, reference counting is better when you're strongly memory constrained.

dfdub

@dkf said in OOP is TRWTF:

C++

In C++, ideally you don't even use reference counting, but work with explicit owners (unique_ptr). Avoiding both reference counting and GC should always be the fastest option.

sockpuppet7

@pie_flavor I've seen all this talk, but the only things that got C performance on the benchmarks game aren't GCd nor jitted. And things made in java and C# just feel slow

dkf

@sockpuppet7 said in OOP is TRWTF:

the benchmarks game

The problem with that is you're measuring someone else's benchmarks and someone else's solutions to them. Their applicability to your own problems is uncertain at best.

sockpuppet7

@dkf it matches everything I saw in the wild though

Gąska

@pie_flavor said in OOP is TRWTF:

And JIT is better than precompiled if it can map stuff efficiently; precompiled can only optimize for the lowest common denominator whereas JIT can optimize differently for every system.

If only there was a language that takes advantage of that...

C# when you only use structs and static dispatch isn't quite as fast as C but it's a lot faster than cromulently object oriented C#

Fun fact: the default equality comparison of a struct type is one of the slowest parts of entire C#.

cabrito

@sockpuppet7 said in OOP is TRWTF:

With modern c++ and rust, wasting cpu cycles and memory with these garbage collected, bytecode interpreted languages is TRWTF

DogsB

@dkf said in OOP is TRWTF:

@_P_ said in OOP is TRWTF:

But implementing AD with dependent types is easy and simple.

I'm assuming you didn't mean Active Directory there. Nothing to do with that is easy or simple unless you're very lucky…

Or have a human sacrifice on hand...

pie_flavor

@Gąska said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

And JIT is better than precompiled if it can map stuff efficiently; precompiled can only optimize for the lowest common denominator whereas JIT can optimize differently for every system.

If only there was a language that takes advantage of that...

C# when you only use structs and static dispatch isn't quite as fast as C but it's a lot faster than cromulently object oriented C#

Fun fact: the default equality comparison of a struct type is one of the slowest parts of entire C#.

Is it a different operation than bytewise comparison?

Gąska

@pie_flavor yeah. It does some reflection shenanigans instead for God knows what reason. VEEEERY SLOOOOW.

Dragoon

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

Gąska

@Dragoon I expected worse. Haven't actually read it - just skimmed through - but the languages they've picked does seem reasonable. Ruby and Perl seem to go the way of PHP as far as I can tell, and Obj-C is the closest it could possibly get to official deprecation. Dunno about R, never was interested in data analysis. Haskell - I think it's a safe bet it'll stay exactly the same way it's been for the last 20 years: it has a small cult of devout worshippers, but to most programmers it's a mythical creature they hope to never see for real.

Carnage

@Dragoon said in OOP is TRWTF:

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

This comment...

We need to do more with object-oriented classes. Programming needs to become simpler – not harder. It needs to make objects do the nitty-gritty work. It needs to de-geek itself and become user-friendly in the extreme. It needs to do away with the acronyms. It should be more like BASIC, with objects that extend its usefulness to the max. Saving, opening, reading and resaving any file should be built in. Access to changing pixels and saving them in any lossless format (and every format should be lossless) should be easy. Pixel colors should be assigned numbers with a base of 256 in which to both read them and write them with. Going to a specific address, to use the data there, should instead take the form of nesting data in arrays.

boomzilla

@Carnage said in OOP is TRWTF:

@Dragoon said in OOP is TRWTF:

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

This comment...

We need to do more with object-oriented classes. Programming needs to become simpler – not harder. It needs to make objects do the nitty-gritty work. It needs to de-geek itself and become user-friendly in the extreme. It needs to do away with the acronyms. It should be more like BASIC, with objects that extend its usefulness to the max. Saving, opening, reading and resaving any file should be built in. Access to changing pixels and saving them in any lossless format (and every format should be lossless) should be easy. Pixel colors should be assigned numbers with a base of 256 in which to both read them and write them with. Going to a specific address, to use the data there, should instead take the form of nesting data in arrays.

It's like a 12-year-old-blakey blakeyrant.

Carnage

@boomzilla said in OOP is TRWTF:

@Carnage said in OOP is TRWTF:

@Dragoon said in OOP is TRWTF:

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

This comment...

We need to do more with object-oriented classes. Programming needs to become simpler – not harder. It needs to make objects do the nitty-gritty work. It needs to de-geek itself and become user-friendly in the extreme. It needs to do away with the acronyms. It should be more like BASIC, with objects that extend its usefulness to the max. Saving, opening, reading and resaving any file should be built in. Access to changing pixels and saving them in any lossless format (and every format should be lossless) should be easy. Pixel colors should be assigned numbers with a base of 256 in which to both read them and write them with. Going to a specific address, to use the data there, should instead take the form of nesting data in arrays.

It's like a 12-year-old-blakey blakeyrant.

I particularly liked this part of it.

There is also another thing. Programming apps should come only on disk, and be delivered by snail-mail to the user. These disks should be coded, by law, with dedicated computers that are isolated from any outside tampering. Programmers should also work on such computers. The data in their apps should only be copyed to beta-test internet apps. These computers should be for programming only and, aside from accessing files on their own hard drives, they should be hard-wired to be read-only.

Like... What?

topspin

@Gąska said in OOP is TRWTF:

@pie_flavor yeah. It does some reflection shenanigans instead for God knows what reason. VEEEERY SLOOOOW.