functional programming is mount stupid

a well designed language needs to do 2 things: - maximize hardware utilization (performance) - make the programmer's work easier (productivity) the core assumptions behind functional programming make it much worse at these 2 metrics. for example the assumption that always immutable is a good thing - it makes it hard for the programmer to express even trivial things (productivity) and harder for the compiler to optimize the code (performance). therefore at a fundamental level functional programming is a really bad design, and that's reflected by nobody using it in the real world.

well, when it comes to functional programming, isn't threading much easier to handle? doesn't that mean that you can utilize more hardware performance with ease? just a thought >for example the assumption that always immutable is a good thing - it makes it hard for the programmer to express even trivial things did you start with imperative programming first? that would explain it. i get it, it's weird and you might be more used to imperative style, that doesn't mean that it's less productive. that's very subjective point of view >harder for the compiler to optimize the code maybe, but what about ghc? >therefore at a fundamental level functional programming is a really bad design, and that's reflected by nobody using it in the real world. no. are you trying to convince people that nobody is using clojure or scala? even haskell is used by companies like facebook.

The core assumptions of your argument rest on everyone else's experience of FP being the same as yours. That you think you have trouble expressing things in immutable terms doesn't actually mean that it's more difficult. In reality you probably have expressed things in precisely the same way a functional programming language would force you to. For something which is "at a fundamental level really bad design" modern languages sure do take a lot of queues from FP. First-class functions and lambda , internal/external iteration, macro systems and even assumed immutability have all been rolled out as updates to major industry languages in the past decade as though they're brand new revelations rather than things present since the 1960s in the most basic implementations of LISP.

FP allows you to better isolate different parts of your program so you don't have mutations all over the place. You might say: just design it better. Well you can't predict all the changing requirements over time.

the fuarrrk are you on about OP, haskell is easier to write efficient bug-free code with than C.

Considering that pretty much every programming language nowadays has added most concepts from FP I'd say you're wrong. I understand it seems frustrating at first if you're used to imperative programming but trust me, it gets better to the point that many things will become more natural to do in FP than classic imperative programming. I'll concede (partly) one of your points though: I know that doing stuff the functional way in some languages can actually cause performance issues. As an example I know that python does not support tail call recursion, so you might hit the recursion limit way too easily.

>>28660 > - maximize hardware utilization (performance) > - make the programmer's work easier (productivity) hewwo OP, just leaving this here for you: https://chrispenner.ca/posts/wc

>>28661 >isn't threading much easier to handle? the sole purpose of threading is to speed things up and by making copies of everything you slow things down, which defeats the purpose. performance wise usually you're better off syncing access instead of making copies. also most of you guys are parroting excuses you were thought. FP isn't simpler, it isn't a matter of what you learn first, and reality isn't on your side. few academics are not the real world. u can check tiobe index or similar measures and get an estimate for usage. haskell is at 0.2% and even that's too much imo. >>28662 >everyone else's experience of FP being the same as yours. That you think you have trouble expressing things in immutable terms doesn't actually mean that it's more difficult. >everyone having trouble expressing >not more difficult you're literally contradicting yourself 1 sentence apart. additionally you're missing the point, if there's an easier way to express it's better, and there is thus FP is worse. and if these features are used by non-FP langs then they aren't part of what defines FP, thus not what im arguing against. perhaps i should be more specific and say im critical of always immutable, always pure function, and generally stuff that constrain the programmer in artifical ways and prevent simplicity. >>28663 >FP allows you to better isolate different parts of your program so does every mainstream language. >>28665 >haskell is easier to write efficient bug-free code with than C. >than C. it's very easy to beat C in safety since it's outdated and almost got no safety features, except adding const in C99 or something.

>>28660 >maximize hardware utilization (performance) 90% of cases there is no reason for that >make the programmer's work easier (productivity) FP langs are not python in this regard but at least they are writable unlike C++ or rust, especially if you have experience. >carefully forgetting the fact that bugs exist and can cause real detriments unlike having to wait 3sec or not being able to work with 14yo coders Predictable

>>28670 >the sole purpose of threading is to speed things up and by making copies of everything you slow things down, which defeats the purpose. performance wise usually you're better off syncing access instead of making copies. Even if you get little performance hit, it's worth it because you know for sure that nothing will interfere with your threads. It's also not really true that you are copying everything, for example GHC does many optimizations and lot of data are never really allocated to heap, but stays in registers. >you're literally contradicting yourself 1 sentence apart. >>The core assumptions of YOUR argument >so does every mainstream language. not true when it comes to mutations but it seems the you already made your mind about it, do you really want to have conversation about fp or are you just venting your feelings? >it's very easy to beat C in safety it's very easy to beat any language in safety with Haskell

