/tech/ - Technology

Yeah but you unironically use "app" as a word so your opinion doesn't count.

Learning haskell will teach you to think functionally. This has made me a better programmer in other, non-functional, languages.

Remember, programming is a creative endeavor. When you learn FP, you don't learn a language. You learn a way of thinking.

>Java/C#
lmao, go learn Smalltalk instead.

Functional programming is much more powerful and it disappoints me that your go to languages are not only a mess, but also corporate trash that is only popular because Oracle and Microsoft have spent quite a lot of money to turn them into standards.

All Turing complete programming languages are equal in power.

>>8012
yes but that doesn't mean they are literally the same.

i learned common lisp and scheme. it teaches you to think about programming differently i guess. thinking isn't that productive honestly, just rapid fire functions in c and tie it all together with tcl. if something needs rewritten it only takes a few minutes. programming is just math for brainlets and unless it's embedded it's probably not that important to anyone but maladjusted zoomers

>>8210
Based choice and based reasoning.

simulating mutability takes way too much extra time for FP to be viable. there has to be another way to encourage functional purity without making immutability the default.

>>8210
You've clearly haven't worked in an enterprise setting. Bugs are the fucking devil. FP reduces bug space.

>>8286
>FP reduces bug space.
that's what they'd like you to think, but does it? I've never seen any evidence that functional programming reduces bugs

Maybe I have a different understanding of the phrase "functional programming", but I write simulations and do regular statistical analysis in R and I couldn't imagine doing what I do as easily without the ability to write and nest functions within other functions.

>>8328
I hope you are not denying that stronger guarantees on type correctness makes it hard or impossible to write certain classes of bugs from existing.

>>8219
are you talking about development time or the actual performance of end result? How is compiler suppose to make any inference out of non pure objects?

>>8329
Functional is a dumb name, it should be applicative.

>>8332
>I hope you are not denying that stronger guarantees on type correctness makes it hard or impossible to write certain classes of bugs from existing.

you're conflating static typing with functional programming. There are dynamically typed functional languages ex: lisp, clojure.

FP is orthogonal to the typing issue

>>8345
>functional programming is orthogonal to typing
As someone who got into this dick swinging industry after every imperative languages under the sun adopted some 'functional programming principles' by 'allowing functions to be treated as first class citizen', calling impure languages like common lisp a functional programming language does not make sense. I heard clojure push immutability upfront or something but I never used it so I will not write about it. Only purely functional languages with evil io /exceptions monads that revolves around persistent data structures are worthy of the name functional programming languages.

And no, algebraic data types / type classes are much stronger concepts that allows smarter compilers than what was possible with statically typed languages where 33% of what I write or read is type declaration.

>>8354
saying only purely functional languages are really functional is autistic, any language is a FP if it implements at least partially the ideas of the lambda calculus, which lisp clearly does (in fact it was the first one).

>I heard clojure push immutability upfront or something
Clojure is more purely functional than scala but less than haskell, everything is immutable by default its only impure to allow you to incorporate existing java libraries with mutable code.

By your standards literally only a few rarely used academic languages are really "functional" i.e. maybe haskell and a bunch of purely functional lisps made by academic programming language theorists and used by no one else.

>algebraic data types / type classes
Meme. Plus non FP languages already have algebraic product types baked into how most languages work. And with a little more work you can easily simulate sum types in plain old java/js/etc. as well. There is nothing superior about FP modeling with an ornate type system than with objects/classes. Static FP languages use types for modeling because they don't use objects, it's simply an alternative way of modeling the domain, obv. Clojure is the exception here being data oriented and modeling data as EDN or w/e.

>algebraic data types / type classes are much stronger concepts that allows smarter compilers than what was possible with statically typed languages where 33% of what I write or read is type declaration.
>I hope you are not denying that stronger guarantees on type correctness makes it hard or impossible to write certain classes of bugs from existing.

The static type guarantees are overhyped, maybe if this was 1982 or something where the compiler was the only check on errors but in this modern age of linters, static code analysis, automated unit/integration testing, continuous integration etc. the benefits of this are probably 80% redundant for dynamic languages and even more for static OOP languages.

