Functional Programming

I've heard great things about functional programming. How can I dive into it?

I personally started with Lisp and it's what I advise others do as well. The parenthesis-oriented syntax helps put you in the "this thing is evaluated to this other thing which is then used in a larger expression" mindset that is IMO the most important part of FP. Just know that Lisp's not a pure functional language, because it has mutable data and side-effects. If you want to delve into pure FP, you should also learn Haskell.

My recommendation would be to use http://racket-lang.org, its big but practical and if you stick to the beginners stuff it should teach you a lot.

I've just finished Land of Lisp, pretty cool book have a look at it Op.

>lisp It's good and all, but the ML syntax is I think easier on the eyes and makes things more transparent. OP should at least have a look at it. The category theoretical discourse it employs is fun and illuminating. And of course Haskell would be a good choice, but OCaML is very gud too

If you already use a general-purpose language like javascript, python, c++, or java, it might be good to start by seeing how you can use functional programming there.

I kinda dived into it nit knowing about it. I happen to structure my procedural C code in a way that reassembles stuff done in functional like passing state as parameter. For example configuration parsed from flags is just a change of values of fields in a structure that is passed as parameter everywhere info on config is needed.

>>20592 Read SICP (SICP will teach you Scheme, a Lisp dialect) then look into SML (Sample Modeling Language https://smlfamily.github.io/sml97-defn.pdf) as >>20592 suggested. From there you can easily go into Haskell, OCaml, etc.

I was thinking of starting with Elixir. What do you think?

>>20643 Give it a try.

Nice to have a general for this op, thanks. I'm kind of dissatisfied with the functional programming offers right now. Lisp is great, but it's hard to distribute your programs as binaries like every other language. Haskell is incredibly beginner unfriendly and just beats you over the head for doing anything like other languages. The other languages has such a small userbase that there aren't many libs you can use or resources to learn them. Would love to be wrong about some of these things, I would especially want a Lisp that compiles to executables.

>>20660 >I would especially want a Lisp that compiles to executables. I know some schemes compile to binary, but the two I've given a quick try just now (gambit and chicken) require a library at runtime - there may well be a static option, I don't know. I do seem to recall that stalin could compile to completely stand-alone binaries, but it isn't as complete as the more mainstream implementations. For Common Lisp, the usual answer seems to be SBCL's sb-ext:save-lisp-and-die, which saves the whole image. It's not the lean kind of thing you usually have in mind when you ask for an executable, but of course the very way CL runs is different from C or Haskell (interactive / incremental development, error recovery etc.), so you can't expect an exact equivalent. >Haskell [...] beats you over the head for doing anything like other languages. I actually intend to main Haskell, but I recently figured OCaml might be a good alternative for those projects that have little deep logic but a lot of side-effecting housekeeping code. I was rather disappointed by the state of the language and the tools, but I think with some patience and more research it could be a pretty decent option - I intend to give it another try when I can build up the motivation. Specifically, my complaints about OCaml boil down to these two: one, never having had to write a makefile, I have this fantastic belief that, unless my project is particularly complex, I should be able to type compiler_command main_source_file and obtain a working binary. That ain't so with OCaml's tools, but it may with ocamlbuild, I don't know yet. Two, the standard library's a bit too comfortable with side-effecting, mutable code, and also too fond of exceptions, with option types (the equivalent of Haskell's Maybe) having been introduced as an alternative only in recent versions it seems - it's true that I wanted something less strict than Haskell, but damn, this goes a bit too far the other way. To add to the thread, I'm really interested in Elixir, but can't get into it because I don't have enough projects that it makes sense for. All that neat infrastructure for watching over and restarting threads is quite pointless for a silly script that renames some files or reads an RSS feed.

>>20663 Have you checked out Clojure? Compiles to JVM and looks pretty good. To me, it feels like a modern lisp.

>>20663 >I should be able to type compiler_command main_source_file and obtain a working binary. For a trivial enough script you can just 'ocamlc' to get it. But as soon as you use libraries, ocamlc doesn't know how to look them up unlike every other language, so it's easier to write a little dune file that names them. dune's really good, maybe enough you won't mind this too much. The OCaml standard library's deficient indeed in a lot of ways, which makes stuff like dune more important, because now even your most trivial scripts probably want to use something like Core or containers. >I'm really interested in Elixir, but can't get into it because I don't have enough projects that it makes sense for. same. this is the tragedy of Erlang. even for microservers it's easier to justify a single binary vs. an Erlang node and accompanying files that you have to check isn't accepting backdoor connections, etc. I think OCaml's due for a resurgence, as ocaml-multicore looks very thoughtfully designed, a nice escape maybe from impossible to understand async/await code in Rust. (I mean, it looks fine in tiny bits of client code, but for server code--hate). You can use ocaml-multicore right now with opam but still with an older version of ocamlc.

>>20663 >Specifically, my complaints about OCaml boil down to these two: one, never having had to write a makefile, I have this fantastic belief that, unless my project is particularly complex, I should be able to type compiler_command main_source_file and obtain a working binary. That ain't so with OCaml's tools, but it may with ocamlbuild, I don't know yet. You should really use dune as a build tool for ocaml. It's very straightforward and nice to use. > Two, the standard library's a bit too comfortable with side-effecting, mutable code, and also too fond of exceptions, with option types (the equivalent of Haskell's Maybe) having been introduced as an alternative only in recent versions it seems - it's true that I wanted something less strict than Haskell, but damn, this goes a bit too far the other way. Yes there never was much effort put on the standard lib (and that might be a reason ocaml didn't gain much traction). Maybe you can have a look at containers or stuff from janestreet.

