Is FP Niggerlicious?

FP's better if you'd rather troubleshoot performance than troubleshoot bugs.
FP langs with good type systems (OCaml, Scala probably, Haskell, Erlang to an extent with optional analysis) permit you make checks early and then have islands of safe and [Haskell has left this sentence] readable code where you know you don't have to have paranoid checks for out of bounds data because the type says that it's in bounds.
All FP langs tend to have garbage collection (the cancer therapy from the 60s, not quite a cure), lots of higher order functions, immutable data structures, etc.
Of the languages listed, OCaml is terse yet readable and is a prince of all trades, proving that people who say "the right tool for the right job" of programming are just people who know a lot of shit languages with narrow utility. OCaml has real success with Jane Street: youtube.com/watch?v=v1CmGbOGb2I
Of the languages listed, research at Ericsson said nice things about the size and bugginess of Erlang. Although Erlang definitely isn't useful for everything, it's just fucking magic in its own domain and its had success all over the place, in big pozzed companies and small companies and personal projects on a Zaurus running OpenBSD. Here's another single example for it: Vendetta Online uses it. The biggest flaw of Erlang is that it has two string types and the natural default of them is a list of 64-bit ints. Elixir probably goes far to fix that, by making the other type the natural default.
honestly Elixir looks like shit to me vs. Erlang, just in language aesthetics, but you probably won't agree.

His pants are sitting disturbingly low...

Are you angry because you cannot into FP?

the more difficult languages in OP's picture are difficult because of their defects, not their FP-ness.

You really don't want to go too far into the FP meme. If you even understood half of the terms in that post, you'd know that too.

Brainlets think FP is a brainlet filter though. Their perspective is intrinsically limited to that which is hard for a brainlet, so they project it on everyone else.

It is easier to prove things about the program.
It is easy to create abstractions that make problems easier.
They typically come with a powerful type system,
With strong enough types you can even automatically generate functions. For example if you know you have a function of type a -> a, then it must be the id function. It is IMPOSSIBLE to create any other function with type a -> a which is not the id function.

in Haskell such a function could have an unsafe* function in it that performs arbitrary IO
in OCaml such a function could use Obj.magic and such to return garbage of type a; or inspect the type and have type-dependent behavior
in ATS you can use templating or overloading to have an a -> a that behaves different for different actual types.
in a dynamic language like most in the OP's pictures, of course, IMPOSSIBLE guarantees like this rarely come up.
meanwhile, wow what an amazing thing, something that's probably id by its type. I guess you're not jealous at all of dependent type systems.

General opinion on Elm as a front end web language?

idk about the other languages but the unsafe* functions you refer to are not a part of Haskell. It's a GHC thing.
I'm actually more interested in linear types than dependent types, but dependent types are cool since you can write proofs with them. Well you can write more complicated / actual useful ones with them.

it looks very cool but I've limited enough need for front end development that I haven't used it yet. If another project comes up and isn't too much of a hurry, I'd definitely consider it vs. JS + the usual suspects (Vue, React, or Mithril). The JS interface is obnoxious but for that reason you're more likely to find an Elm alternative to the JS library you want. It's an auto-formatted language ala Go with go fmt. Although the language looks like Haskell, it has a focus on clarity and readability that acts as a blessed crucifix before Haskell's vampires. The main dev has a) very entertaining and thoughtful presentations on the language and on other matters, and b) a constant need to bitch and moan about how people bitch and moan and posture to him about his language [these are the same presentations; often B is the motivation for A]
If you also write back end code, take a look at Reason instead. More opportunity there to use the exact same data validation code on both ends.

Then Haskell is a dead language that literally nobody writes in, ever.
GHC is what's alive.

depends on the language honestly:
erlang, elixir, and clojure were made to give better tools for abstraction, and concurrency (performance).
ocaml is much more focused on correctness and means of abstraction (in different ways) with little interest in concurrency, although they do their best to be fast in traditional ways.
common lisp is not focused on correctness or concurrency but is every interested in performance in traditional ways and means of abstraction.
scheme is interested in being simple and some means of abstraction.
haskell and idris only care about correctness, and because of this they get some interesting means of abstraction and concurrency for free, but any performance or abstraction they get is really secondary to them.
by correctness I mean both ability to prevent bugs up front and to debug easily.
by means of abstraction I mean the ability to express a complex pattern in a new way (functions, typedefs, macros, first-class modules, dependent types, etc.) and the ability to use these to a greater extent.

Functional programming is like object-oriented programming: a useful skill to have in your toolbelt, but trying to view everything through pure FP is autism.

FP can produce code that's concise and easy to reason about. This can come at a cost of performance though, mapping over a list and creating a new list every time even though you won't be using the original list anywhere is a waste of resources.

The only good FPlang is ATS, and that's because it doesn't have a garbage collector. Its performance is close to C and its type system is really cool.
Too bad the syntax is cancer

you can have exceedingly efficient pure data structures, especially when it comes to concurrent read/write. Clojure has the best examples of these.