Also I feel like people who say this never took a class on programming language theory or compilers. People saying the ornate type system of Scala/Haskell makes it superior are missing the fucking point: the types are fundamentally there to help model data, compile time checking is a really trivial part of the reason for their existence in those languages. Saying the type system of those languages makes them better is like saying "language A does X and language B does Y and thats why A is better than B, B doesn't even have X!!!" It isn't better, its just different. Again, please think deeper than just just the level of a freshman learning python, programming languages are there to help the programmer MODEL THE PROBLEM DOMAIN, and there are different ways of doing that like classes/objects.

Yes, there are some impressive optimizations made by compiler writers of Haskell, Scala, and even Clojure (since it compiles to jvm bytecode), but even with that effort functional programming fundamentally is at odds with how computers actually work, which is procedurally. Machine architectures are inherently imperative von Neumann derived style, FP is a mathematical abstraction. Thats why even though Haskell runs insanely fast for a garbage collected languages, it will never be as fast as C/C++, golang or rust. A lot of this shit reads like basically parroting blogs/websites that shill Haskell but if you go to grad school of CS and actually learn about compiler optimizations at a high level you will learn how full of shit they are.

Furthermore the real problem with FP isn't speed but memory usage, which can become a problem esp for scaling. The immutable data structures, despite all best optimization efforts, in languages like Haskell/Clojure use a TON of memory, I'm not talking a trivial amount but potentially gigabytes, think of a web environment where you have to handle lots of concurrent connections, file uploads of images, video files, etc. you need all the fucking memory you can get lest 1 server running your app can only handle 100 users or something.

This isn't to say functional programming is bad, but the "advantages" of it are generally overhyped and not worth forcing the developer into a functional style 100% of the time. People who shill pure FP as the solution for everything have no idea what they're talking about when their experience is writing toy programs and working through SICP or the Haskell elephant book or w/e. The only remotely viable FP language is Scala, which isn't pure anyway and is like Java larping as Haskell. But even that isn't necessary. The rest of it is contained to academics and amateurs who real Stallman/Paul Graham blogs.

In any case the FP hype wave blew over the mid 2010s and now low level shit like go/rust is the hype, or just plain Java/C#.

I don't remember FP being a significant craze, but that might have just been my corner of the woods. People remained obsessed with OOP until recently, and now Rust has sucked up all the oxygen instead. FP was always a thing for people with a hard-on for formal logic and high level maths around my parts.

>>8404
>any language is a FP if it is compatible with or can express some form of lambda calculus
which makes that definition quite useless

>only rarely used academic languages are really 'functional'
Any language that does not make me inherit entire jungle with gorilla just because I wanted to use banana reads and writes functional to me for all practical purposes. And I know for a fact that most non trivial common lisp projects were not engineered with 'code reusability' in mind.

>algebraic product type
is not an actual word. did you mean? product type
>is baked into how most languages work
Not sure what you are implying.
How would you implement List as ADT in java? Maybe you smart enough to figure it out seamlessly as in not make type checker complain and not make it too boilerplate heavy but what would be the point of deriving it by hand when I don't enjoy any benefit of pattern matching while using your shitty implementation?

Also ever wondered why some c++ shops don't allow you use fancy stuffs like std::variant if OOP and FP goes so well together?

>static type guarantees are overhyped
what is the largest project you ever worked on in terms of LoC and numbers of people involved?

>languages are just different
>OOP is also valid way to model the problem domain just like FP
If you had to go to graduate school to realize this, you are probably wasting your life.

The reason people actually working in industry have been pushing FP meme and buzzwords like abstract type classes is because large problem domain that has been historically tackled within OOP framework turned out to be as easily 'approachable' in purely functional languages cheaply. Nothing more, nothing less. Nobody who actually write / read or considering to adopt haskell / ocaml / F# think it's better in every department. They want it because it's more expressive and less semantic error prone making it more competitive choice than java or c++.

>FP will never be as fast as c++
why yes every c++ projects automatically reach its full performance potential and correctness guarantee the moment it's last line is written without draining significant manpower that could have been invested otherwise. that 2 seconds saved in processor time will be surely worth it when you have to write another set of features that invalidate most of your logics and assumptions in next release cycle. Or when project is abandoned and everyone moves on to the next job.

Why would porkies working in Jane street use ocaml? Do they enjoy slower HFT algorithms and donate money to other firms or something?

>muh memory usage
>FP web apps needs GBs to handle 100 users or something
Is GHC memory inefficient when dealing with large sum / unicode string types? yes. regrettably with no easy or obvious solution in sight.

Did I have to change my VHS plan when we migrated from python to yesod cuz memory? NO. You are full of shit. Stop writing about things you only have pedantic understanding of

