if your langauge doesn't have>first-class functions and closures>strong static typing>non-nullable values by default>sum types>typeclassesthen it's not worth using
>>107484949Types are like training wheels. Good for beginners but you don't actually need them if you know what you are doing.
>>107484949
>>107484949You only mentioned the features that are already in Rust, Swift, and any other modern language. Next time mention actual Haskell specific goodies like GADTs, HKTs, and purity.
>>107485003>t. C++ tardWe all know you can’t be fucked to type std::this::stupid::namespace::shit::makes::no::sense.begin() and resort to auto instead. No need to be smug about your language being a stinking pile of shit.
>>107484949What’s the point of non nullable types if you’re going to be using option types or maybe monad or whatever it’s called anyway? There’s no getting around the fact that in programming you can’t always be sure you will have access to all your resources
>>107486418Compiler forces you to check if it's not empty and that is le good
>>107486418>if you’re going to be using option types or maybe monad or whatever it’s called anyway?You often have values that are guaranteed to not be null. Differentiating between "can be null" and "cannot be null" is useful for both the programmer and the compiler.Also, with Maybe, you can nest Maybes a much as you want, e.g. Maybe(Maybe x) or Maybe(Maybe(Maybe x)). This is useful e.g. if you want to know at what point you got a Nothing / null value. For example, you can differentiate between "query returned null" and "query failed"
>>107485339Rust and swift don't have proper typeclasses anyway>GADTsGood feature but 90% of /g/ doesn't know what they are>PurityRust has immutability by default, which fixes some problems related to side effects. With Haskell it's more complicated because lazy evaluation means that values are mutable albeit in a controlled way
>laziness>gcno thanks.everything else is cool though
>>107487512>lazinessNot nearly as bad as you might think. 90% solved by importing strict containers.>gcyeah this is bad for some applications. at least they have nonmoving GC now, which minimizes latency
laziness is such a meme, my for loops can be lazy too.
>>107487512>GCNot a problem for at least 99.9% of the applications.
>>107488209I'm the 0.01%
>>107488329Maybe learn arithmetic before writing performance critical code?
>>107484949You are right, english has none of these
>>107488329>I'm the 0.01%
>>107485003types are more like boosters really. they let the compiler automate a lot of stuff for you.in C, types exist to let the compiler know how many bytes each data type takes up. proto-C (B) didn't have this feature (the only type was the machine word) and that made some operations cumbersome to implement.in Haskell, types allow the compiler to automatically look up and supply typeclass implementations. this lets you write `sort xs` instead of `sortBy compareIntegers xs`but if you're a javajeet or a pytard, then yeah, types are just an afterthought carelessly sharted onto the language
>>107487123>rust>pureby design rust is not functional, it may have some little features that are kinda functional, but no>lazy = mutableholy retard
>>107489957Java is a strongly typed language.
>>107484949haskell is garbage. Use Erlang.
>>107484949I love functional programming very much but I think 99% of functional programming advocates are cargo cultist midwits who couldn't write useful software.
>>107485003>Types are like training wheels. Good for beginners but you don't actually need them if you know what you are doing.You have never built a big system. About 40 years ago we passed the point where anyone could comprehend what’s happening inside software. At any given time you can only understand about 0.1% of a program; beyond that you can rely only on strong interfaces between your pockets of temporary understandings. This is exactly why dynamic languages don’t really scale. They’re only good as long as you write 1–2 dialogues in them, or duct-tape together various libraries written in real programming languages.
If you can't prove that your code does what it should, why even bother?>>107485003> Types are like training wheels. Good for beginners but you don't actually need them if you know what you are doing.Do you carefully reread the whole code base every time you change a single line of code? Or do you just yolo and hit type errors at runtime like a retard?
>>107484949>your langaugeThere is no "your language". There's only proper tools for a job, or less than optimal fit for a job.If you have to post things like this about a particular language, you're probably using it wrong and want everyone else to do it with you.
>>107485003Types are literally math. You use them to prove to the compiler that your code is correct.
>>107490940what in the braphog slampig
>>107491963You don't really prove anything though, because most type systems do not have means to say anything. You can't even express something as basic as ∀(n k: Nat), n + k = k + n in Haskell.
>>107485003are you a retard?.. you should probably go to a psychiatrist or something...
>>107485010>AZOZIN SAYS HASKELL IS LE BAD THEREFORE IT'S LE BAD!!Tsoding's profession is rage baiting and making people believe polarizing things. He's intelligent, intelligent enough to make people on the left side of the curve think he's some kind of programming god. This said, his content is pretty fun
>>107491963This is factually wrong. Types are a necessity if you aren't capable of creating a compiler that can understand types. Understanding that something is a string or a integer shouldn't be have to be told to the compiler in 2025. Typer errors might be the most common error in programming btw and the one that causes most (White) people to stop programming entirely. That's why Python conferences are swarmed by White vibe coders in 2025.
>>107492146that's a perfectly valid opinion, static vs dynamic typing is a classic PL trade-offretard...
>>107491963most math notation is untyped
>>107485003Nice bait, faggot.
>>107493006> most math notation is untypedTypes are implicit.
>>107484949get off 4chan and pay attention in class
>>107493219yeah, same with dynamically typed langsor even with Haskell which uses Hindley-Milner type system
>>107491744Is this shit actually usable now, or are you just shitposting? I mean both for proving ordinary math (e.g. statements about differential equations) and making useful programs/libraries. Languages like this rarely graduate from research toy.
>>107484949assembly is easier to program in than Haskell.
>>107492073>You can't even express something as basic as ∀(n k: Nat), n + k = k + n in Haskellit's a pain in the ass to define and use but you can do ithttps://stackoverflow.com/questions/50787796/proving-commutativity-of-type-level-addition-of-natural-numbersby this point, though, you'd seriously consider switching to idris. >>107493219>all elements of R are sets and they all have no elementsthis is wrong and stupid. The typical construction of real numbers in ZFC goes as follows:1. natural numbers are finite ordinals (every natural number is the set of all smaller natural numbers)2. integers are equivalence classes of pairs of natural numbers.3. rational numbers are equivalence classes of pairs of integers (a, b) where b /= 04. real numbers are dedekind cuts (with rational numbers defined in step 3)
>>107493494For math it's usable, Mathlib is pretty big. For programming it's probably about as useful as Haskell (i.e not really). It has a better tooling than Haskell, but basically no libraries.
>>107490308typing in java can be trivially bypassed and almost doesn't matter at runtime anyway anyway (as proven by clojure using the JVM). also note that polymorphic types (aka 'generics') weren't added right away and that a lot of stdlib functions (e.g. compareTo) don't take advantage of Java's so-called static typing. afaik pretty much only go and python are worse in this regard
>>107491744>Sofia>look inside>it's a fucking malelolhttps://lean-lang.org/fro/team/
>>107484949>try to do anything useful in Haskell>language literally physically prevents you from doing it
Daily reminder that you can't write a true quicksort in Haskell!!!!!!!!!!!!!!!!!!
>>107495744Why not?
>>107493787>typing in java can be trivially bypassedis this trivial bypass in the room with us right now?
>>107495744>>107496323That's true for any purely functional language, though. The concept of quicksort itself requires mutability lol.You use mutable arrays inside the ST and IO monads thougheverbeit
>>107484949at least my language is readable.if you enjoy reading haskel you might as well try brainfuck.
>>107496495>IO / STExactly. You could also do it using linear types. (You could also do it without IO, ST or linear types, but such code would be extremely unsafe)
>>107496415Yes, it's called casting. Java has several types of casts (some safe, some unsafe) and they all use the same notation so they are impossible to tell apart at a glance
>>107484949>mogs you and your half-baked hipsterlang
Has anyone tried flix? https://flix.dev/
>>107497037>JVMslop>type inference doesn't work>No proper tail calls>No STMYep, it's dogshit
>>107489957> boostersAhh… no.sizeof() suffices.MASM has SIZE or DB/EQU a bunch of stuff, and put a dope vector at the end.
>>107498513>sizeof() suffices.* The compiler inserting sizeof for you is a productivity boost* You need types to use sizeof in the first place* sizeof doesn't help allocate stuff on the stack
>>107497119>JVM slopdiscarded
>>107498320>JVMslopDoesn't have to be >type inference doesn't workWrong>No proper tail callsWrong>No STMNo need because scala mogs haskellshit in terms of concurrency by miles.
>>107501488TCO that only works for self-recursive tail calls isn't proper tail calls
>>107497037If you take any two of the random extensions that have been thrown into scala and try to use them together, they typically don't play nice. e.g. Implicits and subtyping don't play nice together.Type inference works right up until you write anything that needs it. If you go to write any sort of tricky recursive function, you know, where inference would be useful, then it stops working.Due to type erasure, its easy to refine a type in a case expression / pattern match to get something that is a lie.Free theorems aren't.Since you can pass any dictionary anywhere to any implicit you can't rely on the canonicity of anything. If you make a Map or Set using an ordering, you can't be sure you'll get the same ordering back when you come to do a lookup later. This means you can't safely do hedge unions/merges in their containers. It also means that much of scalaz is lying to itself and hoping you'll pass back the same dictionary every time.The container types they do have have weird ad hoc overloadings. e.g. Map is treated as an iterable container of pairs, but this means you can't write code that is parametric in the Traversable container type that can do anything sensible. It is one of those solutions that seems like it might be a nice idea unless you've had experience programming with more principled classes like Foldable/Traversable.You wind up with code that looks like myMap.map(...).toMap all over the place due to CanBuildFrom inference woes.Monads have to pay for an extra map at the end of any comprehension, because of the way the for { } sugar works.
>>107502032You have type lambdas. Yay, right? But now you can't just talk about Functor (StateT s IO). Its Functor[({type F[X] = StateT[S,IO,X]})#F], and you have to hand plumb it to something like return, because it basically can't infer any of that, once you start dealing with transformers ever. The instance isn't directly in scope. 12.pure[({type F[X] = StateT[S,IO,X]})#F] isn't terribly concise. It can't figure out it should use the inference rule to define the implicit for StateT[S,M,_] from the one for M[_] because of the increased flexibility that nobody uses.In this mindset and in the same vein as the CanBuildFrom issue, things like Either don't have the biased flatMap you'd expect, somehow encouraging you to use other tools, just in case you wanted to bind on the Left. So you don't write generic monadic code over the Either monad, but rather are constantly chaining foo.right.flatMap(... .right.flatMap(....)) ensuring you can't use the sugar without turning to something like scalaz to fill it in. Basically almost the entire original motivation for all the type lambda craziness came down to being able to write classes like Functor have have several instances for different arguments, but because they are so hard to use nobody does it, making the feature hardly pay its way, as it makes things like unification, and path dependent type checking harder and sometimes impossible, but the language specification requires them to do it!You don't have any notion of a kind system and can only talk about fully saturated types, monad transformers are hell to write. It is easier for me to use the fact that every Comonad gives rise to a monad transformer to intuitively describe how to manually plumb a semimonoidal Comonad through my parser to carry extra state than to work with a monad transformer!I've been able to get the compiler to build classes that it thinks are fully instantiated, but which still have abstract methods in them.
>>107502044Tail-call optimization is only performed for self-tail calls, where you do not do polymorphic recursion.Monads are toys due to the aforementioned restriction. (>>=) is called flatMap. Any chain of monadic binds is going to be a series of non-self tailcalls. A function calls flatMap which calls a function, which calls flatMap... This means that non-trivial operations in even the identity monad, like using a Haskell style traverse for a monad over an arbitrary container blows the stack after a few thousand entries.We can fix this, and have in scalaz by adapting apfelmus' operational monad to get a trampoline that moves us off the stack to the heap, hiding the problem, but at a 50x slowdown, as the JIT no longer knows how to help.We can also fix it by passing imperative state around, and maybe getting scala to pass the state for me using implicits and hoping I don't accidentally use a lazy val. Guess which one is the only viable solution I know at scale? The code winds up less than 1/2 the size and 3x faster than the identity monad version. If scala was the only language I had to think in, I'd think functional programming was a bad idea that didn't scale, too.for yield sugar is a very simple expansion, but that means it has all sorts of rules about what you can't define locally inside of it, e.g. you can't stop and def a function, lazy val, etc. without nesting another for yield block.
>>107502055You wind up with issues like SI-3295 where out of a desire to not "confuse the computation model", it was decided that it was better to you know, just crash when someone folded a reasonably large list than fix the issue.. until it finally affected scalac itself. I've been told this has been relatively recently fixed.No first-class universal quantification means that quantifier tricks like ST s, or automatic differentiation without infinitesimal confusion are basically impossible. def test = diff(new FF[Id,Id,Double] { def apply[S[_]](x: AD[S, Double])(implicit mode: Mode[S, Double]): AD[S, Double] = cos(x) })is a poor substitute for test = diff cos
>>107502061TL; DR: Scala is a bloated pile of shit