>>28670 >you're literally contradicting yourself 1 sentence apart. No, you're misquoting me. The point I was trying to get across is that you only believe that you have trouble expressing things in a purely functional way. In reality if you've used a modern language you have written at least some code which is entirely compatible with assumed immutability and purity constraints and that was the cleanest way to do it. >if these features are used by non-FP langs then they aren't part of what defines FP If that's the standard then FP is nothing. First class functions? That's everywhere, even in Javascript where everything is an Object. Assumed immutability? Again, ubiquitous. This is such an insane stipulation. Accepting this we can reduce any definition to nothing. >being a form of transportation/having tires/having a seat isn't part of what defines a bike because cars have those features too! >im critical of ... generally stuff that constrain the programmer in artifical ways and prevent simplicity. So when everything is a function that constrains the programmer in artificial ways. What about when everything is an Object like in Java/Javascript/C#/Python? Is dealing with Object hierarchy always super simple? What about when everything is garbage collected or memory managed? Are these not constraints? You even touch on why constraints might be important later in your post. >it's very easy to beat C in safety since it's outdated and almost got no safety features Do safety features not artificially limit what a programmer can do? As best as I can tell, your take on FP is "When a language I like does something it's a feature, when a language I don't like does something it's fundamentally bad"

>>28670 >performance wise usually you're better off syncing access instead of making copies I'm not a functional programming fanatic, but I can't help thinking that you don't know what you're talking about. Copies can be cheap, synchronization is generally expensive. And having multiple cores read and write to the same area of memory comes with an extra penalty too (cpu caches have to be synchronized, if I remember correctly). If you can efficiently split the work and minimize access to actively mutated state shared between threads, your performance will only improve.

>>28681 i wrote usually, and you talking about embarassingly parallel cases which are super easy. once you actually have dependencies you need sync and you cant use copies, and if you do somehow trying to resolve the effectively race condition will be slow.

>tries to learn fp >discovers too stupid >FP IS GARBAGE! sad you project your own lack of comprehension onto programming languages that are used daily and enjoyed and understood well by many. both of your arguments are trash. performance has been improving for decades as new compilation techniques emerge. they do make everything easier. anyone who thinks otherwise simply lacks the experience (or, in your case, capacity) to grok it. go crawl back under the bridge you came from troll.

>>28660 >- make the programmer's work easier (productivity) I truly fail to see how FP do not fall into this for many cases. It's not a "solve it all" paradigm, but none is anyway. But like any other, it has many cases where it's the best solution. At the end of the day, it's just another tool that will only help you if you master it. Simple as that.

>>28690 i havent touched FP for over a decade. it's just that during my compiler & language design research one day it clicked that FP isn't used in the real world because it fails at the stuff that matters.

>>28692 >that FP isn't used in the real world because it fails at the stuff that matters. Like what?

>>28692 >i[sic] havent[sic] touched FP for over a decade, so here's my opinion on it.

>>28689 You seem to be pretty vague about those ubiquitous programs where you absolutely need threads, but somehow have no way to divide responsibilities in a way that minimizes synchronization. Are you sure those particular programs wouldn't be better off written in a single-threaded manner? The more synchronization events you have between threads, the more you will approach (or get worse than) single-threaded performance anyways. Or maybe those programs could be written in Erlang, a highly concurrent functional programming language (^: >and if you do somehow trying to resolve the effectively race condition will be slow Has anyone really been far even as decided to use even go want to do look more like?

a note on "copying": if you're approaching FP from an imperative perspective, it's easy to fall into the trap of applying the logic you would use to analyze an imperative program that does not mutate its input to a functional one. if an imperative program accepts a (mutable) map, returns a map with a new key inserted, and claims not to mutate its inputs, you would (reasonably) assume that it had to expensively copy the entire datastructure this isn't how we write functional programs: your cs101 knowledge often doesn't apply. we use entirely different data structures with efficient operations that *share data between the input and output*. this crucially involves two things that make it hard for imperative programmers to do the sort of high-level educated guesses at performance i mentioned earlier: 1) you have to think about applications that might benefit from the fact we didn't butcher the input (this goes beyond easy concurrency, but that is a huge win) 2) functional data structures must almost always be implemented with (at least some) laziness, if they are amortized. you probably didn't learn how to analyze lazy programs in school. "fp" libraries for imperative programming languages usually get this wrong.

He's right that imposed immutability is garbage, though, because some algorithms simply depend on being in-place for efficiency AND readability. Mutability is often the most intuitive way to express something, so choice should be given, instead of the ML "purity cult". t. CL user

>>28705 The ML family pushes immutability to a greater degree than its Lisp cousins, but they are by no means pure about it. The closest thing I can think of to a pure FP ML dialect is Haskell, and that's pushing it.

>>28715 Indeed, the cult is not perfect, but they strive for it.

