Functional Programming: This thread is like a burrito

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Functional Programming: This thread is like a burrito

tazjin: Jul 24, 2015

GrumpyDoctor posted:

There's no way around hardcoding an explicit mapping for each Enum value somewhere.

Strictly speaking in this case he could change the constructor names to the full weekday names and derive Show.

Also unless explicitly forbidden by the task you're doing you should probably use the time library for time&date stuff.

# ¿ Sep 17, 2015 19:48

Adbot: ADBOT LOVES YOU

# ¿ May 1, 2024 15:53

tazjin: Jul 24, 2015

Snak posted:

Wow. Thanks for all the feedback. It was a really simple, basic assignment to demonstrate we knew how to make basic Haskell functions. I was only confused because I don't have a feel for "the Haskell way" and I was bringing a bunch of C baggage along for the ride.

Generally when you come across an explanation for concepts in Haskell and read sentences like "this is comparable to an enum in C", don't take them too seriously and don't make the assumption things will work the same way.

# ¿ Sep 17, 2015 20:56

tazjin: Jul 24, 2015

VikingofRock posted:

Is there an up-to-date tutorial on regexes in Haskell? It seems like every tutorial is out-of-date, and the documentation on Hackage is fairly lacking.

Usually when you're not sure whether a library on Hackage is still "current" you can check whether the same library is available on Stackage, which is a stable set of Haskell packages that requires them to be maintained.

From there we can find for example regex-compat, which seems to have a fairly simple interface. Consider the types of the functions as the documentation and view it a bit like a "type-puzzle" you are putting together. Example:

code:

-- Puzzle pieces:

-- We have a regular expression as a simple string
expression :: String

-- We have some text and want to find matches to the regular expression above 
stringToMatch :: String

-- The result we expect is a list of strings or something similar
expectedResult :: [String]

With the puzzle pieces we check out the documentation of the package and see if we find matching types:

code:

-- From Text.Regex in regex-compat:

-- A compiled regular expression.
data Regex

-- Now we know there is a type for compiled regular expressions, good!
-- How do we get there from our expression as a string?
-- We know we have a String, we want a Regex, and bingo:
mkRegex :: String -> Regex

-- Great, now we want something from our Regex and string to match (String) to some kind of [String], i.e. the result we want.
-- Back to the docs and we find:
matchRegex :: Regex -> String -> Maybe [String]

-- That looks like exactly what we're looking for! Now we just need to put the puzzle pieces together,
-- which is simple given the types above.

# ¿ Nov 28, 2015 02:28

tazjin: Jul 24, 2015

Athas posted:

Well, it does, but as you said yourself: Erlang lends itself to a programming model where you spawn thousands (or millions) of processes. On a modern multicore processor, you need maybe 32 processes to exploit the hardware, and more just means overhead. Even with Erlangs lightweight threads you end up "simulating" all this parallelism that you don't really need. And on a cluster, performance depends on efficient communication patterns and locality, which Erlang doesn't really expose in a useful way (any process may send a message to any other process). Message passing is presently the only efficient way to program clusters, though.

Efficient parallelism is all about limiting communication and ensuring that the granularity of parallelisation isn't smaller than it has to be.

Erlang processes are not just about resource utilisation and they don't map to physical threads. A large part of it is simplifying the programming model, doing away with global state and, of course, fault tolerance.

Asymmetrikon posted:

I've seen a lot of people online doing an Elixir backend and an Elm frontend, and it seems like it works pretty well. Plus, you learn about two wholly different styles of functional programming (impure, dynamic typed, concurrent vs. pure, static typed, non-concurrent.)

I second this. Elixir specifically is a very approachable language (Elm maybe a little less so), but the combination has been a very effective tool for lifting programmers out of the dark pit filled with Javascript and Ruby.

# ¿ Apr 27, 2016 17:07

tazjin: Jul 24, 2015

Arcsech posted:

Elm is by far the most approachable purely functional language, and arguably one of the more approachable languages in general because the compiler errors are really, really good, which sounds silly, but given how much of learning new programming concepts is changing things and seeing what works, having the compiler explain very clearly why some things won't work and give suggestions on how to fix it is super helpful for learning.

The compiler errors are indeed fantastic and I hope the GHC crew takes some inspiration for that, but specifically when it comes to web development Elm introduces several radically different concepts at the same time and it's often too much for people.
Keep in mind that frontend developers often have a background in untyped, imperative languages with no formal design - quite literally the opposite of Elm.

For those coming from a functional language the situation looks a lot different

# ¿ Apr 28, 2016 00:26

Adbot: ADBOT LOVES YOU

# ¿ May 1, 2024 15:53

tazjin: Jul 24, 2015

Pollyanna posted:

So I hear a lot about Lisp's extensibility and metaprogramming capabilities, and how it's good for defining a problem in a language that maps directly to said problem domain. People talk about domain-specific languages and macros and bottom-up programming and "changing the language to suit the problem" which makes it seem a lot more like dark-arts wizardry than a programming language.

I don't really understand what this all means, and how it makes Lisp so powerful/versatile. I get the concept of domain specific languages, even if I have no idea how to make one or what makes a good DSL good, and I understand that homoiconicity means that everything is just data, including code. But I can't seem to connect those concepts to understanding and writing code that maps directly from problem domain to implementation.

It feels like there's supposed to be an aha-moment with Lisp that I haven't had yet, and I don't know what I'm missing. What am I looking for, and how do Lisp's killer features matter in programming it well?

For me the lisp aha-moment happened when I started using structural editing for it (paredit in emacs), that's when I realised how the syntax and everything is just superficial and that data is code and how the universe really works.

I went to find more information and was finally enlightened by this article about the nature of lisp.

# ¿ May 19, 2016 01:01

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Functional Programming: This thread is like a burrito