/tech/ - Technology★

No side effects? Althrough in reality any practical thing is hard to do without them.

A good chunk of early whatsapp was written in erlang. Pretty sure they switched to sepples after being bought out by facebook though

Some concepts are useful, but it's otherwise just a jewish mind trick.

>>1006685

To elaborate on that, the performant and useful FP languages are the most unpure ones (like ocaml).

most real languages (like python and c#) already use the useful parts of functional programming

Concise code, simple functions. Purely functional is insane tho.

>>1006751

Which is why it is sad that you can do all >>1006757 only to be about as productive as a nigger with Python.

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: https://www.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.

>>1006757

His pants are sitting disturbingly low...

>>1006757

>t. small brained turbo nigger

Are you angry because you cannot into FP?

>>1006767

>thinking FP is a brainlet filter

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

>>1006767

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.

>>1006769

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.

>>1006779

>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?

>>1006783

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.

>>1006792

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.

>>1006796

>Haskell isn't just GHC

Then Haskell is a dead language that literally nobody writes in, ever.

GHC is what's alive.

>>1006661 (OP)

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.

>>1006661 (OP)

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

>>1006819

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

>>1006821

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.

http://home.pipeline.com/~hbaker1/LinearLisp.html

https://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.

>>1006661 (OP)

Abso-fucking-lutely nothing.

If you want to explore an alternate programming paradigm which is actually usefully different, checkout logic programming.

>>1006906

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).

>>1006980

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.

>>1007111

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:

>I want to write a game.

<Will most of the game take place on some kind of server?

>yeah

<then use Erlang.

>>1007111

>Ugly syntax

you are retarded and a nocoder

>>1007163

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

>>1007150

Is that a fucking menorah?

>>1007231

>being this new

>>1007231

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

>>1006661 (OP)

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

>>1007029

>logic programming is slower than FP or imperative

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

>>1007231

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.

> A.1.2.1. Why is CLISP using menorah as the logo?

< 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.

https://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

>>1007111

>with 'do' in every function

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

>>1007422

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

>>1006761

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

>>1006792

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

>>1006819

>creating a new list every time even though you won't be using the original list anywhere is

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.

>>1007920

>Rust doesn't have tail-call optimization in 2018

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

>>1007926

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

>>1007927

>they're planning to probably add a keyword for tail calls

lmao

>>1007923

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?

>>1009868

It's a nice language, but as an anon 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.

>>1009868

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

>>1009868

Relevant post: >>1002692

>>1009868

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.

>>1009880

>it has a good ecosystem

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).

>>1009880

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?

>>1006661 (OP)

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.

>>1009868

See >>1009926

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.

>>1009926

>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

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

>>1009926

>And I found it just as hard to be effective and not lose yourself in meaningless details when dealing with FP.

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.

>>1006661 (OP)

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

>>1006667

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

>>1006761

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

>>1007111

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"

>>1009954

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

Citation needed.

>>1009926

>and linguo that makes everything much more confusing that it has to be

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.

>>1009868

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

>>1009919

> isn't type inference in typed racket pretty bad at least compared to functional languages without homoiconic syntax?

I don't know, I haven't used those enough to make a comparison

> Did you feel like that slowed you down?

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.

>>1010316

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

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.