Name a language better than Haskell

Brainfuck.

Attached: Screenshot from 2018-09-02 06-54-31.png (266x408, 13K)

Visual Basic for Applications.

HolyC

Unironically Standard ML.
I prefer it even to Ocaml and F#.
It's the Scheme of the ML family. Truly the white Aryan man's choice.

D

Haskell is too hard to learn and not suitable for system programming.

idris

German

Then present your arguments in favor of Haskell if you have any, but you're just probably memeing, because you've seen it posted here many times.

Racket.
Now you can end your life, thanks me later

Attached: lisp.png (623x623, 46K)

based

I was going to say something sensible and centrist, but then I remember where I am.

php

in other words, you don't want to say what you think is the best language because you're afraid someone will insult you

json

ASM

Pepsi ?

Swift

>overally
Yes. That's what they were saying.
Haskell is an incredible language that encourages maintainable code. SPJ and Philip Wadler are very talented language designers. However, without massive industry support, Haskell is a bad choice. It's a meme that it's harder to learn; proper C++ (as in, not writing it like a C# brainlet) is more difficult to learn. That being said, the best language, as a function of both popularity (which is a huge boon...) and language quality, is Python.

/thread

Can confirm the bitches, you're wrong about the job though, Hasklel is my job; we're hiring like 6 more.
>Ocaml and F#.
How did we allow either of these atrocities to be born?

Attached: 1494371195328.gif (720x480, 309K)

muh boi

Rust is more inclusive
:^)

Is there Parallelism in Idris language?

Do they work like Haskell? Which is said to be very good at concurrence and parallelism?

Also, what's a "Pac-Man Complete" in programming language?

Does it mean that the language can fully run a Pac-Man game without being dependent of external languages, so it's a proof that it's a general purposed language?

I can't really find any info related to that. I know that Idris is new... but I also think that there're something about that somewhere.

Attached: 1535032743035.jpg (2335x2507, 685K)

Most functional languages are better. Modern Haskell is just GHC seeing how much bullshit they can haphazardly staple to the language without it breaking.

p
No I was going to say different languages are good for different things, but people here can only comprehend absolutist autism, and would veiw my statement as a cop out.

c++

Python, fight me.

any other language, including (((lisp)))

Coq
> Dependent types let you define and prove theorems over programs as you write them that are far stronger than the free theorems you get in a general pure typed language.
> Tons of libraries for math and deep formal verification shit.
> User-definable syntax.
> Export (formally verifiable) programs to Ocaml, Haskell and C for execution.
> Use tactics languages like Ltac to prove theorems interactively.
> Strong normalization means all programs terminate. Strictness by default means time and space complexity are easy to reason about.
> Inherent complexity keeps the brainlets out.
Haskell's bretty good by normie standards though.

Attached: coqtan.jpg (234x216, 11K)

Is Idris concurrent and does it have parallelism?

What's the downsize of Dependent types?

They often have runtime checking overhead and not every function can be proven to be total by the compiler and some have to be manually annotated.

Not sure about Idris.

I don't believe Coq is concurrent or parallel, but I'm not sure.

The main downside to dependent types is that they're more complicated than lighter-weight solutions to similar problems like refinement types, modal logics, abstract interpretation and model-checking, and HOL. They also impose a linear overhead for all datatype construction in the length of the datatype. So accessing lists for instance is quadratic. Doesn't matter if you're exporting performant programs that you've proved in the language, but it does limit the scaling behavior of endogenous code. Nothing is more powerful as a proof foundation than a dependently theorem prover though.

Also there are concurrent separation logics in Coq for writing imperative programs, like Iris.

Biggest problems holding Haskell back is lazy evaluation by default and strings not being a primitive data type. Also not being able to do easy and efficient mutation makes it impossible to use as a systems language.

I read that Haskell is parallel and concurrent, what's limiting Idris or Coq?

umm i think japanese

Does Idris or Coq resolve this problem?

Idris solves the first two and I've heard the developer talking about how he'd like to make it an efficient systems language. But generally a purely functional programming language isn't going to be a good systems language without sacrificing purity.

I think I'll go with Idris as my first functional language, I already started with Haskell, but still...

Do you think that Idris will be concurrent and parallel in the future?

>lazy evaluation by default
>strings not being a primitive data type
PureScript addresses both.
It is interesting to see a comment start out sensibly then slowly descend into pure trolling.