>>28668 c version is still 5 times faster and author admits it's not the fastest c version.

>>28815 >I didn't read the article

>>28815 (not the guy you were replying to) C excels at performance, but it's pretty lousy at productivity.

>>28660 FP is one of those things in computer science (see unix philosophy) that are very difficult to criticise because, at their core, they are some good advice. Then surround that advice is a whole bunch of stuff that is much more questionable.

>>29008 The UNIX philosophy is hard to criticize because it is actually good (except the "no protocol other than bytes", especially when they use ASCII which has tons of control characters reserved for this soykaf). Idiots criticize UNIX and think they scored against the UNIX philosophy. Wrong, UNIX is actually a poor implementation of said UNIX philosophy and SuS/POSIX is a hackjob that was standardized way too soon without any regard for future evolution or even fixing the past, just wanting to unify all the proprietary UNIXes (a bit like Common Lisp, really). Plan 9 wasn't made just for fun, after all.

>>28660 Look into APL, which is an array programming language. The basic idea is making it very easy to perform complex mathematical transformations, typically to all of an array at once, conceptually. This has obvious hardware implementations, such as SIMD and systolic arrays, which functional programming doesn't outside of projects such as the Reduceron and SECD machine. Furthermore, an APL program is typically very small, mine are as well, so there's not much effort on the programmer besides thought. >>28668 https://ummaycoc.github.io/wc.apl/ >>29008 >>29009 The UNIX philosophy is simply brand-named simplicity. The ideas of modularity and simplicity predate automatic computing and recorded history, and yet people will claim one is following UNIX if one were to write a program that adheres to these basic ideals. Further, those other qualities of this philosophy result in programs that aren't modular, simple, nor beautiful. >Wrong, UNIX is actually a poor implementation of said UNIX philosophy This proves my point that UNIX is actually a cult.

Unix is a poor implementation of Unix, perhaps. Who would have thought. Unix philosophy: neither Unix, nor philosophy. Yeah

>>29009 Exactly my point. There is some good advice: “write things to be interoperable”, and it is surrounded by a bunch of BS. When the unix philosophy is just a few sentences of good advice, there is almost no point in it existing. The only reason it is relevant is that many people are stupid and don't follow that good advice. Likewise for FP, but the advice is: “minimise state”.

>>29011 >The UNIX philosophy is simply brand-named simplicity. That's because you're being reductionist. The most important point of the philosophy is the extremely minimalist API of processes (standard streams, argv, return code and signals) together with the shell (mostly pipe) as a data oriented "programming" environment. That's what allowed so many programming languages to flourish, as you only needed to implement such a basic interface for it to become usable. Another thing you mostly ignored is that it's about provisional modularity: write your programs as if they were to be used inside a pipeline in the future and/or by other people. Compare this with something like Lisp machines where integration between the components is a lot tighter, but only shines when there's no external world to work with. >The ideas of modularity and simplicity predate automatic computing and recorded history So what? You're crying about the UNIX name being attached to it just because it didn't invent its parts but put them together and somehow formalized it? >>29018 I guess it should be "write things to be interoperable in a system with text streams and pipelines", which does deserve naming, since UNIX introduced such easy-to-use asynchronous pipelines. Otherwise, modularity is almost always a plus in computing, unless the cost is too high (designing proper APIs is not for dumbasses).

>>29023 >text streams That's the bit that fuarrrked it up. Text is a crappy way of storing data, in terms of both efficiency and usability.

>>29023 >So what? You're crying about the UNIX name being attached to it just because it didn't invent its parts but put them together and somehow formalized it? Not him, but calling it "the UNIX philosophy" implies that UNIX 'owns' it; like they not only invented it but are also the best at it.

>>28660 thank you for the warning i knew haskell was a meme

The main strength of FP, at least to me, is that it keeps my namespaces clean. Let's say I have a collection of names, and I want to retrieve all the names starting with 'a'. The imperitive approach would be to create a temporary collection to store the names starting with 'a', loop over your main collection with a for in loop that checks to see if $i starts with 'a', and then return the temp collection. But with FP, you'd just map an anonymous function to the main collection. You get the same results with fewer steps and less clutter in your code.

>>29025 what is a better alternative >>29076 example of FP please

>>29082 I just gave one. Here it is in soykafty pseudocode: imperative:function starts_with(letter, collection){ let temp = [] for i in temp{ if i = letter then{ append(temp i) } } return temp } functional: function starts_with(letter, collection){ return map(function(x){if x = letter then{return letter}}, collection) }

>>29083 Meant for >>29078

One of the biggest advantages of functional programming is you are unfireable at a company when you write a codebase in it.