>>20583 The traditional route to go would probably be Scheme via SICP -> Lisp -> Haskell, but I would recommend starting with Haskell right away. It's not that hard to pick up and it's a lot more useful than the Lisps imo. Learn You a Haskell for Great Good is an alright starting point, if you don't mind the childish presentation.

Learning Haskell is a lot easier if you have a domain in mind to apply it to using Haskell School of Expression/Music for example

Functional programming is for students and academics, not hackers

>>20919 What do you mean by hacker?

>>20919 >>20926 The Jargon File describes programming culture as it was from around the rise of UNIX to the fall of usenet. A lot has changed since then, and at this point it serves moreso as a time capsule than an accurate lexicon of IT culture. Case in point, when people say "hacker" nowadays, they usually mean someone who hacks into things. The older meaning isn't unheard-of, but comparatively it's very rare. Saging for off topic.

>>20919 Isn't richard stallman a hacker?

>>20919 Functional programming is actually really useful for parallel programming.

>>20964 >>20919 Functional programming is really usefull in itself. It is a much simpler and safer way to build programs than OO programming, because instead of putting (mutable) state everywhere in your program, and making it very difficult to reason with, you end up with clearly defined state, and clearly defined operations over it.

>>20919 https://tools.ietf.org/html/rfc1392 A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term. See also: cracker. Why? if you want to learn functional programming just because you want to learn more about computers. That makes you a hacker I guess >>20950 Yes. Why wouldn't he?

>>20933 Why should there only be one understood meaning for a word? When we say "Traverse a Tree" do we have to think of the same thing as a lawyer? Depending on who you're talking to, the usage of words can vary, there's no reason a place like this shouldn't understand "Hacker" to mean what people in communities like these have always used the word as.

I need project ideas to implement in F#.

>>21004 A dot net core implementation that doesn’t phone home to MS every time you open the REPL. Seriously, F# is great, but .NET is poison

>>21004 Write a Scheme interpreter.

>>21006 I run it on Mono but .net core and soon .net 5 are gonna kill it for good.

>>20583 1. Find a way of keeping brains alive after removing them from the heads of functional programmer gurus. 2. Remove the brains of functional programmer gurus and put them in a swimming pool. 3. Politely ask the functional programming gurus to start thinking about functional programming. 4. Dive into the swimming pool filled with the brains of functional programming gurus that are currently thinking about functional programming.

>>20583 Pick whatever language you most like the aesthetics of and study it, then go from there. Personally I like Haskell syntax haskell function :: (Num n) => n -> n function = (* 2) but all funclangs are generally really comfy syntax-wise anyways.