Garbage collection is really useful to increace the expresivness of a language; however, often you need to do without so it's pretty cool that ATS has such a low floor along with its high ceiling in this regard, and especially that it can do this safely. LinearLisp & LinearML also don't have garbage collectors, but nor do they have explicit memory management, they simply don't produce garbage if you're interested.
home.pipeline.com/~hbaker1/LinearLisp.html
github.com/pikatchu/LinearML

FP tends to be really good for things like parsing and compiler front ends. Or anything with a lot of composition or pipelining, like transforming data streams.

Abso-fucking-lutely nothing.
If you want to explore an alternate programming paradigm which is actually usefully different, checkout logic programming.

All programming is logic programming.

Attached: apu 3f4.jpeg (200x197, 8.29K)

They are really expressive at these things but not necessarily performant, parser combinators are always slower than parser generators (although maybe they don't have to be).

Mercury is pretty cool but generally speaking Logic programming languages are exceedingly slow (far worse than functional languages) because of all the backtracking they have to do, and because they're declarative it's exceedingly difficult to optimise.

1) CommonLISP
- standard is basically copypaste of one of implementation's doc. Obtuse, bloated, compatible with OSes which went extinct before niggers fucked OP's mother.
- as 'functional' as C is 'structured
- bus factor = 1 by design
+ you don't write in CLISP. You write in bespoke language you wrote in CLISP.
+ job security
+ actually fun to write in

2) Erlang
- not actually functional
- slow performance of individual threads
- PHP for phone switches
+ simple and straightforward
+ parallelism and concurrency are as cheap and easy as it gets
+ ETS, OTP, easy C bindings
+ comfy

3) Elixir
- pozzed
- ugly syntax
+ is actually Erlang

4) Haskell
+ purest of them all
+ manages to explicitly express side-effects
+ hoogle
+ fast (if you are lucky)
- idiomatic haskell assumes machine with infinite memory and timeless universe
- (you)r program will look like retarded python, with 'do' in every function and crash on every second run.

5) OCaml
+ functional
+ practical
+ you should learn it
- made by frog eating faggots
- not haskell

6) Scala
+ Better JAVA, without "Should be usable by 80IQ pajeet" constraint
- JAVA
- frogs

7) Clojure
+ Good parts of LISP
+ JAVA libraries
+ Programs can be readable to people other than original author
- Not best parts of LISP

Attached: 1339267510083.jpg (600x360, 125.48K)

good analysis, except the last point for OCaml should read "+ not haskell", and most of the points under Haskell should have - rather than + in front of them.
still, it'd be better to approach these languages with some specific interests in mind, so you can get more relevant points. For example:

Don't call it that, it gives people the impression that the implementation called (((CLISP))) is somehow the canonical implementation. It is not, it's just another implementation out of many. Call it Common Lisp or CL for short.

Attached: serveimage.jpeg (640x434, 46.81K)

you are retarded and a nocoder

How could you read through the entirety of his post and then conclude that he was a non-code?

Is that a fucking menorah?

...

(((STEINGOLD))) didn't answer that for you?

Unlike OOP, FP has legitimate use cases, like formally verified code.

That's like pointing out that a car is slower than an airplane. Use the right tool for the job.

There's a decent post on PozOverflow concerning this topic.

Attached: OOP vs FP.PNG (700x1076, 86.52K)

You know what the best part is? The original author who put in the menorah is not even a Jew, it's just a really good goy.

< Whimsical
< If you must have some answer and you do not care whether it is correct or not, you may simply think that Common Lisp brings the Light to a programmer, and CLISP is a vehicle that carries the Light.
<
< Accordingly, CLISP enables you to see the truth, thus you can pronounce it as see-lisp. Alternatively, if you are a seasoned expert, you might pronounce it as sea-lisp.

< Historical
< CLISP has been using the menorah for the logo since the project was first started in the late 1980-ies by Bruno Haible and Michael Stoll. This probably reflects the authors' affection toward the Jewish people, Judaism or the State of Israel (neither of the two original authors is Jewish by birth). You may ask the original authors for details yourself. Both of them are very busy though, so do not expect a prompt reply.
clisp.sourceforge.io/impnotes/faq.html#faq-menorah-why

Anyone else cursed to use KDB+/q at work?

It's really efficient but fuck me it's horrible to read

Overuse of do notation in Haskell code is considered anti-pattern and should be avoided.

that's what he was fucking saying: your code will be bad

Seems like he's just as confused, and this is a very subtle way for him to get people to badger the original authors in the hopes that they eventually spill.

Attached: a9e3cb3fdb57180d0ff1213f24bb507ab115929666a880cda5aab14de1502fc8.jpg (311x400, 20.55K)