>>29083 That's rather counterintuitive pseudocode, as it implies that map returns a collection of a different size than its input. Normally that's the job of filter/select/reject/whatever your language calls it. function starts_with(letter, collection){ return select(function(x){return x = letter}, collection) } Keeping namespaces clean could be achieved simply with scopes; many imperative languages, I believe, support code blocks (as introduced with {} for example) that create new scopes. I think a more important feature of the case you're describing is that FP tends to abstract common patterns into procedures, so they can be written once and then reused, whereas in imperative programming the common practice is to write loops from scratch every time. As a result, functional code is usually sprinkled all over with very abstract procedures that can often be hard to wrap your head around, but is briefer and less prone to error.

>>29078 >what is a better alternative Almost anything. The issue when deciding a universal method of data storage is the universal part. Text is crap at storage, but great at being universal. Serialise almost any other data-structure (lists for instance, being the obvious one) and you get a better binary format, but you suddenly need a specialist piece of software to edit it. Everyone has a text editor, no one has a serialised list editor.

>>29104 but you can represent any data structure with text.

>>29025 Text streams are okay, especially since ASCII contains control characters made specially to format them. The problem is UNIX tools being retarded and using readable formats with space separators (not even tabulations) while expecting people to parse them. UNIX would have just needed to introduce environment variables named FS and RS defaulting to ASCII US and RS (or \t and \n), ban the use of control chars in paths, maybe give a standard way to encode/decode said control chars to avoid problems during binary serialization and use this mechanism everywhere a tabular or list format is output/read. Would have even solved the lack of arrays in sh and a LOT of tools would have one or even two options less.

>>29152 >Text streams are okay, the problem is using readable formats That is the defining feature of text. It's just a binary stream if it's not readable, and you'd need a standard way to make it readable. In other words, it would be a binary format that no one wants to use because everything already uses text. Unless everyone agreed to it, it would just act as an intermediary for a text representation.

>>29153 Using RS=\n and FS=\t is both readable and parsable, as long as these aren't to be found in the fields themselves. For 99% of sh usecases (filesystem and simple data manipulation), it would "just werk" as long as said control characters aren't allowed in paths.

>>29155 >different separators for each level of nested data And if you want to produce something with three dimensions? [[[1, 2], [3, 4]], 5] seems like a very basic use case to me. You could just about get away with two new lines to distinguish tables, but beyond that you can not have much complex structure at all. >99% of sh usecases Already having a this text restriction has reduced 99% of sh use cases to being things that this works with. If you take a shell, remove the text restriction, and add a GUI, you would get Emacs (or something like it). There exists an Emacs version of almost every piece of software under the sun, do you think this would be the case if it used text streams? Text is not a good format, what other conclusion can you draw from the only shell that doesn't use text being one of the best out there? You can not even represent file names with the proposed format unless you add a / to delimit them. Would that necessarily be the only tree data anyone ever wants to deal with? What about printing diffs? What about git commit graphs? What about grep results for multiple files with tabs in them?

>>29157 >And if you want to produce something with three dimensions? You use a real programming language, I don't know a single UNIX tool that produces/consumes more than two dimensional data. Alternatively, ASCII has 4 control characters dedicated to this task (FS, GS, RS, US). >Text is not a good format Obviously, I'm talking about improving the UNIX shell, not replacing it. And unless your lang allows to do `a | b c | d e` instead of `(d (b (a) c) e)` for readability purposes (data pipeline displayed in order, no ridiculous nesting) and has all the obvious performance advantages of having a process per function producing/consuming in an asynchronous matter, don't bother saying that you just can replace sh with Elisp. >You can not even represent file names with the proposed format unless you add a / to delimit them. What? Everytime someone says "let's replace sh with Lisp", he totally ignores that's there's no direct replacement for |. It could probably be done in flexible enough languages, but would need the entire environment to go with it. I'd like to say CL, but it's subpar for Unicode string handling and stuff like threading/regexp isn't even standard. How I'd do it if I were to "upgrade" CL to have something similar: * Needs to be completely overhauled to support threading thorougly, including data structures. * Needs an efficient data structure to implement a FIFO (ring buffer is the obvious candidate). * Add something like &stream-in and &stream-out to lambda lists (instead of reserving two keywords). * Add the special operator/macro to tie this all together (e.g. allow pipeline components without &stream-in/out via buffering and passing the result as argument). Basically, sh can makes this elegant because stdin/stdout are treated as separate data transports than arguments/return and pipe(3)s are thread-safe and performant.