If it's not implemented already it's guaranteed to be added eventually. Parallelism and concurrency is one of FP's biggest strengths. I'm sure you know but Idris and Haskell are very similar so you'll be treading over pretty much the same ground with both of them. There's orders of magnitude more informational material out there on Haskell and from my experience most of the material in Idris just assumes you know Haskell already so I'm not sure how well it would work as an introductory language. Also considering that Idris is a relatively new language and there's bound to be bugs in the compiler and almost 0 library support.

I see, so I'll start with Haskell. But Idris seems to be much more interesting...

I just read this:

ejenk.com/blog/why-dependently-typed-programming-will-one-day-rock-your-world.html

I like Haskell, but its old and has a lot of dumb old legacy decisions.

If they just shrunk the language by removing all the dumb parts it would be amazing

Dumb parts include
0 Record syntax being sugar for custom types and automatically generating functions that extract values. Just make records their own thing and dont assume functions
1 Crappy string type
2 Impossible and confusing package managers
3 Functions that have exceptions like List.head not returning a Maybe
4 Needing to import qualified and unqualified versions of every module.

Frankly they could even go farther. Im still not sure why there even need to be typeclasses or do notation. Just seems to make things complicated and technical, but not superior in practical terms to their closest alternative implementation that doesnt use do notation or typeclasses.

In the case of Coq, there are libraries. There isn't lots of need for concurrency for proving theorems over programs you can export to a language with stronger concurrency support.

>Coq
So, what's better, learn Haskell and than Coq or Haskell and Idris?

Personally I can't see you getting a lot of use out of Coq unless you're a PhD mathematician or computer scientist. There's also Agda if you want to look into that for more dependent types. If you want practicality stick with Haskell and Idris.

Blodwen (Idris)
- interfaces and auto implicts are the same plus we can construct interfaces as data
- proof search (program inference)
- Linear types (tweagIO are behind on this)
- Actual namespaces
- Elab based meta programming (TH is nowhere near)
- ability declare new syntax without writing a parser
- dependent types
- better error messages
- better tooling (minus a package manager)

Idris then read software foundations and follow with Idris

The Wolfram Language.

Attached: FizzBuzz.png (1023x617, 19K)

>Idris then read software foundations and follow with Idris

Which foundations?

I'm going with Haskell Programming from the First Principals and then I'll go with Type-driven Development with Idris. I'd like to start directly with Idris, but I couldn't find a book that would teach a total beginner on functional language, except for the Haskell one.

Amusingly Type Driven Development is the book you're looking for. After it you can follow most haskell books with Idris as long as you take note when they mention lazy structures they mean Lazy structures.

For an introduction to functional programming I suggest "An introduction to functional programming with lambda calculus" then TDD after

I see, nice, thank you very much

So I'll read these two books, Introduction and Type Driven.

Has anyone ever programmed in the Wolfram Language without getting terminal cancer?

monads

For lambda there's the lci interpreter (but you should really follow on paper) and with Idris do make sure you install the plugin. I usually have the repl in watch mode (:w) while working on my programs so I catch errors on write.

Not a good enough reason for either as both support monads

Oh, so Idris is actually a Haskell package?

Is it running over Haskell?

But I thought it didn't use the GHC... I didn't get it.

I just found the Windows binary here: github.com/idris-lang/Idris-dev/wiki/Windows-Binaries

What's exactly the difference between the plugin and the binary?

sure, different languages exceed in different things, but surely there must be a language that has the best average score when it comes to usability across all the things
also, a simple "different things are good for different things" comment is just a plain boring answer because it's pointing out painfully obvious things and doesn't answer the topic of the thread

HolyC

>Which foundations?
The Software Foundations series.

brainfuck, malbolge

C

Haskell is designed to get stuck in a functional paradigm which for me is uncomfortable.

PHP

compiled: c#
interpreted: ruby

Attached: 1c.jpg (1240x580, 33K)

Nim

This

Attached: 14815498510040.jpg (416x287, 24K)

>strings not being a primitive data type
what's wrong with this?

Thanks user.

Thanks user.

>lazy evaluation
>bad
pick one

Lazy evaluation is shit for predictable performance. It can be useful but it's also easy to make it an on demand feature in strict languages.