>>21025 5. realize that all languages are just a DSL of lisp 6. (( () )) )((( ( )()( ))) )) ( ()(( (( ((( ())( 6. .. / .- -- / -... . -.-. --- -- . / .-.. .. ... .--. 6. psil emoceb ma I

>>21060 >best language >worst compiler it's not fair

>>20583 Can any clojure user give me a quick run down on it? I've never used a functional programming before and I wish to use it for web development, possibly javaFX bindings for quick GUIs and system administration. I came across liquid text editor and it seems like such a nice idea. Are web dev libraries mature enough to rely on them effectively? I read that debian is working on packaging clojure packages as well and I'm sure glad to see it that's why I'm considering it. Tell me more!

>>21069 JDK/Javascript targets. It isn't really similar to other lisps, except in syntax. Honestly, not very good, or worth using.

>>21069 > for web try Elm

>>21069 >>21073 Clojure also has a problematic license which basically makes it impossible to write Free software with.

>>21076 How does Racket compare?

>>21079 Racket is a mix of MIT, LGPLv3 & Apache 2.0. In other words, pretty much entirely safe.

>>21076 You're such a fuarrrking retard, that is complete FUD and 100% wrong bullshit. You little fuarrrking twat, actually do some research before you open your fuarrrking gob. https://en.wikipedia.org/wiki/Eclipse_Public_License

>>21067 What's wrong with GHC?

>>21086 They're whining because it takes a relatively long time to compile. This is owed in part to the sheer abstractness of the language, requiring more cpu time to resolve. The compiler is actually very good, and produces excellent object code, but you're forced to wait for it to resolve what you intended.

>>21085 Why take a wee look here dumbass: https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses That's what I mean.

>>21088 code compiled by it isn't covered under the license. you're revealing your ignorance very well.

>>21088 code compiled by it isn't covered under the license.

>> 21089 >> 21090 Clojure library is included with Clojure projects you compile & build (or is otherwise required at "link time", though Java doesn't quite work that way), which means you have license incompatibility. Trying to make a GPL'd uberjar is instant license violation. The issue is not the compiler, it's the library.

>>21091 for >>21089 >>21090

>>21091 Clojure doesn't have car or cdr, why even bother?

>>21093 There is a legitimate argument that linear linked lists aren't the ideal datastructure for parallel computation. https://vimeo.com/6624203 goes Note that there's no reason it cannot be added/done in Common Lisp, it just would lead to currently not particularly idiomatic code that seems too complicated at first glance for what it does. If you wanted to keep the same appearance to your code, you'd simply need to add a few more methods to generic-cl (for example) so that you can keep the same syntax you're used to. I would question how good of an idea deliberately hiding that you're using a different type of computation would be. Clojure could very-well have taken the form of a Common Lisp library and a few contributions to ABCL, and I'm not quite sure why it wasn't done that way.

>>21085 >>21088 >>21085 If you're both going to be rude then you should leave. > Always argue in good faith and avoid using personal attacks. > You should always elaborate on your opinions rather than just spilling the soykaf. > Don't respond with aggression

>>21088 >The following licenses are free software licenses, but are not compatible with the GNU GPL.

>>21069 It's probably the least Lisp-y language in the Lisp family, but it's also the most functional one.

Thoughts on Idris?

>>21087 One complaint I've seen leveled against strongly typed FP languages is that the compilers are, by necessity, all quite huge and complex. You'd never see something like mini-c being done with Haskell. What do you all think about that? >>21109 I haven't tried it yet, but the type system does look really cool.

>>21106 That is a valid point, I suppose.

>>21110 >by necessity > You'd never see something like mini-c being done with Haskell GCC and clang are huge too. But if you want a small implementation look at the interpreter Hugs. You could easily make a small compiler by adding some code generation and simple optimisations. Hugs on my system is 661 KB.

>>21109 It's soykaf. Don't mess with Idris and Haskell.

What's a good example of high quality, production level haskell code? >>21197 What makes you say that?

Anyone have any experience with functional programming in C++? Seems nice to be able to use all the C/C++ libs, but the language is so fuarrrking ugly.

>>21432 C and C++ have practicality no support for nested functions, which are very nessesary for FP. It's a shame, because I feel like a functional version of C would be fantastic.

>>21441 We have -fblocks when using clang/llvm, i think its was first developed by Apple Inc, its possible to used some extensions in GCC to allow nested functions and blocks... btw nothing which is really portable.. but its worth to take a look. >links https://en.wikipedia.org/wiki/Blocks_%28C_language_extension%29 https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html https://clang.llvm.org/docs/BlockLanguageSpec.html

>>21432 Try F# PInvoke

Any thoughts on F# 5? https://devblogs.microsoft.com/dotnet/announcing-f-5/

>>21441 >C and C++ have practicality no support for nested functions, which are very nessesary for FP. No, they are just sugar.

>>22180 They are sugar in like if-then statements are sugar for gotos.

>>21441 >nested functions You mean like C++ lambdas?

>>21441 >>22180 >>22185 I've found that lambdas and std::function are usually good enough to make up for lack of proper nested functions in C++, but it would be nice to have them. There's also structs with static member functions, which can be made to do kind of similar things.

>>22186 I'm pretty sure that by default, C++ doesn't have the sort of nested functions I'm thinking of, where you can declare a function withing a function and then more functions within those functions.

>>22188 >C++ doesn't have the sort of nested functions I'm thinking of It does, but it's a bit complicated. https://en.cppreference.com/w/cpp/utility/functional So while this won't work: C++ int outerFn() { int i = 0; int innerFn() { return i; } return innerFn(); } you can instead do C++ int outerFn() { int i = 0; auto innerFn = [&] () { return i; } return innerFn(); } which does the same thing. Languages that let you nest functions are actually doing basically what C++ is doing in that second example, it's just that the syntax is simpler because that's the only kind of function they have. C++ just happens to have another kind of function that can't be nested (the older kind that it inherited from C). So really it's a proper superset of the features you're talking about.

>>22189 Are these functions first class? Could innerFn be returned as a value from outerFn? I know in C you can return function pointers, but I'm not sure how that plays with scoping here.

>>22208 >Could innerFn be returned as a value from outerFn? yes, although you have to be careful about variables going out of scope. the example i posted captures the scope by reference.

>>22208 >Are these functions first class? They're function objects, instantiations of classes with a function call operator. They can be easily converted to function pointers if they don't capture anything. They don't have a type you can name, but you can assign them to std::function (type-erased wrapper) to treat them uniformly. Not sure if that's "first class" enough for you. >Could innerFn be returned as a value from outerFn? Yes, but make sure to capture i by copy. C++ auto outerFn() { int i = 0; auto innerFn = [=] () { return i; } return innerFn; }

>>22237 >They don't have a type you can name I thought they did in C++? Like can't you define a variable of type "function which accepts one integer argument and returns a boolean"? People almost universally just use auto for these but I always assumed that's what auto actually resolves to.

>>22238 >Like can't you define a variable of type "function which accepts one integer argument and returns a boolean" You can with the std::function wrapper, but the real type of lambda kind of has to be anonymous because even if the call signature is the same for two lambdas, the captured variables may be completely different, so the fields of the underlying function object would also be different. C++ #include <functional> int main() { int a = 0, b = 1; auto f1 = [a](int c){ return a + c; }; /* f1 equivalent to struct F1 { int operator()(int c) const { return a + c; } int a; }; auto f1 = F1{a}; */ auto f2 = [a, &b](int c) mutable { return (a + b++) * c; }; /* f2 equivalent to struct F2 { int operator()(int c) { return (a + b++) * c; } int a, b; }; auto f2 = F2{a, b}; */ // you can assign both f1 and f2 to a std::function of the same type std::function<int(int)> f3 = f1; f3 = [](int c){ return c; }; f3 = f2; // you can get a function pointer from a capture-less lambda auto f4 = +[](int d, int e){ return d * e; }; return f1(4) + f4(f2(54), f3(888)); }

>>22241 Small correction: in f2, b is captured by reference, so the fields of F2 would be int a; int& b; .

>>22241 I see, thanks for the explanation.

>>22241 That explains a lot. Thanks!

I wonder how viable a functional C would be. I feel like FP would alleviate a lot of the trickiness of working with C, but I've heard that there's certain things that functional languages can only do with at least some degree of garbage collection, which could potentially compromise C's low-level performance.

>>22471 C++11 has lambdas and other FP features.

>>22480 How functional can you get with it? With >>22471, I'm thinking of something along the lines of Scheme or Ocaml, where you can have huge chunks of code that are just passing the results of functions around to other functions, rather than creating or mutating data like you typically see in C code.

>>22471 This is something that might change in the future with affine types or linear types. See Rust for exemple. Linear haskell , Idris2 , granule all have linearity. But we don't know yet if it could be use to suppress the GC. IIt's believed for now that only the affine types can do it.

I feel there is missing a language in the functional programming space. Haskell is thought to be this state of the art language which all others should be compared against, but I really hate the tooling and it feels pretty bloated. What I'm looking for is basically the C of functional programming, a language that is minimal, but very capable nonetheless. Haskell is great on paper: static, strong types is for example great. Scheme looks very minimal, but it's lacking because of the dynamic type system and many different implementations. Racket seems nice, but again, static types are needed for larger scale applications.

>>23805 I think most of haskell's bloat is for performance reasons other than the ones that are just syntactic sugar. I'm not too familiar with the language but I think that's the motivation behind implementing so much.

>>23805 OCaML Unfortunately, to be the C of FP would mean an entire family of OSes to be written in it.

>>23805 Standard ML is the king of functional programming language.

>>23805 Might I suggest Guile Scheme. It's purpose built to be plugged into existing C programs as a scripting language. You bind C functions into the interpreter and call them from Scheme. You can even leave a shell for yourself to interact directly with the Guile interpreter at runtime which is really great for testing. The dynamic typing shouldn't become a pain point because if you're working carefully Guile should be interacting with lists and symbols pretty much exclusively and is only going to be touching data where you already have assurances from the host code's static typing.

>>23809 >>23812 from what I've read, Ocaml looks like Haskell, but like it hasn't fully embraced functional programming. Most people also seem to recommend Haskell over it. Is there any truth to this? >>23813 looks pretty comfy, but it doesn't look like it can stand on it's own. I want to work with functional codebases, not be chained to legacy C-code.

>>23805 I haven't used it but, you know, there is more than one language to Racket, and some are statically typed. You might want to check out Typed Racket [1] or Plait [2]. Browse around the docs [3] for more languages. [1] https://docs.racket-lang.org/ts-guide/index.html [2] https://docs.racket-lang.org/plait/index.html [3] https://docs.racket-lang.org/ >>23817 From a superficial look at it, I'd say that OCaml not only allows mutability, but at times even pushes you toward it. It is also my impression, however, that is moving in the right direction, correcting some of its flaws and bringing some interesting new features to the table.

>>23817 >>23822 FP's interesting in that it just kind of gradually occurred, as opposed to other paradigms like OOP and structured programming, which more or less emerged in their current form right from the start. As a result, a lot of the older functional languages are a lot less functional than newer ones. Most Lisp's and ML-likes are just as imperative as they are functional. Trying to build an entire language around FP didn't become common until fairly recently.

>>23837 SASL(1972), KRC(1981), Miranda(1985), Clean(1987) Haskell(1990) and SAC(1994) are all purely functional programming languages. ML is from 1973, one year after SASL, so I don't get your point of "older functional languages are a lot less functional than newer ones". A lot of FP languages had different focus, being purely functional language was not what all of them wanted. That had nothing to do with it being old or new language.

>>23839 >ML is from 1973, one year after SASL, so I don't get your point of "older functional languages are a lot less functional than newer ones". More to the point OCaml started in 1996 after every pure language you listed. OCaml has some interesting features like GADTs (and existential types), an Object System, and ML-style Modules. These features are implemented (conservatively) in the base language which is unstandardized unlike as is often the case in Haskell. This has the advantage of preventing a tsunami of complex LANGUAGE pragmas which need to be learned separately from the base language, but the disadvantage that you can't just sit down and read Haskell 2010 to gain an understanding of the base language. Multicore OCaml will be introducing parallelism into the compiler, along with effect handlers. I tried to do some type-level programming stuff in OCaml some time ago but ran into some difficulties with the lack of type classes, the module system doesn't seem as boilerplate free for this sort of thing. I could have just been being a fool however, I've not use OCaml in quite some time and never learned it fully. Regarding mutation I think both OCaml and Haskell are interested in making referentially transparent interfaces, but it does seem that OCaml is more willing to use imperative programming in implementation if this results in greater efficiency.

In Functional Programming. Functions are first-class. When you say a function is first-class, it means you can operate on a function, pass a function as if it were data. What's the benefit of that? You can compose functions so that you don't have to rewrite soykaf and it's more general than using an interface because you can just describe the function you're gonna pass (in a statically typed language), or just invoke with some parameters in a language like JS. Also you can do functional programming in JS, it won't be pretty but you'll reap the benefits of it while being sane and keeping with the real world rather than using some unicorn language like Haskell. You can also learn Emacs Lisp to do FP, especially if you're using Emacs, it makes the experience way better than if you're just using Emacs as an editor because you can customzie your emacs to your aesthetic and ergonomics.

>>24195 >you can operate on a function, pass a function as if it were data does this mean functional programming languages have to be interpreted or jit'd in order to have this feature? or is it still possible for it to be compiled? if you pass around and substitute functions and code at compile time can you get the same result or are you still missing something? related to all this - is it fair to say that functional programming is about metaprogramming using functions?

>>24198 I'm pretty sure you're thinking of modifying a function at runtime, which indeed would require retaining the function's code or something equivalent. That ability is not a requisite of functional programming - only being able to store a function and pass it around as other (constant) data is required. Being able to modify a funcion is a rare feature - interpreted languages don't usually allow it, either. It's more common among dynamic-scope languages, like newLisp[1], and it allows for some unusual programming patterns, like Kazimir Majorinc's Crawler Tractor[2]: a function that repeatedly runs a piece of code without using loops or recursion. [1] http://www.newlisp.org/ [2] https://kazimirmajorinc.com/Documents/Crawler-tractor/index.html

>>24198 Metaprogramming in functional languages is most commonly enabled by homoiconicity. In homoiconic languages there is no type difference between the data you work with and the code you run. To make that useful, you need to be able to pass functions you generate around and apply them as though they are first class (yes, that does mean you need an interpreter or JIT compiler). Not all functional languages are homoiconic or even well suited to metaprogramming. Functional programming is set apart from other paradigms you might be familiar with by the fact that it is understood best in terms of description rather than instruction.

>>24198 SBCL and other implementations are capable of compiling lambdas and functions fine. Modifying functions on the fly would require a more complex boxing, as >>24217 suggests.

>>20664 Clojure is awful. It's not even a lisp. The Java interop is everywhere, and it is extremely slow. Common Lisp is the most powerful dialect, because it respects the first rule of Lisp: "everything should be dynamic" The only reason languages like Clojure exists is because the CL standard was released in 1994, which makes it an "old" programming language.

Any one here using idris ? The version 2 is pretty nice

I figure this is the best thread to ask in. Does anyone have recommendations for getting into theoretical CS and PL theory? I've come out of university not having studied much in these areas and only have a dilettante's knowledge of FP.

>>25911 I do not, however I find dependent types quite interesting. I have been meaning to read The Little Typer to get a firm grip on their functionality.

>>24239 I started lisping around in Clojure, and recently started CLing. I kinda see where you are comming from, but I do not believe you stated raison d'être for Clojure is correct. Clojure exists because you can say you are just using a Java library and your manager will ask no questions. If you were to say you were doing X in CL, all hell would break loose. Been there, done that. I shared the story on lisp general, but when people figured out Clojure was "lispy," things were not pretty. I mean Rich Hickey clearly stated that if he were allowed to use CL in his projects, he would not have invented Clojure. I would not say Clojure is awful either. It definitely has a less polished developer experience than CL, but I think it has it's strengths: - Interop with both Java and JS. In my current project, it makes lots of sense using a given JS library. I am definitely not going to use JS, so ClojureScript is going to happen. - Friendly community. That is its main advantage over something like CL. But yeah, I would agree on CL being the superior dialect. >>20583 And since were are on the Clojure topic, this [0] was one of my favorite resources for learning both Clojure and FP. I even rehashed most of the exercises to python when I had to teach FP at work. That is how high I think of those exercises. As lain stated, SICP is great, but it will take significantly longer to work through. You will also get a lot more out of it. [0] https://moocfi.github.io/courses/2014/clojure/

Is there any benefit to using FP for machine learning or networking over imperative languages?

Thoughts on Hy? I like the idea of having access to the Python ecosystem via a Lisp, but it seems like there's basically no books, no IDEs/Plugins and no community for it.

>>26396 Same as any other field. As far as machine learning is concerned, you are most likely just going to be cleaning data and calling a given API for a model. For data cleaninig, I would say FP is fine, you just define your processes as a series of functions and pass your data through all of them. Since you have had no side effects, you can recall your data at any point of the process and do your debugging and what not. In the rare case you are going to be doing more mathy stuff: FP is more affine to math, but again, you are likely to just mess with data a bit, and call whatever BLAS/LAPACK routine you need >>26397 I played with it a couple of years ago. It was rather unfinished and just felt like a better syntax for python. I have had no use for it since.

>>26396 >FP for machine learning it depends, probably not. tl;dr in the extreme low-level case, the efficiency of imperative programming is essential, and yet in the extreme high-level case it hardly matters what "paradigm" you use because the problem has ceased to be a matter of programming per se... ... there's a big difference nowadays between "low-level" ML where you implement the algorithm yourself and "high-level" ML where you (typically) call an API function using a python library. in the latter case, it's barely a real form of programming in the traditional SICP sense--in the sense of building generic units of computation and composing them into more complex systems; the system in this case is already at its maximum point of structural complexity and your only task is to find the right combination of hyperparameters/training for the model to use. The vast majority of "ML" is high-level nowadays, just by the way. I've implemented algorithms from scratch to better understand them, but never out of necessity. Sort of like with sec stuff, rolling your own is a "bad idea"

>>26396 >>26398 >For data cleaninig, I would say FP is fine, you just define your processes as a series of functions and pass your data through all of them. Since you have had no side effects, you can recall your data at any point of the process and do your debugging and what not. forgot to mention this. the cleaning stage is where functional programming principles really do shine (techniques like Makefiles would as well). it can also be compartmentalized fairly easily, so that even if you're stuck using python for the model training, you could still use some other language for building the datasets. however, perhaps sadly, I think in the end python is still the best choice for every step just because of the maturity of its tooling. but let me know when Idris has something like the ipython shell.

>>26402 Isn't ipython shell really bad? At least if the argument lies on proper interactability, a language like Common Lisp would serve that use case a lot better. As for Idris, Idris does ship with a repl, this is how you often check code, search for proofs, and throw terms around.

>>26470 >Isn't ipython shell really bad? compared to what? does the Idris shell automatically repatch all the objects in memory whenever you change a source file (including class instances)? and does the debugger also do this? that's the kind of stuff that ipython is good for at least. you rarely have to "run" your program multiple times while testing it, since all interaction is live and in-memory.

>>26471 P.S. i'm aware LISP has already been doing all that and more since the 70s. I don't think CL or any other lisp would be very practical for datascience, though because (1) the field is heavily reliant upon libraries that aren't feasible to reimplement yourself and (2) it's very "social", and people want an agreed-upon syntax and somewhat universal structure to things. Python is pretty good at these two things. not sure if any Lisp is. I guess what I'm saying is, there's plenty of roles that are better filled by a mediocre person who sticks to common sense than by a genius who sees the optimal approach and can't bear to compromise anything for its sake.

Hope this is the right thread. I feel like I have a big knowledge gap, I don't understand at all what people mean when they talk about a language having a "powerful" type system. How does a language's type system supposedly affect how programs are written and designed? I've heard this about haskell, ocaml, idris and probably others. I just can't imagine what it mean. Is there anything I need to read or see to become enlightened? A book or a PDF that would make me "get it"? I know C, python and some rust and scheme.

>>26646 >>26646 Use mypy or typescript. The "powerful" ness is kinda nonsensical, but basically it means you can write terser and nicer code when you know what you're writing. Learning kotlin was my first view at how powerful a type system could be, because I wrote something once, very quickly, and just googling all of the red squiggly lines. What took me about a week or in Java, I could smash out (not same project but similarly sized) - could smash out in about a weekend

>>26646 As I see it conceptually, type systems serve essentially to verify programs against a specific set of rules ("types"); more expressive type systems in languages such as Haskell allow you to model certain characteristics of your problem at the type level (even things like error conditions and branching and beyond), which tends to allow you to write terser and more concise code (partly because such systems tend to be designed with composability in mind, and because you don't have to worry about safeguarding against logical errors or certain conditions because you've either made then unrepresentable or made handling then (in case they're inevitable) a lot more concise) than a language with a more "primitive" type system. They're a system for encoding and verifying properties, and you just use them for what they're made for.

>>26646 I had an 'aha!' moment watching Effective ML, a talk on OCaml available at https://www.youtube.com/embed/-J8YyfrSwTk . The juiciest bit for me starts at 18:00, when algebraic datatypes are used to make certain invalid program states simply impossible. That's a powerful type system to me: one that allows me to express some complex properties about my problem, so that the compiler will only ever generate code that respects them. I can upload the talk somewhere (150MB), if someone has a broken version of youtube-dl or simply doesn't want to send requests to Google.

>>26659 finally watched this, thanks lainon! I think I get it a little now.

I'm considering using Ocaml for a new project and I have some questions. 1. How is the Ocaml macro system? Does it allow for the manipulation of the AST like, say, Elixir? Is it well suited for building a DSL? 2. I want to have an idea of what I'm getting into. What are some general complains you have about Ocaml? I saw an lainon mentioning that the build system is not as powerful as that of some modern languages. For example, there is no equivalent of `go build` and `cargo build`. Please don't rant about how I should study the language for months and find the answers for myself. Trivia: The lumps on the back of camels and dromedaries is actually fat, not water storage. The camel in the picture is not hurt, that's a normal thing they do attract females.

>>26940 I'm only a newbie, having written under 1000 lines total, but I can tell you something about what lies ahead. >2. I want to have an idea of what I'm getting into. What are some general complains you have about Ocaml? I saw an lainon mentioning that the build system is not as powerful as that of some modern languages. For example, there is no equivalent of `go build` and `cargo build`. Yes, I was in that conversation, and I can now confirm that the built-in build system is terribly cumbersome. The thing you have to realize is that OCaml has no 'include/import' statement: in your code, you go ahead and use the names of any libraries you want, with no ceremony; then someone has to remember to tell the compiler to load those libraries so that your code will compile, because there is no hint at all in your code that those names are supposed to be found in a different file. For very simple projects, you can use ocamlc / ocamlopt and pass as arguments the names of libraries you want to include (in the correct order). For something more complex or if you're using non-stdlib libraries, ocamlfind is a hack but works very well. The other option, as said above, is the build tool dune. Dune just works and is stupidly easy to get up and working with, but there are only two ways to use it: either you accept all its default behaviour (and I can't, because it gives binaries a .exe extension even under GNU/Linux), or you spend more time learning dune than learning OCaml. Another gripe: documentation is scarce, although not lacking. The language manual holds your hand for a while, then lets you go without warning. The stdlib manual can sometimes be frustratingly terse, but once you can read ML function definitions fluently you can always find the information that you need. A companion book can help a lot, I've been using Practical OCaml for that. And finally, about the language itself: my impression is that sometimes you have to work for it if you want to reap the benefits of functional programming. Especially when dealing with dirty things, like network communication, the language makes it all too tempting to fall into imperative idioms. I suggest that you consider Haskell, especially if you're picking OCaml over it for fear of its pure functional style. Go on to the Haskell page at Rosetta Code, pick a task that sounds very side-effecty and imperative-friendly, and see how it's done. It may swing you over to Haskell, or it may teach you to write better OCaml; it's a win either way.

>>26950 I will check dune, thanks. >Dune just works and is stupidly easy to get up and working with, but there are only two ways to use it: either you accept all its default behaviour (and I can't, because it gives binaries a .exe extension even under GNU/Linux), or you spend more time learning dune than learning OCaml. Why is that a problem? Just remove the .exe. >I suggest that you consider Haskell, especially if you're picking OCaml over it for fear of its pure functional style. I don't think Haskell is fit for what I want, I not Ocaml then it will be Rust. Thanks for your input and shame I might not be able to use Ocaml.

>>26951 >Why is that a problem? It disgusts me, quite simply. >Just remove the .exe. Every time, yes. I could've written a wrapper script, but in my experience, if a tool and I are not a good fit for each other, everyone's better off if I pick some other tool instead. Glad to hear, though, that my personal dislike did not put you off dune altogether. >if not Ocaml then it will be Rust. Make that OCaml then if you want to do functional programming. In my extremely shallow experience with Rust, imperative programming proved to be unavoidable for certain tasks. With OCaml, at least, wherever the stdlib is too imperative, Batteries usually provides a more functional alternative.

What functional languages have good cross platform support? I'm developing something that should work on desktop+mobile. It seems like the best options are Rust, which is kinda unnecessarily low level, and F#, which feels like an arranged marriage with Microsoft. OCaml cross platform support is almost there but not quite, specifically I would need to use ReasonML to target Android and I would rather just use normal OCaml. In fact this seems like a repeating pattern, Haskell also has weak support for mobile. I would like to avoid electron/cordova/node.

>>26960 Purescript and react native will get you there. There's no avoiding node. There are essentially no ways to build functional soykaf that goes straight to the metal in android at least. With PS you can write once and run it on web and native, can do the back end in Haskell too if you're capable. Also, how come the little dealybopper says my post looks automated?

Haskell: How applicable are proofs and algebra in the day to day usage? Is there a lot of material to study the relationship between the language and higher level mathematics? Recommendations are welcome.

What are some other nice functional programming communities? /g/ is soykafty and the functional programming general is rarely up anyways.

>>26960 Clojure runs on the JVM and as such supports everything that supports Java.

>>27183 JVM doesn't run on iOS and even if it can compile to native code I'm guessing it won't have all the libraries available.

>>27309 >>27183 Oh and I prefer statically typed, forgot to mention it.

Is there any actually good functional programming lang for backend? The only one that seems to be polished is JS for Node.

>>28654 I've heard good things about clojure but I know next to nothing about it

>>28654 Elixir is great. It uses the actor model, interops with Erlang, has syntactic macros and ruby like syntax. Phoenix is the go to web framework but honestly you can do a lot with just OTP (the standard library).

I just finished my year's end programming project, in OCaml. One of my goals for the year was to become fluent in an ML, and although not quite there, I think I'm reaching the end of the beginner phase. I'm slowly picking up more sophisticated ways to take advantage of the type system and pattern matching - and all in all I'm starting to feel at home in the language. I'm approaching that point that veterans speak of where, after you get rid of the type errors, few bugs remain in the program - and I'm learning to spot the places where they can hide. For example, I dread functions that take several arguments of the same type, because I know that the type checker can't catch my mistakes when calling them. If it doesn't make sense to create separate types for the arguments, what I do is label them with explicit names. As for my project, it's an interpreter for a very rudimentary programming language that I've come up with, intended foremost to be pleasant to use as a desktop calculator. It's amazing how easy writing an interpreter turns out to be when you understand the fundamentals (making an AST, eval/apply), and it's a lot of fun to spot the places in your code that affect the language's semantics (checking function arity, typing discipline, lexical/dynamic scope). This all was arcane sorcery for me not long ago, yet I managed to put it all together quite easily based on ideas I picked up from SICP, Programming Languages: Application and Interpretation [1], [2] and Understanding Computation (>>28163). The progress is real, lains! Keep at it! [1] https://www.plai.org/ [2] https://cs.brown.edu/courses/cs173/2012/book/

>>29268 Post link inside brackets too much to ask? Fair, then: >>28163