>>29160 >(d (b (a) c) e) You could just use the pipeline operator. (-> a (b c) (d e)) >What? You need the / to delimit file names, it can't be done with tabs because that would be too cumbersome. >don't bother saying that you just can replace sh with Elisp. Elisp's method of input (Emacs) is top notch, compared to typing everything in full at a shell. It might technically just be autocomplete and binds, but it makes the whole thing much easier to use and extends the concept of the shell outside of simple TUIs. It may not have sh features, but sh does not have it's features (if you count Emacs as a feature of Elisp, and the terminal as one of sh). >How I'd do it if I were to "upgrade" CL to have something similar Clojure has most of these things, but so does CL with a few libraries (bordeaux-threads, queues, alexandria) and about 12 minutes of work. >instead of reserving two keywords Just use a macro to override defun, then reserve some private keywords in a module. But those aren't really needed. 90% of the time you're just calling map and filter, just use those on a stream instead of defining special stream inputs. The general pattern is: generator => map/filter... => consumer, which doesn't require any functions except the generator and consumer to even know about streams. It can be simplified further, since the only functions that really make use of async are IO related: do-IO => map/filter => fold/reduce. From that point of view, no functions except IO-related ones need to deal with streams, everything else just works using generic interfaces. What you end up with is an iterators library, which is what you wanted from the start. Now you might be able to complain about it being unergonomic for daily use, but: -most regular things don't even need streams -the Emacs input style (binds + interactive) makes it easy to do the things you do often -a regex that works better with lisp data would help with most of the rest of these issues

>>29023 >That's because you're being reductionist. The most important point of the philosophy is the extremely minimalist API of processes (standard streams, argv, return code and signals) together with the shell (mostly pipe) as a data oriented "programming" environment. None of that results in simplicity, as even a basic UNIX requires a great deal of infrastructure just to provide those meagre features. How is returning an octet simple instead of just stupid? How are signals simple when a better mechanism allows for richer communication that's easier to write? >Another thing you mostly ignored is that it's about provisional modularity: write your programs as if they were to be used inside a pipeline in the future and/or by other people. Tying the human and machine interface together like that doesn't result in simplicity. >Compare this with something like Lisp machines where integration between the components is a lot tighter, but only shines when there's no external world to work with. The Lisp Machines had Ada and C language compilers. Compare the simplicity of making a change to Genera compared to the Linux kernel, but does that simplicity not count? Meanwhile, it's not pleasant to have a Lisp under UNIX, because of how braindead UNIX is. >So what? You're crying about the UNIX name being attached to it just because it didn't invent its parts but put them together and somehow formalized it? It did nothing of the sort, but fools believe it did. >>29104 >Text is crap at storage, but great at being universal. Bits are more universal, but we can clearly see that using unstructured bit streams would cause issues. Abstraction enables greater systems to be built. >Serialise almost any other data-structure (lists for instance, being the obvious one) and you get a better binary format, but you suddenly need a specialist piece of software to edit it. >Everyone has a text editor, no one has a serialised list editor. This thinking is what leads to garbage such as UNIX. Whatever we already have is great, and everything else costs too much, and why have it when nothing supports it, because it costs too much? Clearly, whatever garbage we have laying about is fine. A text editor is also specialized, but that also doesn't count, right? Here's an email I sent to Doug McIllroy, but after a tad of back-and-forth, he decided not to answer: Hello there. I've had many discussions about data formats and, being one of the popular systems, UNIX-likes come up often. I prefer numerical data formats, also known as binary formats; these tend to be smaller, easier to manipulate and verify, easier to parse, among other advantages. A disadvantage of these is the need of specialized tooling for creation, manipulation, and display with regards to human use. I've been of the belief that UNIX favors textual formats primarily because these enable ostensibly generic tooling to be used and not for any other particular reason. That is, you can create them with ed, display them with more or less, and so on. It is my belief this was due to sloth more than anything, considering the various textual formats common have different syntaxes and other qualities that I'd think preclude an overarching design consideration. Would you be able to give any information or perspective on this view? I appreciate your taking the time to read this email. >>29160 >Everytime someone says "let's replace sh with Lisp", he totally ignores that's there's no direct replacement for |. I have better things to do with my time than play human centipede with terrible programs. Common Lisp has better streams, but they're intended for more than just octets.

>>29165 >This thinking is what leads to garbage such as UNIX. I had intended it as more of a justification than praise, why I think it happened, not why it was good. At the time it was a reasoned decision, and evidently the right one given the success produced. This all circles back around to the old “why don't we all just use the same language?” argument, and the answer is that it probably won't be yours. Everyone wants to standardise, but only on the thing they like. The only solution would be to sit every programmer down in a big room (impractical) and have them all design the solution by committee (horrible results).

>>29165 >How is returning an octet simple instead of just stupid? How are signals simple when a better mechanism allows for richer communication that's easier to write? You seem to be unable to understand that something may be both simple and stupid. >Tying the human and machine interface together like that doesn't result in simplicity. They should be tied, but not like that. Like Emacs, where the human interface is built on the machine interface. I agree that trying to merge them is mostly retarded; but see Plan 9, it can be done. >I have better things to do with my time than play human centipede with terrible programs. Come on, they may be terrible programs, but you're arguing against the implementation instead of the idea. >Common Lisp has better streams, but they're intended for more than just octets. CL streams are indeed better, in fact, CL is better than everything else on almost every level. Its problems are mostly historical baggage and having been designed with retrocompatibility in mind.