Rust is pretty much a typed FP language (it'll be more complete when they add explicit tail call optimization) without the GC baggage.

Very nice shit, though there are other options for functional frontend, like purescript and haskell or F# to js compilers.

lists are trees in these languages, you can just reuse the old allocation and add a bit of new data to it since it's immutable.

Is this for real? How do rustniggers have the gall to shill such an incomplete language

Because tail-call optimization isn't explicit, has unpredictability and edge cases. So they're planning to probably add a keyword for tail calls.

lmao

Hi Cheetah.

Attached: rotten cheetah.jpg (600x399, 79.03K)

No, I meant when you do a map over the entire list, in that case you have to allocate a new list if you are not mutating the old one.
(define l '(0 1 2 3 4 5));; This creates a new list(define l2 (map (lambda (x) (* x 2)) l))

Anybody got any experience with Racket? I've been messing around with it since yesterday and I actually kind of like it. Are there any gotchas?

It's a nice language, but as an user pointed out to me, there is now a tranny on the development team. Other than that, it's a good language for your projects, but don't expect to find a job as a "racket" programmer.

If you've touched CLOS you'll probably find Racket annoying.

Relevant post:

Aside from the tranny, not much. Typed Racket is particularly nice, dynamic typing is way overrated. There is a decent amount of libraries and it has a good ecosystem with a package manager, unlike for example Guile. I used it in my thesis, the language itself made it very easy to create nice code and the plotting library allowed me to actually visualize everything and make a "stroboscopic" rendering of an object in motion in a couple of lines of code.

The documentation is also well written, but there is not much to ease you into the language. One problem is that Racket is used in teaching, but they teach the concepts of computer science, not Racket itself, and they usually use some sort of baby-Racket instead of the real thing.

I should have stressed this above, there really is A LOT of batteries-included with the default racket install (although they did move some of into separate packages).

isn't type inference in typed racket pretty bad at least compared to functional languages without homoiconic syntax? Did you feel like that slowed you down?

Is TCL basically Lisp with less autism?

I am moderately intelligent. I study combinatorics and computer science and was taught PLT Scheme (aka Racket) as my first language. It's comfortable and I like it.

But FP is bloated with hyper-abstracted terms and linguo that makes everything much more confusing that it has to be.

In particular, I have found Haskell to be a headache with OCaml being slightly better. I think there is a lot of cargo-cult at work here. I don't see how I could ever be productive in either of these languages. It's hard to reason about dynamically typed code, especially in larger codebases. And I found it just as hard to be effective and not lose yourself in meaningless details when dealing with FP.

I will get a lot of hate but on the contrary, C++, Golang, and even Rust are much better - for me at least. To elaborate on Golang, I realized that the language is cleverly dumb. The abstractions are basic and perhaps incomplete in some ways and that's precisely why it is so much more productive: simplicity makes cognitive room to reason about the actual software you are trying to build. With Haskell, I found myself spending more time and effort *dealing with the language* rather than building anything.

And the systems I have built with Golang are stable with near perfect uptime and little technical debt. I don't think I could have done a better (cost-efficient + stable + meeting perf reqs) in Haskell or OCaml.

See
I enjoy Racket a lot. The documentation is hard to parse at first but you get used to it. There are a lot of perks that comes with working with Racket. With that said, I have been told by people who write Racket for a living that my code was clean, modular etc. yet I find it pretty hard to re-read it and understand it a few months after not peaking at it. Same goes for code written by other people. It might be lack of experience but I suspect there is something deeper. Racket is convenient and expressive (tight code does a lot) but it's a headache to parse and understand code that has nested list processing procedures (fold*, map, filter) if you haven't written it yourself (and that's 99% of Racket code written in general). So your mileage may vary.

This is a great way to describe my experience using Golang as well.

You nailed it. FP is a mind trap, which just leads you down a complex intellectual infrastructure which ends up making you no more productive than a PHP nigger. I'd recommend people look into it, but don't take a deep dive.

all 3. speed if compared to java,python,lua or some similar such braindamaged language

false. the only reason FP isn't use a lot is because it isn't.

Erlang shit. neckbeards here will defend it because it looks like UNIX (on a superficial level, other than being shit)

literally everything you listed is shit and meme. the only real FP language anyone uses is SML. Scala is a fucking joke. OCaml is a crippled ML in the name of "practicality"

Citation needed.

Ah yes, let's dumb it down for brainlets to understand. Reusing things from mathematics is a good idea since they have already done a lot of the work for us. Both those mathematicians and programmers want to create a system in which it's easy to solve the problem at hand. Why people want to discover everything independently beats me. Maybe they don't want to associate with those algebra weirdos.

I was kinda curious about Typed Racket. Doesn't static typing contradicts the whole point of a Lisp language?

I don't know, I haven't used those enough to make a comparison
Not really. You can write untyped Racket first and then later harden your code by changing it to typed Racket. It does make your code more verbose, because with untyped Racket you can simply assume that for example a function that reads a byte from a file will always return a byte and shove the case where it returns EOF just under the rug. With typed Racket you have to handle that case as well.

Why would it? Common Lisp has type annotations as well, they are optional though. Type-annotating allows the implementation to generate faster code, catch type errors and at least in the case of SBCL types can be checked at compile time (though I'm not sure to what extent).

I have been using Chisel (Scala) for the last few months and I have to say that its been pretty nice coming from an embedded C/C++ background. While its not purely FP, going back to C++ after months of not writing any made me realize how awful C/C++ are to the point where I am probably going to sit down and learn Rust since it now has some really nice language features which C++ developers have been requesting for a while.