Reminder "design patterns" are cope.

Reminder OOP is neoliberalism as it applies to the software engineering craft.

>>8411
Based.

>>8332
>are you talking about development time or the actual performance of end result?
both. say you are doing a divide-and-conquer recursion like

f(4) = f(4) 
     = g( f(2), f(2) ) 
     = h( f(1), f(1), f(1), f(1) )

instead of doing a simple recursion and repeating

f''()

4 different times, you only have to do it once, take the output, and then combine them in whatever way you need, by storing the outputs on a table

f[x] = f(x) if f[x] does not exist else f[x]
return f[4]

in regular programming such an implementation is superfluous. how would you do it in functional code? I can't even imagine the types of workarounds you'd have to do to simulate the functionality of a global immutable like

f[]

>>8426
actually it's more like

f(x) = f[x] if f[x] does exist else f(x)
return f(4)

but you get what I mean

>>8411
OCaml and F# are not pure. I suspect that's at least part of the reason Jane Street uses OCaml and not Haskell.

>>8426
I have trouble parsing your example, is this a question on dynamic programming or just naming values? Maybe memoization in general?

>>8427
I think you are asking two different things but not too sure.

I will answer the memoization first a la
f(x) { if (f[x] == null) {f[x] = f(x)} return f[x];}

Haskell is semantically non-strict and the GHC compiler is lazy by default. This allows you to pretend like there exist an infinitely large data structure (list for single valued functions, map for multiple valued functions et cetra) that is populated with values you (will) need. When your program actually executes in hardware and needs that value, it will either utilize the contents of list / map / data structure or calculate (recursively or not) the value it need, store it into list / map / data structure and use it (transparently). There is no practical difference (as in how rough assembly language output would be generated) between your 'procedural' pseudo code and

memoize f = (map f [0 ..] !!)
fx = fix(memoize . f)

after all, turing machine and lambda expression should be equivalent right?

Now about the second part of the question regarding 'global' immutable, as you could readily understand the infinitely large data structure caching f's value is indeed immutable from programmer's perspective. Its contents are initally not 'realized' but it can, and it will be realized when you actually need it on runtime. You might be confusing not relying on mutability (side effect) while writing program and how haskell's compiler and runtime actually evaluates the code. If no side effect of any kind is not allowed while realizing computation, haskell or purely functional codes will not be able to do anything inside physical processor and that is not the point of 'purely' functional languages.

This is one of many reasons why people caricaturing haskell or other purely functional languages to be non-performant because of 'immutability' should actually study those languages and how their compilers and runtimes are implemented. There's no 'expensive deep copies or whatevs' happening everywhere for those languages to be 'immutable', compiler writers and languages designers spent lot of time for the codes to be written in a way that does not necessitate such things behind the scene while forcing programmers to think what they are actually trying to solve.

>>8429
I don't work in HFT and I am not fluent in modern MLs so I shouldn't comment on them but I mentioned it just out of spite. But beware that even haskell can be arbitrarily sped up and it is never orders of magnitude slower than c/c++ thanks to tools haskellers have access to: from very basic techniques like unboxing types (C/++ is not the only language that have access to native types or capable of generating appropriate processor specific instructions) and forcing strict evaluation at appropriate code path to something more nuanced like applying appropriate optimizing transformations that help TCO. Like, I know most people don't get paid write 'performant' haskell (outside of maybe facebook that is) and GHC devs and library developers do not normally prioritize runtime performance specific enhancements but saying it's slow because you cannot pretend to micro-optimize at machine level details is absurd.

>>8426
>>8427
Look up prolog son, some implementations do tabling for free

>>8432
Prolog is not a functional language.

>>8411
>The reason people actually working in industry have been pushing FP meme and buzzwords like abstract type classes is because large problem domain that has been historically tackled within OOP framework turned out to be as easily 'approachable' in purely functional languages cheaply. Nothing more, nothing less.

except that a bunch of people in the 2010s didn't treat it like that, they acted like OOP was "BTFO", outdated, and that FP would cure cancer and world hunger. Saying FP is ok in some circumstances is not the same as subscribing to the cult of FP and the blogosphere of it and shit

>>8446
what exactly is the value of this post? If you have valid criticism of haskell or MLs or frameworks written in those languages (which there are many and poor heap management is not one of them) share it with your personal experience or analysis. Why do you want to talk about nameless bloggers?