>>28660 Guaranteed replies. It's that easy in lainchan.

>>28660 > immutable [...] makes it [...] harder for the compiler to optimize the code Incorrect. Immutability actually makes it easier for many optimization because they compiler doesn't have to worry about mutating state.

>>29186 this is really sad you're that ignorant yet think you're clever. if u had basic knowledge of compiler optimizations you wouldn't make that post.

>>28660 the premise of languages like haskell is that effects being explicit at the type level improves correctness, and that being able to program your own effects gains you expressivity. i don't know whether the first premise is true (i feel like it helps but comes at a cost) and i don't feel like i've ever really needed the latter in general programming, but there's one benefit of functional languages that haskell doesn't leverage at all: there's a very direct correspondence between logic and typed functional programming, which means that it's fairly easy to build a functional programming language that is also capable of proving theorems and doing maths. using the exact same language for proofs, programs and specifications has a ton of benefits and simplifies things massively. at the same time, not having to reason about the heap (as you have to do in inherently imperative programs) simplifies correctness proofs considerably, so not having any effects built-in is helpful when reasoning formally about programs. now, program verification itself has a huge cost associated with it, so make from that what you will. but depending on how important correctness is for a software project, this may be a worthwhile benefit. performance is obviously an issue with current functional languages as well, but there are some recent developments in research for strict functional languages that alleviate the whole issue with copies and costly memory allocations. lastly, while i don't appreciate the constant worries about performance in current functional languages, i do appreciate not having to worry about the heap, reference semantics and the like.

>>29200 What language(s) have this proof system? I know Idris has the option to prove the correctness of functions, is that the kind of thing you're referring to?

>>29201 idris is one example of a language capable of proof that is also a functional programming language, though it lacks all the good stuff that makes a theorem prover usable, so i wouldn't expect it to be as painless as other theorem provers.

>>29199 Feel free to provide any argument. I'll provide a concrete example: the `const' annotation which makes local variables immutable. This allows the compiler to make certain optimizations knowing the data cannot be changed. I take it that your pic-related applies to yourself.

>>29200 >>29209 Lack of mutable state makes it easier to write an optimizing compiler, but I doubt it actually leads to better compiler optimizations. The real benefit of immutability is in multi-threaded/distributed programming, and even then you can definitely get better performance by being clever (I once wrote a program that worked by lazily modifying a huge array of atomic variables, for instance). Functional programming simplifies the job of the programmer in many respects, and leads to a compact mathematical style. For me that's enough of a reason to use it.

>>29213 >I doubt Perhaps you should learn what you are talking about so that you do not need to qualify. It is quite easy to research this.

