Haskell is king

Haskell has an explicit goal (according to Simon Peyton Jones) of minimizing the pain of strict static typing - of having the fewest possible cases where what you want to express is reasonable but doesn't fit the type system. The useful cases that OOP supports but Haskell 98 didn't are already supported (in a different way) in Haskell via extensions. In fact the modern Haskell typesystem is far superior to anything I know of in the OOP world.

So basically, you just don't need OOP in Haskell. You could do things using Haskell 98 typeclasses that you couldn't do with OOP anyway, and with (stable, widely used) extensions such as higher-rank and existential types you can now do pretty much anything you could with OOP. With multi-parameter typeclasses and type functions, you can go beyond OOP to handle what Java generics can do (probably more, though I'm not that familiar with Java) and a fair chunk of what C++ template classes can. And that's without looking at Template Haskell.

There are some cases where OOP still seems a bit more convenient, but mostly that's a short-term gain that's outweighed by longer-term losses. For example OOP can be a lot more convenient at times because of the pervasive mutability, but Haskell keeps mutability under control for a reason.

Brainfuck has an explicit goal (according to Simon Peyote Joints) of minimizing the pain of strict tape seeking - of having the fewest possible cases where what you want to express is reasonable but doesn't fit the tape system. The useful cases that RAM machines support but Brainfuck 98 didn't are already supported (in a different way) in Brainfuck via extensions. In fact the modern Brainfuck tapesystem is far superior to anything I know of in the RAM machine world.

So basically, you just don't need dynamic seeking in Haskell. You could do things using Brainfuck 98 tapeclasses that you couldn't do with RAM machines anyway, and with (stable, widely used) extensions such as higher-rank and existential tapes you can now do pretty much anything you could with RAM machines. With multi-parameter tapeclasses and tape functions, you can go beyond RAM machines to handle what Haskell typeclasses can do (probably more, though I'm not that familiar with Haskell) and a fair chunk of what C++ template classes can. And that's without looking at Template Brainfuck.

There are some cases where the RAM machine model still seems a bit more convenient, but mostly that's a short-term gain that's outweighed by longer-term losses. For example registers can be a lot more convenient at times because of the immediate accessibility, but Brainfuck keeps accesibility under control for a reason.

Brainfuck has an explicit goal (according to Simon Peyote Joints) of minimizing the pain of strict tape seeking - of having the fewest possible cases where what you want to express is reasonable but doesn't fit the tape system. The useful cases that RAM machines support but Brainfuck 98 didn't are already supported (in a different way) in Brainfuck via extensions. In fact the modern Brainfuck tapesystem is far superior to anything I know of in the RAM machine world.

So basically, you just don't need random access in Brainfuck. You could do things using Brainfuck 98 tapeclasses that you couldn't do with RAM machines anyway, and with (stable, widely used) extensions such as higher-rank and existential tapes you can now do pretty much anything you could with RAM machines. With multi-parameter tapeclasses and tape functions, you can go beyond RAM machines to handle what Haskell typeclasses can do (probably more, though I'm not that familiar with Haskell) and a fair chunk of what C++ template classes can. And that's without looking at Template Brainfuck.

There are some cases where the RAM machine model still seems a bit more convenient, but mostly that's a short-term gain that's outweighed by longer-term losses. For example registers can be a lot more convenient at times because of the immediate accessibility, but Brainfuck keeps accesibility under control for a reason.

ONE WORD THE FORCED COLLECTION OF THE GARBAGE THREAD OVER

>>4
That is only one of the minor advantages of Haskell.

>>4
Go back to your thread.

u mena haskal

HQ9+ has an explicit goal (according to Cliff L. Biffle) of minimizing the pain of writing common example programs - of having the fewest possible cases where what you want to express shows off the features of the language but doesn't fit in one of the primitive instructions. The useful cases that Turing complete languages supported but HQ9+ didn't are already supported (in a different way) in CHIQRSX9+ via extensions. In fact the modern HQ9+ instruction set is far superior to anything I know of in the Turing complete world.

So basically, you just don't need Turing completeness in HQ9+. You could do things using CHIQRSX9+'s X that you couldn't do with Turing completeness anyway, and with (stable, widely used) extensions such as R and S you can now do pretty much anything you could with a TC language. With multi-effect I and C functions, you can go beyond Turing completeness to handle what Java can do (probably more, though I'm not that familiar with Java) and a fair chunk of what C++ template classes can. And that's without looking at X.

There are some cases where Turing completeness still seems a bit more convenient, but mostly that's a short-term gain that's outweighed by longer-term losses. For example TC can be a lot more convenient at times because of the pervasive functionality, but HQ9+ keeps usefulness under control for a reason.

>>8
I love you. Please post more.