>>29209 >the `const' annotation which makes local variables immutable. This allows the compiler to make certain optimizations knowing the data cannot be changed. wrong. there's even a CppCon talk with one of the LLVM devs (chandler) in which someone asked this and he said it doesnt help optimizing. what i was referring to as "basic compiler optimizations" knowledge is data flow analysis - the compiler doesn't need you to tell it what mutates state, it already knows. and making everything a copy changes the semantics of the program so the compiler cant optimize that - are you actually making a copy to store different data or is it just functional memeing? and of course you're on the top of pic related so you're being wrong & arrogant about it.

>>29214 I doubt it because I am aware that most compilers convert all code into code which modifies immutable variables (those "three-term statements") and then apply optimization steps to reduce the computation complexity close to the original. it is more complicated to write the same optimizations when you don't know ahead of time that variables will never be modified, but modern compilers like LLVM and GCC apply many passes that essentially detect it.

>>29220 I know full-well about SSA. Mutable variables (especially pointers) do not work with it. Most of my experience comes from llvm, where you would need to alloca for any mutable variable you wish to pass by reference (which can not always be optimised into SSA form). Only code which is already in SSA (functional, or very close to it) can be reliably translated to SSA. More generally, you have something like: class c { virtual void z(); }; int x(c* y) { y.z(); return 3; } In order to optimise a call to z away, you would need to verify that it has no side effects. This ranges from a costly and complex pass in a static binary, to impossible in a dynamic library (side effects might be introduced by overrides in child classes). If there is no shared mutable state, a function call to x can be replaced by 3 in any of its callers.

>>29221 not him but this seems ill framed. how are you defining side effects? what u really care about is program output opposed to internal state. that is if the call has internal side effects that don't change the output it can be removed. tho it might be even harder to detect.

>>29221 you can't know when an external functin call is side-effect free in functional code either. Other than that, you are correct that the optimization is more complicated and doesn't always work. That is my standpoint as well. The point is that if you put any serious effort into optimization and use a current featureful compiler, it will probably come out the same in the end.

>>29222 >how are you defining side effects? >shared mutable state If the function shares data with the caller and that data is mutable. Doesn't matter if you get rid of the sharing or the mutability. >>29223 I know that GHC uses an IR called core, and I think there are a lot of optimisations that go on there. They would logically be things that rely on the functional part of the code, otherwise they would just be implemented in LLVM. Generated haskell code seems to be quite fast. so I suppose it works. I also think that the garbage collector uses the fact it's functional to improve performance.

>>29220 >>29222 >>29223 it won't come out the same because as soon as your code isn't easily convertible to a functional equivalent, you need alias analysis to perform any optimizations whatsoever, and alias analysis is either horribly slow and complex (as a proper interprocedual data flow analysis) or horribly inaccurate (as an inference system based approach). even the data flow analysis is a considerable under-approximation and especially in the presence of multi-threading you get almost no guarantees, since every effect is observable. that's not to say that you need a functional language to do this - "locally imperative" code is usually fine and if your code is mostly functional, despite being in an imperative language, you get the same guarantees. in fact, there are now functional languages that let you write "locally imperative" code and give you all the same guarantees that you'd otherwise get in a functional language, too.

>>29219 const in C/C++ does not help optimization because there is not any guarantee that the value cannot be changed at runtime. Essentially, due to their horrid design, these languages allow for changing const variables and therefore the compiler cannot make assumptions about it.

>>29219 >the compiler doesn't need you to tell it what mutates state, it already knows. A compiler cannot always determine whether or not a mutable variable is mutated or not. If one code branch mutates the variable and another code branch does not, then the compiler may be unsure; the compiler cannot know what branch is taken, in general. This is not because of I/O; this is because of the halting problem. >>29219 >I doubt it because I am aware that most compilers convert all code into code which modifies immutable variables (those "three-term statements") I thought CPS was more popular than SSA in the functional programming space. >>29221 This reminds me of how the value-flow problem becomes the control-flow problem becomes the value-flow problem in functional programming languages. (f a) ; The control flow of this expression depends on the current value of f. A mutable 'f' sounds even worse. >>29225 >They would logically be things that rely on the functional part of the code, otherwise they would just be implemented in LLVM. See, that's what I thought, but 'Core' doesn't look like CPS at all. It looks like they're just punting the compilation task to another intermediate representation. >>29228 Why doesn't the C++ compiler just assume the values won't be changed? C++ compilers already remove null checks on pointers deferenced before the check. (They can't be null if they've been used! Let's remove that dead code branch.)

>>29229 C++ does a bunch of weird soykaf because of its origins as a C preprocessor. Any features added back when it was still "C with classes" (such as constants) are guaranteed to be complete nonsense under the hood.

>>29219 Feel free to provide concrete argument. 'a youtube video one time' and 'i was talking about something else' don't count as they are not arguments.

>>29229 >A compiler cannot always determine whether or not a mutable variable is mutated or not. If one code branch mutates the variable and another code branch does not, then the compiler may be unsure; the compiler cannot know what branch is taken, in general. neither does the programmer, or anyone, because it's unknowable. any statement with a side effect is known & visible to the compiler, the programmer doesn't have information it doesn't about mutability, thus is can make just as good decisions. stop proving functional memers are incompetent. >>29231 i did, "data flow analysis", second paragraph. next time actually make sure you understand what you're reading before replying.

>>29236 >any statement with a side effect is known & visible to the compiler, Whether that statement is ever reached is unknown. In general, data flow analysis cannot determine if a statement is reached or not.

You guys are fuarrrking stupid. OP is not even here anymore.

>>29237 >>29236 >because it's unknowable. for weird self-modifying code, sure. Generally code is much more structured and if you don't code like a monkey, data flow analysis will work 90% of the time.

>>29353 >>29354 if(runtime_true_random_bool()){ f(); } go ahead retards, describe how it's knowable at conpile time if f() is called.

>>28660 > immutable is a good thing - it makes it hard for the programmer to express even trivial things I've never used a language with no non-mutable types, what language is this about? If anything shared-persistence data structures seem to be faster and easier to reason about for most problems FWIW the Common Lisp mentality isn't "use immutable structures only" and mutably isn't what makes a language functional, that's just Haskell propaganda. If mutation makes your algorithm better, you are allowed and given tools to do that. If anything Lisp's staying power, should tell you you're missing something. And I don't mean its popularity. >>28697 > functional data structures must almost always be implemented with (at least some) laziness, if they are amortized Good point, laziness can be hard to think about, I've seen a number of Clojure users get confused over the thunking behavior of collections. >>28705 based pragmatic FP user >>29076 namespaces dont have anything to do with FP? i may misunderstand >>29163 If this is meaning (-> bar foo) means foo | bar in shellism, that's WAY to many characters >>29163 Clojure is a real downgrade from Common Lisp in one particular area: the error and conditional handling system, God fuarrrk JVM stack traces. thos JVM libraries though >>29417 >not coding like a monkey

>>29418 so you cant describe how, what a surprise. it isn't code monkey code, retard. it's a concrete example for runtime input. the saddest part is that you're all smug about being wrong while everyone else cringe.

>>29417 >is f called is different from >is f reachable which is the relevant topic when it comes to optimization. In this case yes, f is clearly reachable.

>>29443 oh, also, before you try to say "nuh uh! you said whether it's called!" If you're making an argument from turing machines (which I assume you are) then the program as a whole is deterministic and includes its inputs. In that context, reachability is the same as whether it's called, the random variable is necessarily known at compile time. All nondeterministic turing machines are equivalent to a bigger deterministic turing machine. Obviously that's not very useful from a practical point of view, just like most computability theory isn't useful from a practical point of view, and in fact when you don't write code like a monkey a majority of decideability problems vanish.

>>29354 >for weird self-modifying code, sure. An array of function pointers is extremely common and soykafs on naive data flow analysis. >>29443 >which is the relevant topic when it comes to optimization. You have to build a control flow graph to determine if a variable is reachable. To build a control flow graph you need to know what functions are called. You don't what 'f' is defined as. You don't even know, in general, if 'f' is defined. Static analysis is not magic.

>>29443 >which is the relevant topic when it comes to optimization. In this case yes, f is clearly reachable. dead code elimination is nothing new. pathetic strawman attempt.

>>29444 >includes its inputs holy soykaf wtf is this retarded mental gymnastics. if an "input" is included it's part of the program, not an input. i explicitly said runtime too.

>for example the assumption that always immutable is a good thing - it makes it hard for the programmer to express even trivial things (productivity) fool detected

>>29465 if you want to use formal computability theory, you have to use the assumptions of formal computability theory. Every nondeterministic turing machine (which model mchines with input) is equivalent to a family of deterministic turing machines.

>>29453 >You don't even know, in general, if 'f' is defined. What do you mean? It's right there in the code. >You have to build a control flow graph to determine if a variable is reachable. To build a control flow graph you need to know what functions are called. Like I said, reachability is not computable. But in most situations, which don't include self-modifying code, there are very good heuristics. It's like saying you can't solve a problem because it's equivalent to the travelling salesman problem, but TSP has extremely good heuristics that are good enough 99.9% of the time.

>>29165 > he decided not to answer Lmao, smart man.

>>28660 FP is for fun, not for real software. No any Haskell in the real world and it is impossible. All Haskell soykaf is shortly removed and replaced with real programming langs. It's true for many FP toys.

>>29506 A compiler's relationship with the programs it produces is what's being talked about here. The compiler doesn't have access to the input of the programs it produces. If you really want to get into it the compiler is a turing machine whose output is other turing machines. While in theory this means we could just add to the compiler's input all possible input of our resultant program that would expand the input to infinity which isn't doable inside of the universe.

>>29620 Yes, but for instance, if what you've written is a finite state machine, then it actually *is* possible to evaluate in finite time whether it halts on a particular (finite) input. I can think of no better definition for the "decidability" of whether a program reaches a certain state or not, than to say that a Program is decidable iff it is possible decide in finite time whether the function mapping Q to P(Q) (codomain is the infinite string for output tape at time of halting) halts. If we assume that all computers that you can actually run programs on have a finite amount of memory, then they are all finite state automata, so it is a decideable problem.

>>29624 I'd also like to point out that this is all besides the point since the decideability is considered a computationally *difficult* (but not decideable) problem. Usually you would instead use some convenient heuristics to model parts of the program as FSM's... for instance, if you know two arithmetic expressions will always be the same, you can write whichever one is faster and save the computation. If whether the function is called is determined by a comparison with a known high-entropy value (a large counter or pointer or something, for instance) and the range where it would be called is very small comparatively, you can choose not to inline it. These are all things that any good compiler does, and functional programming languages make it simple for the compiler to perform this kind of analysis because it doesn't let you out of a very rigid paradigm. >arrays of function pointers soykaf on data flow analysis It's generally considered bad form to do that kind of soykaf when you're trying to eke out the kind of performance where that kind of thing matters.

>>29605 you are appealing to Real World this means you consider JS as a real language you arent special or more reasonable than anyone you, tool

Just bump this thread already and create multiple threads about programming paradigms, one for functional, other for procedural and so on. Everyone here are just trashing at each other about their personal preferences. What to expect of a thread that just complained about FP without any proper argument.