(untitled)

Whats your reason to learn haskell/erlang or other noncommon languages, are they better? Will they work at every platform? Or just self challenge? sometimes i want to learn some of these langs but i cant find really good reason to start, also probably i cant find job with em in my country and maybe little bit feels like waste of time? Or just these languages doesnt suits me?

Learning new ways to express complex ideas is interesting and useful.

Back when I was learning programming, I was doing it for fun. And Haskell is a lot of fun.

>>6526 Learning different paradigms is the one of the best ways to improve as a programmer in my opinion.

>Whats your reason to learn haskell/erlang or other noncommon languages, are they better? Before I address 'uncommon' languages lets state what the common ones are and why they are 'common'. Java/C# Java was first billed as a 'write once, run anywhere' language because people thought that it would be more portable than compiled languages because it ran on a VM. That turned out to be false, compiled languages are just as portable. The reason that Java (and its clone C#) are so popular is because they are so safe and robust because it runs on a VM. If a bad programmer makes a program that crashes, it only takes down the VM, not the whole operating system. Even a super safe compiled language like Ada is less secure against bad programming and crashes the OS. So this is why Java/C# completely owns enterprise computing. Also the fact that it has very conventional syntax and forces OO means that its very modular and code made by low quality programmers will always work together well. C++ C++ rides on the coat tails of C, C is the defacto systems language and there are good reasons for C being a good systems language. By systems language I mean running on bare metal or doing kernel-space programming. When C++ became popular in the 90s its only competition was VB, Delphi and Java, so obviously C++ appeared to be a much more powerful language than any available alternative with its unlimited pointer use and memory allocation. But all this pointer walking doesnt really mean anything in userspace of an OS and most C++ programmers just fool themselves into thinking they are programming on hardware memory space. Also currently there is a lot of meme spouting about 'generics' to try and make C++ look like its modern. But Id really like someone to show me an example of everyday C++ programmers using templates for anything other than just making functions take a variable range of types. Haskell Yes Haskell belongs in the list of 'common' programming languages, it is not at all obscure, the #haskell channel on freenode is usually always tied with #python for most users. The whole 'pure functional' language thing is a myth, Haskell has mutable state, its entire programming environment is mutable state. People who believe in 'pure functional programming' are chasing the dragon. ------------------------------------------------------------------------------------- OK, so what are the replacements? Well.... Elixir/Go Elixir and Go are going to take over in backend programming. People are latching on to Node quite hard, but Node is really only good for SPA's and can not scale to handle large data nor can it handle real concurrency as it fakes concurrency with an event loop. There is a lot hype about Ruby being obsolete but what is replacing it? Python is an easier language to learn than Ruby but it is a less powerful language IMO, so I consider Django to be a step backwards from Rails. Its only a matter of time before web programmers are forced to accept Elixir and Go as both these languages eliminate all the problems with Node and Rails/Django. Rust Most people think of Rust as a replacement for C++, but I consider just as much a replacement for Haskell. Rust can do everything that Ocaml/Haskell can but in a much less limited way. And eventually Rust will replace C++ as C++ is just a pretend/fake systems language and most C++ programmers just programming in C++ in the same way you would program in Java. Kotlin/Swift Java may be a good language for enterprise but its syntax is out of date and quite limiting for mobile programming. So Kotlin has replaced Java for Android and Swift has shoved out Obj-C on iOS.

>>6628 This whole post is a load of bull. >>6526 Some obsure or noncommon languages have features that make them a lot better at some tasks than more mainstream languages. I don't need a reason to try out an obscure language, but if I stick with it for a larger project it's usually because it's better suited at that task than any other language out there. For example, I've been writing a lot of Ur/Web recently, even though the number of users of the language is not much more than a few hundred, because there's simply nothing else out there that gives you the same level of safety and integration when writing web applications. >Or just self challenge? It's more about self-improvement than challenge. Learning a language that adopts an unusual paradigm will help you understand that paradigm much better than if you just tried to use it in a language that doesn't adhere to it as much, and will give you a new perspective on the problems you want to tackle. Basically, you'll get better. >probably i cant find job with em in my country Some companies use uncommon languages partly because while the pool of programmers that know them is comparatively very small, those programmers are usually very good. it's difficult to get a job using an uncommon language, but it'll likely be great and pay well if you find one. I don't think anybody can help you with the lack of motivation. If you don't find learning about programming interesting you can get by with what you already know just fine.

>>6526 Some of them have interesting concepts that aren't implemented in major programming languages. It's fun to see how those work. >>6628 >Haskell is common It's not even top 20. Two of the "uncommon" replacements you listed (Go and Swift) are top 20 - how can those be uncommon if Haskell is common and they're more common than Haskell? >compiled languages are just as portable as Java Not really, unless the programmer explicitly programs them to be cross-platform or the program is so simple that it doesn't need to make any use of OS-dependent functionality. >when compiled programs crash, they take down the whole operating system This hasn't been true in a long, long time. OSes are not so simplistic that an arbitrary program segfaulting is going to crash the OS. >most C++ programmers just fool themselves into thinking they are programming on hardware memory space What do you even mean "hardware memory space?" Memory is stored in hardware, and while the OS prevents users from directly accessing hardware addresses through virtual addressing, any time you put something into memory, it is, literally, in memory, on the hardware. Or is your point that they're addressing virtual memory addresses instead of physical addresses? Because I don't know of any C/C++ programmers who are so disillusioned as to believe they have direct access to the physical address unless they're doing embedded systems programming.

>>6526 Personally, learning Scheme (through SICP) really expanded my mind on programming techniques and possibilities. I suppose learning any language that is outside your comfort zone/preferred paradigm would have that effect. Don't expect to use them for a job, though. >>6628 >But all this pointer walking doesnt really mean anything in userspace of an OS Except it does. The OS allocates a chunk of addressable memory for an application, and then the application uses addresses (aka pointers) to access data on that chunk. This is true at the machine code level, and it's also true at the C/C++ level. The fact that the addresses are virtual rather than physical is extremely irrelevant; it just means more work for the MMU hardware. >a lot of meme spouting about 'generics' At least it has generics, unlike a certain "modern" language Present Day, Present Time! AHAHAHAHAHA! >But Id really like someone to show me an example of everyday C++ programmers using templates for anything other than just making functions take a variable range of types. What the fuarrrk is an "everyday programmer", and why does it matters if they're not heavily defining templates when they're not making libraries? Also, the "everyday programmer" is using templates every time he instantiate a std::string or a std::vector. >And eventually Rust will replace C++ as C++ is just a pretend/fake systems language and most C++ programmers just programming in C++ in the same way you would program in Java. This is a nice piece of nonsense. First, considering that C is a real systems language (if it isn't, then nothing is), how can a language that is mostly a superset of C (bar for a few minor features) not also be also considered a real systems language? Second, assuming that C++ programmers are programming in C++ like they would in Java (I'm not so sure about that), then why would they switch to Rust? Does Rust offer more Java-like features? Otherwise, how can you pretend Rust will replace C++ if it can't give C++ programmers what they supposedly want?

>>6628 >By systems language I mean running on bare metal or doing kernel-space programming. Actually that's C. The core philosophy of C++ is zero cost abstractions so it is mostly used for high performance userspace work, like video games and scientific simulations and high frequency trading. >But all this pointer walking doesnt really mean anything in userspace of an OS and most C++ programmers just fool themselves into thinking they are programming on hardware memory space. Speak for yourself. The purpose of manual memory management is performance and predicable latency. >But Id really like someone to show me an example of everyday C++ programmers using templates for anything other than just making functions take a variable range of types. This is the reason templates exist. The fact that they are accidentally turning complete and have been abused to do metaprogramming at compile time is something the committee is trying to fix by adding new features to do that instead like constexpr. It's not a "meme". >Most people think of Rust as a replacement for C++ Speak for yourself. >C++ is just a pretend/fake systems language and most C++ programmers just programming in C++ in the same way you would program in Java. Places where C++ is being used like Java or C# will be replaced by Java or C#. Not Rust. >>6642 >This whole post is a load of bull. Agreed. This person hasn't got a clue.

Because every time I put it down I crawl back to it eventually, if nothing else just to make my processor sweat. Simply put because it's fun. If you're having trouble finding the motivation, I'd suggest getting into the theory of it and then working out how you might solve various little problems. There's a lot of theory behind Haskell and so that's fun to look at.

I had the chance to be able to learn them when getting a job was not something I was worried about because I was still studying. Erlang was my first programming language right after bash, so I felt a connection Haskell came along when I wanted a deeper understanding of type theory

>>6643 I can freeze my system with a C program. I think that’s what he meant.

>>6526 Every language has a niche. If you are interested in Haskell, you should write a DSL. Haskell is really good at that. Or, you can even just bolt on a Haskell superset and call it a day. Write a project in the language you are interested in. It's not indulgent to explore some of the odd ones.

>>10258 >I can freeze my system with a C program. I think that’s what he meant. I can "freeze" your system with a bash script :(){ :|:& };: Language has nothing to do with it.

A good reason to learn Haskell/Erlang or any functional programming, is that it's different than your average programming language, which makes it a lot more fun to learn and experiment with. And it's a good way to gain more experience, if you already know some programming languages.

>>10263 spot on. >Whats your reason to learn haskell/erlang or other noncommon languages I used ML in a compilers course at university and that was the start of the love affair.

>are they better? I wouldn't compare languages that way. You can't reasonably say that one language is "better" than another. They are just too different in many aspects which all have advantages and disadvantages. >noncommon languages Often they do something different than more common languages, and I think it's good to learn different approaches. Sometimes I like learning a language just because I'm interested in how it does things. I think when I learn a new language that has some unique feature it can change the way I approach a programming problem. Even if I'll never use that language again, there are probably a lot of higher level things that I learned while learning the language which will turn out to be useful in other contexts. Another reason is that I simply don't like choosing a certain tool based on popularity alone.

>>6526 Erlang is god-tier powerful, and Elixir is Erlang with ruby syntax. The Erlang VM was used by whatsapp (maybe it still is?), Discord, and lots and lots of other massively parallel distributed services. It's just so reliable and well designed for concurrency and fault tolerance.

>>6526 >Haskell has mutable state Haskell does indeed allows you to "mutate state" in the sense that you can change memory and do IO. But syntactically, in Haskell you deal only with immutable data structures. To represent mutations you use some specific monads that represent the mutations semantically.

Holy soykaf getting Haskell to run in arch is a giant hassle. I feel like setting up a separate VM with Haskell is an easier solution.

>>6526 Erlang is easy to learn, easy to read, easy to write, very well-documented, incredibly well implemented, with great tools and an inspired 'stdlib' with OTP. It's one of the Great-tier languages, and if you want something like Lisp and don't mind it not being suitable for small fast binaries, you should go with Erlang. Elixir fixes a few Erlang warts (strings as lists, binaries being a bit ugly). It's not bad, but Erlang alone is great. But, Erlang ain't a statically typed language with an advanced type system. A good example of a language like that is ATS: http://www.ats-lang.org/ . Or just watch https://www.youtube.com/watch?v=zt0OQb1DBko ATS is an ML that compiles to C (and a bunch of other languages) that also has dependent types and theorem-proving. ATS's a pretty good contrast with Erlang: everything Erlang does well, ATS does poorly. Docs? One guy wrote them and they exist but they're not exhaustive or that approachable. Tooling? The error messages are a form of assault. Whereas Erlang's strings are displeasing (but easily dealt with), ATS has design decisions that draw open guffaws and derisive laughter. Easy? ATS is literally the hardest language that exists, even when you consider languages like INTERCAL or Malbolge that were deliberately crafted to be confounding. But, ATS is an ML with dependent types and theorem proving. Those advantages are so advantageous that if it didn't have all of these flaws, it would probably immediately cause a hole in reality and become the God of its own dimension. It's good. You should learn it so that you can use it in one-man projects and get a head start on it, because some company is eventually going to put Erlang levels of investment into a language like ATS and then you'll have a lot more competition for boring jobs like making sure that humanity's first FTL spacecraft doesn't fly into a star. If you want challenge, get Forth. If you want a job in your country, learn Go and JS. And then after you've learned and have gotten a job, look at Erlang or a language that you think has real promise but isn't popular enough yet.

>>10933 Just use nix

>>10933 use stack. installing Haskell from any distros repos is a pain in the ass.

>>6628 >Also the fact that it has very conventional syntax and forces OO means that its very modular and code made by low quality programmers will always work together well. you can have modularity without OO

>>10933 yet another thing that's easier on Gentoo, yet the distro is just as versatile :o

>>12003 >>10933 Haskell on arch isn't a pain once you realize, never use cabal. Just use stack for everything, and have emacs use intero mode. Once you do that, Haskell will never be an issue again >>12002 That is indeed true, and relatively easy. OCaml's Module system is a great example of this, it makes me wish Haskell had first class type classes (ie type classes you can pass around, meaning that we can have a List of Show's instead of having to make a typeclass that hides the a in Show a) >>10544 Most Haskell mutation happens in IO or ST, Haskell isn't yet advance enough yet to have an effects system where most mutation happens in various effects/monads

>>10933 sudo pacmna -S ghc is all I had to do.

The last few languages i've learned were rust, ruby and elm >rust I thought it was cool, a cool, new community with a lot of projects you can join. Without the community i wouldn't have bothered >Ruby/Rails/javascript Mony. Need mony. Gimme mony. If you have no reason whatsoever to learn a new language, you probably shouldn't, dude. Computer science is a layer above specific languages, and if you have no specific needs, use fortran for all i care.

>>10934 This.Except, trying to get started with Erlang is not that difficult, and take about two weeks for the difficulties to vanish (I had to use it for a job and still love it as a language). Using ATS is like trying to scratch your retinas by slowly, painstakingly inserting cocktail sticks into your eye, while trying to knot a XXL dragon dildo and you've never done anal before. It's... It took me an hour to ditch that and realise it was a pile of crap. If you want formal verification there's a perfectly good lisp with that. Actually as a language it might be the most superior batteries-included language of all-time. Meet Shen Lisp. It is/has: * Portable (port K-Lambda and you have ported Shen) * Literally everything Haskell has (pattern matching, currying, etc etc etc) * Static type checking based on sequent calculus * Shen Professional includes "a computably effective axiomatic semantics for generating formal descriptions of Shen programs in second-order logic" It has one of the nicest DSL creation systems I've seen. The only big soykafhole in the floor is that the LICENSE is basically "no forking!!!! >:(" > If you want a job in your country, learn Go and JS. And then after you've learned and have gotten a job, look at Erlang or a language that you think has real promise but isn't popular enough yet. That's kind of funny because almost every single job in the capital city of my country (UK) that pays $$$$ Big Bucks $$$$ requires Erlang knowledge. It sees heavy use in cloud security, banking, trading, and the financial sector afaik.

I've been learning the Mercury language as a way to expand my horizons of what can be done with declarative programming[1]. I wouldn't consider myself a huge fan of static languages in general, but I really like this one. It has true autoparallelization (just replace AND conjunctions (commas like Prolog) with ampersands, not the bait-and-switch of Haskellites bragging about functional parallelism and then yak shaving with Parallel Haskell extensions), compile time garbage collection (can statically verify that there's only stack allocation at run time), declarative clause grammars (better than parser combinators), etc. It gives me this sense of wonder that a few type and mode declarations over what's otherwise a restricted Prolog can allow the compiler to select totally different search strategies to solve problems. One feels that it's an alternative vision of what computing could be like, the final, keystone piece in fully realizing Licklider's Man-Computer Symbiosis. Mercury feels like everything that Haskell promises but fails to be. I just wish it would let me omit type and mode declarations (it has inference, but requires them always for some reason), had a REPL, and had Haskell-like refactoring tools and libraries. [1] Programming means flipping bits right now, and almost all programming discussions are about how to flip bits better. We couldn't even move to a slightly-parallel system like Itanium. von Neumann languages won't be able to handle massively parallel quantum or DNA computers. I suspect that it will be the languages with pure semantics and simple equational theories which will prove to be portable in coming years. Prolog and APL will live and hopefully thrive, C will die. >>12011 >Haskell isn't yet advance enough yet to have an effects system where most mutation happens in various effects/monads Haskell is advanced enough to have typesafe abstractions over continuous time which plug directly into pure functions. It's called functional reactive programming, or FRP for short. I don't know why it hasn't taken off; it's the one thing in the Haskellverse which has impressed me so far. I have heard that more recent implementations such as push-pull FRP outperform older ones like Fran (the original, see PDF). >>12020 >If you have no reason whatsoever to learn a new language, you probably shouldn't, dude. Computer science is a layer above specific languages, and if you have no specific needs, use fortran for all i care. Not true. Programming experiences in APL, Prolog, and C are nothing like each other. Some people might not even consider Prolog and its cousin SQL to be real programming languages. The formal equivalency in ability between predicate logic and Turing machines tells you nothing about their expressiveness or how easy it is to write something useful in them (re: "Turing Tarpit"). If every language was an expression of the same underlying concepts, why would we need new languages? Are you more insightful than the designers of every language? They all thought previous languages were inadequate, or else they wouldn't have written their own. http://www.paulgraham.com/icad.html >>10934 >>12022 I'm a sophomore in college and am thinking about a focus on distributed systems so I work with REPL-driven dynamic languages in Emacs (like in "Erlang: The Movie" )and learn about the actor model, pi calculus, and other innovative formalisms for computation which have so far only been looked at for concurrency[2] Is it worth it? [2] I'm always excited to hear about genuinely innovative approaches to computation like the chemical compiler: https://arxiv.org/abs/1808.04790 >>12022 >banking, trading, and the financial sector I've been thinking about learning K so I can work in that area. I already know some APL (I'm the one who posted the question about point-free composition in the APL thread), so I can't imagine it being that hard to learn. Is it hard to break into the field?

>>12023 I got carried away in editing my comment and missed something. [2] should include a link to http://research.microsoft.com/en-us/projects/spim/ Microsoft came up with a stochastic formulation of the pi calculus (a restricted version of the Actor Model, akin to CSP, and normally used to reason about concurrent processes) to compositionally model biological processes. Perhaps that could be combined with the chemical compiler.

>>12019 Not if you want to use any packages. Then the easiest is to install the stack binary separately and let it handle everything.

>>12023 >Not true. Programming experiences in APL, Prolog, and C are nothing like each other. I didn't try to imply that the difference between languages is only syntactic. What i said is that you shouldn't learn a new language if you have no reason to do so, which is exactly what OP asked. Ruby would definitely be a more effective and professional tool to develop a website. But do you need to use the best tool for your project? As a hobbyist artist, do i need to use the best brushes and ink, or should i just pick up a pen and draw whatever i feel like? I would most certainly become a better artist by using different tools to a certain level of proficiency where i can just pick the best tool for the job; but that's not always the point. If OP doesn't have a specific reason to learn a new language, don't. Use Lisp, FORTRAN or ASM for all i care is, all of them are *just fine* for every single project imaginable. Only the author of a project can know if a new tool is necessary to the execution of a project, and in programming there's this fetishism with picking up new languages as if they were yugioh cards. I believe this drives people away from actually enjoying their time as a programmer, it adds nothing to a hobbyist or professional, so unless you have a specific reason that drives you towards picking up a language, you most likely shouldn't bother.

>>12028 >in programming there's this fetishism with picking up new languages as if they were yugioh cards Most criticisms in this vein seem to come from weariness with the framework mania of webdev*, where everything is new but none of the features are. No one is criticized for learning Lisp or Prolog or APL just for the sake of it, as well as it should be - you don't learn those because they're FoTM, you learn them to think differently. Learning Haskell to think declaratively is very different from learning PHP because some new framework uses it. If OP wants to get straight to making a project, your point stands, but there is intrinsic value in learning different styles. *this being the worst case of a general hype malaise in programming >this drives people away from actually enjoying their time as a programmer I really enjoy figuring out how to solve problems in different ways. Maybe you're more hands-on and only satisfied if you're working on an immediately useful project, but I like compilers and interpreters and weird languages. >it adds nothing to a hobbyist or professional Even after only reading "The Little Schemer", my C++ became much cleaner. The difference was night and day. I sometimes got 20 line examples from my teacher and turned in a 5 line equivalent. >But do you need to use the best tool for your project? You certainly shouldn't use PHP because it "just werks" and it's "industry standard" and there's lot of libraries. You'll have security holes and fill your brain with bad habits and pointless edge cases like T_PAAMAYIM_NEKUDOTAYIM instead of actually building something new. No matter which way you go, you'll be faced with a huge amount of options and a never-ending grind of doc-reading. You chose Python for webdev because it's a simple language? Which framework do you choose: Django, Flask, CherryPy, or py2js? The most you can do is to learn new paradigms and select a sane one for your problem domain so you don't write a slow, buggy interpreter for half of the right solution (re: "Greenspun's 10th Rule"). You can't do this if you only know one language or paradigm, if your only tool is a hammer and every problem is a nail.

>>12031 >I really enjoy figuring out how to solve problems in different ways. Maybe you're more hands-on and only satisfied if you're working on an immediately useful project, but I like compilers and interpreters and weird languages. Then you have a reason to pick up a new language. See my point? Op doesn't seem to have any justification for picking another language other than the fact that "maybe i should?". My point is that you should pick it if you want, but if you want it, you already have a reason to pick a new language. If you're fishing for justifications, maybe you shouldn't worry about a new language, since clearly you have no implicit need for it. Once again, imagine a hobbyist painter. Would it make his art better to use different brushes? Yes, definitely, each brush has it's own particular set of qualities. But not everybody is necessarily trying to be better, and unless stated, nobody can know. If someone randomly asks "should i buy a graphics tablet?" my answer will be obviously "no, don't waste your time, have fun making art, if you ever feel like making more polished digital art, you'll naturally know when to buy one".

>>12032 OP's question is specifically about noncommon languages, the niche ones overlooked by the continuous hype train (NoSQL! FP! Electron!). I wasn't "born" a PL nerd. It happened over time, all going back to some kind soul linking me to Paul Graham's essays on Lisp. One thing led to another thereafter. Programming languages don't have to be shiny trinkets, something to learn and put away once the Next Big Thing(tm) comes along. Saying that a new language is like a new paintbrush for a hobbyist painter is a category error - with an interactive platform like Emacs where users and developers are one and it's easy to make real contributions, the language and environment are the hobby. Lisp was the first language I learned for its own sake (okay, it was Scheme first, but it translated directly into CL), and I still keep coming back to it. If you live in the mainstream proprietary ecosystem, obviously you'll want to be more jaded about a new tool because it might be shut down or go unmaintained without being extensible or because it's effectively an advertisement for a profit-driven ecosystem. Just because you don't have time for all the languages doesn't mean that you shouldn't learn new ones for their own sake.

>>12033 I see your point, never saw a language as a hobby within itself.

>>12023 >compile time garbage collection (can statically verify that there's only stack allocation at run time), Do you know of any papers on how they achieved this? I would love to work a similar feature into my pet project at the moment :)

>>12035 It's a little intimidating.

>>12036 Indeed! I might skip to the code instead. >>12023 > I've been thinking about learning K so I can work in that area. I already know some APL (I'm the one who posted the question about point-free composition in the APL thread), so I can't imagine it being that hard to learn. Is it hard to break into the field? I'm not in the field. I worked for a year in cloud security (more interesting than it sounds) and had to learn Erlang for the job. A few people at the job had moved from finance, and after I left a few people moved into finance. Learned that from looking at some main city job postings and asking around the people I knew.

>>12037 It might be the region-based memory management papers which showed how to assert pure stack allocation at runtime. Mazur's CTGC sounds more like conventional generational GC without the need to stop the world to prevent memory locations from becoming unreachable because it does lifetime analysis at compile time. You can find all the papers here: https://mercurylang.org/documentation/papers.html I wonder what they're using Erlang for in HFT. Managing clusters of high-performance ASICs to make sure they never go down?

>>12038 Good catch. Looking at the abstracts for the RBMM papers it ooks like a lot of them provide specific optimization benefits for Mercury's backtracking -- my guess is a language without said backtracking wouldn't see much advantage over using the GC they tested against, Bohem GC.

>>12003 Too bad ghc takes centuries to compile.

>Whats your reason to learn haskell/erlang or other noncommon languages, are they better? I take this advice to heart: 19. A language that doesn't affect the way you think about programming, is not worth knowing. http://www.cs.yale.edu/homes/perlis-alan/quotes.html There's plenty of good advice there, but I want to focus on these as well: 8. A programming language is low level when its programs require attention to the irrelevant. 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. People usually interpret this and more to point mostly at Lisp, but I think APL is a better solution, which is partly why I learned it. >Will they work at every platform? If you choose a language with a good standard and plenty of implementations, or even just one good one, it should. The C language is mostly as portable as it is because of just two implementations, whereas other languages have dozens that achieve a similar or larger spread. >Or just self challenge? It's in the spirit of hacking to challenge yourself. Why not learn a new language, so long as it will teach you something and change your ideas about programming? >sometimes i want to learn some of these langs but i cant find really good reason to start, also probably i cant find job with em in my country and maybe little bit feels like waste of time? Or just these languages doesnt suits me? It's been almost two years. If you're still here, how has that gone for you so far? I don't worry about getting a job with any language I know, but that doesn't mean there aren't jobs available. I wouldn't learn a language solely to get a job, though. Have you managed to find such a language that does suit you?

A few months ago learnt erlang in order to work on a personal project of mine that could benefit from the concurrency and high availability features it offers. Erlang is great to work with and provides you with all kinds of tools needed to increase your productivity. Personally I find the syntax very nice and minimal. The language is verbose enough to be readable without being annoying and the functional programming style, as presented by it, was easy enough to adopt to and easy to bypass when needed. Dynamic typing can be an issue, but type specs and dialyzer are very helpful. Regarding platforms, it can run on most unix-like systems (and OS X), Windows and even Android. Job wise as it makes no sense learning this language for me, since it is very unpopular in my country. Maybe one can find remote work, but I have not looked at it. This is same because this is a very pleasant language to program in.

It gives you a more complete view of programming. Every single turing-complete language is just a different representation of the same thing. The more languages you learn the more you see the constants between them. You go from thinking in code to thinking in general computation, making you a much better and much more adaptable programmer.

>>10934 >A good example of a language like that is ATS: http://www.ats-lang.org/ . Or just watch https://www.youtube.com/watch?v=zt0OQb1DBko Funny how the guy in the ATS's thread tells one to not watch this video.

>>6526 >Will they work at every platform? sadly, no https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html I like haskell, but it really only works on x86 cross-compiling is possible, but they don't have haskell directly on arm64 that should be fun soon when ARM based Macs drop I guess they all have to switch to Dell

I'd love to use Lisp in the programs I write normally but the performance is nearly Java-level, which is like kicking dead whales down the beach so I stick to C++ or C for the most part

Don't know why but Haskell is so beautiful to me I just waste all my time implementing things in GLOSS that would take a few minutes in openFrameworks

>>10258 Show me C code that can freeze my system and I'll produce a Python equivalent.

>>12075 Nobody says you should compile it on your year 2000 cellphone, Pradesh

As a programming language designer, the uncommon languages are some of the more interesting ones out there. Take Idris for example; it's similar to Haskell, but adds support for dependent types, and in its second version, linear types. Its type system makes it possible to encode assertions about the validity of a types values into the type itself. printf can be written to have compile-time assertions about the validity of its format string and arguments with this. That said, uncommon languages like this tend to have niche use cases compared to the more common ones. Designers of the more common ones take inspiration from them, so they can be used as a learning tool to pick up concepts that may appear elsewhere in the future.

>>22374 You can write type-safe printf in Haskell too. https://hackage.haskell.org/package/typelits-printf-0.2.0.0 Also Idris isn't really a niche language. It is a general purpose language, just not as popular as Haskell or, say, C.

>>22375 I'm sold on this board if I can get a quick, informed response like this here. >You can write type-safe printf in Haskell too. It'd be more accurate to say it facilitates writing such a function, I guess. https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c115292 >Also Idris isn't really a niche language. It is a general purpose language, just not as popular as Haskell or, say, C. Fair. Convincing people to learn and work with a language they're not familiar with when ones more people are familiar with fit for a use case isn't very easy to do though.

>>10934 how would you fix ATS strings? seems like the only serious thing in your list of problems or... is there any attempt at fixing that?

>>18847 why should we? according to him

>>10934 Just FYI F* >>>> ATS

>>22368 > Nobody says you should compile it on your year 2000 cellphone, Pradesh wrong board lainon

>>6526 >haskell I like mathematics and Haskell seems to bring me closer to program proofs and applications of algebra. I'm still learning but I hope my understanding is correct. >Elixir Very useful for server side.

>>22376 >>22375 You can do it in SML as well http://mlton.org/Printf However like >22376, it's more fair to say they facilitate writing printf. One issue you find in the Printf of say agda or idris, is that they are quite frail when you are dependent in the first argument of the function (if one wishes to abstract around a generic string). This is more of a Idris/Agda issue than a dependetly typed issue, as similar results can be had with dynamic information. For example in Idris, if one wants to have a safe string index, one has to get a proof that the length of the inputted string is say n. Now if you wish to index into the string n -5, you have to supply a proof that n > n - 5, and is thus safe to index into. in F* this is free as the SMT solver solves for it, and thus it's the standard way to index into the string https://github.com/FStarLang/FStar/blob/master/ulib/FStar.String.fsti#L88

>>6547 this post is over three years old, but this is a really common take that im really skeptical of. there arent a lot of transferrable skills between paradigms. if im an e.g. C programmer, and i learn a pure functional programming language, that doesn't help me write better C code at all. C doesn't provide any appliances for writing functional code, and it isn't entirely clear what it would mean to do so. at best it would just involve immutable state, but immutable state is a horribly inefficient abstraction when the compiler isnt turning it into mutable state under the hood, and C code that is scared of mutable state will always be less performant and less readable than regular, well-written C code. at worst it would involve the programmer reimplementing higher-order functions to make their code mode functional-y and it would end in a tsunami of functional spaghetti. ditto for trying to transfer functional ideas to any other predominantly imperative language. functional programming is an objectively worse way to write code when there isn't a really complicated compiler to turn it into well-designed !!imperative!! machine code with !!mutable state!!. if you're writing imperative code it is objectively worse to be reallocating copies of arrays and other data structures constantly to maintain immutable state, when you're only going to destroy the original afterward anyway. that isn't to say all these ideas aren't valuable, functional programming is a great and unique and elegant way to model solutions to problems! but these ideas are certainly not valuable outside of their own sphere. in python, several of the container types have emulated higher order functions defined on them as methods, but chaining several of these together in the middle of otherwise imperative code will always be less readable than the imperative alternative, because you can't (really) write pure functional python, and mix-matching paradigms is always less readable. the only imperative language into which you can readily transfer the skills you learn in functional programming is rust, which is only because it is already a nightmare hodgepodge frankenstein's monster of ideas from ten functional languages chained to the back of C++. it was specifically designed for this. thats the main thing: if a language was designed to make functional code not objectively less performant and readable, then you can transfer functional ideas to your use of it. but almost all of the languages that do that are the functional languages. you're gonna have a really bad time trying to transfer any of those skills to go, for instance. write code in a given language using the idioms of that language. don't try to force the language to adapt to you using the idioms of another language. if you want to write haskell code, write it in haskell, not C.

>>27184 > there arent a lot of transferrable skills between paradigms. if im an e.g. C programmer, and i learn a pure functional programming language, that doesn't help me write better C code at all. C doesn't provide any appliances for writing functional code, and it isn't entirely clear what it would mean to do so. > the only imperative language into which you can readily transfer the skills you learn in functional programming is rust Well there are techniques in functional programming (note that aren't necessairly functional themselves) that would transfer over quite well. A very obvious example is pattern matching, you can simulate it with tagged unions. See the image above on how to do that. What this allows you to do is more formally break down problems. This technique has already seen itself adopted into Java (next vesrion), Python (next version), C# (next version), and Rust. None of these languages are functional. I'd like to go on a broader point about OO languages in particular. If you've ever hung out around the OO crowed they typically praise SOLID and design patterns for good reason. Using the tools that Java provides and how the language encourages you to program is negative. You have to beat new people to OO with SOLID and even then it's not clear cut as the L in solid is not computable [1]. What functional programming allows one to do is side steps the issues of OO, as you'll nature obey SOLID and in trying to map down to languages like Java you'll naturally write better OO code without falling into the traps that native java kids would fall into. This is not even to mention the more functional flavor people write these days with preferring breaking big hairy imperative loops into more state concerning maps. > at best it would just involve immutable state, but immutable state is a horribly inefficient abstraction when the compiler isnt turning it into mutable state under the hood, and C code that is scared of mutable state will always be less performant and less readable than regular, well-written C code. > ditto for trying to transfer functional ideas to any other predominantly imperative language. functional programming is an objectively worse way to write code when there isn't a really complicated compiler to turn it into well-designed !!imperative!! machine code with !!mutable state!!. if you're writing imperative code it is objectively worse to be reallocating copies of arrays and other data structures constantly to maintain immutable state I don't think you know how functional compilers nor how normal compilers compile functional structures. Functional compilers actually don't compile functional data structure into imperative ones. It can't do that safely without some form of linear logic, so only Rust, ATS, and Idris can with only really ATS doing this via tail allocation and other tricks. Further some compiler like OCaml are not optimizing but still preform quite well. Further an interesting observation is that imperative languages compile their code into a functional form, as the mutation of variables makes it harder to pick registers. I would also like to mention that your idea of efficient data structures also misses the mark quite a bit. Although it is true functional data structures in a sequential environment might takes a slight performance hit (This hit is typically quite small as to it not mattering unless you are talking about the hot loop of your program), for most applications this simply does not matter. Further, functional programmers expect their data structures to do a lot more, namely they need to be able to persistent (linear style logic can actually do an automatic transformation, but as stated previous functional compilers don't do this currently), which means that if you need to have many differences of the structure, an imperative data structure would not simply do as you'll end up with deep coping every time you want a difference or typing to cobble together a difference log. I brought up sequential as if you want your data to properly cope in a concurrent environment functional data structures have massive advantages so you don't end up with inconsistent data. The might of the original sentence is also important here, as there are many examples of "functional" data structures in an imperative world. We can see this with Java Streams, C people when they implement basic linked lists, Optionals in Java (if we count optionals as functional), strings in Java, etc. > but chaining several of these together in the middle of otherwise imperative code will always be less readable than the imperative alternative, because you can't (really) write pure functional python, and mix-matching paradigms is always less readable. > thats the main thing: if a language was designed to make functional code not objectively less performant and readable, then you can transfer functional ideas to your use of it. but almost all of the languages that do that are the functional languages. I think another confusion that you are having is that functional code is not a binary choice, often it is (if we take the conservative sense of the word) about factoring state into smaller portions and scopes of your program. This allows state to be less ubiquitous which has the benefit of reducing the cognitive load as you don't have to worry about some state you mutated earlier in scope. Further all functional languages allow imperative code and they do quite well. OCaml has Refs and imperative structures. They are typically used less on the basis that they are harder to read and reason about. However when an imperative algorithm will do they are used. Thus the only reason why this code is less readable is not due to mixing paradigms but due to the inherent nature of imperative structures reducing proper control flow and creating a greater scope of concern. Python people already use some functional ideas as is, their beloved list comprehensions are just a mix of map, filter, and the applicative/monad. They do prefer using this over loops even! Now I'd argue that list comprehensions are not very readable due to making properties of these HOF very hard to discern. I can go on about functional structures (like streams) in python, and how adding more wouldn't make it less performant. > you're gonna have a really bad time trying to transfer any of those skills to go, for instance. write code in a given language using the idioms of that language. don't try to force the language to adapt to you using the idioms of another language. if you want to write haskell code, write it in haskell, not C. I hope you can see now where functional ideas have their place and where they are starting to take over. There are many other arguments I can make, but I'll leave it with this. One should learn to think in a higher level languages, currently the functional languages along side lisp facilitate this the best. Then one should learn to map down to a low lever languages like Java if their job requires that, this allows you to write better code for free and use the language in a more straight forward way than those brought natively up on it. [1] http://okmij.org/ftp/Computation/Subtyping

>>27184 It's less about gaining new skills, and more about gaining a deeper understanding of the ones you already have. Doing the things I already knew in C++ in Haskell and Clojure gave me better insight into the underlying concepts of programming. I think about my code at a higher level now, and it's made me a much faster and more reliable overall programmer.

>>27185 is this Modern Compiler Implementation?

>>27198 Yeah, Blue Tiger vs Red Tiger Vs Green Tiger. Note this is using haskell and not SML like the book uses for the Blue Tiger.

People choose these esoteric languages to reduce lines of code. More visual compactness =/= more productivity. I'm not sure how much time one actually saves since there is increased difficulty of formulating solutions to problems in less natural languages. Sure, more keystrokes might be required to type out a C program than a Haskell program, but I type about 50 times faster than I can think. Solutions in an imperative language are intuitive and not buried beneath layers of abstractions or confusing syntax as in functional languages. It's easier to hand poorly-documented code to another human being and have them understand it if it is more concrete and straightforward; likewise, it's easier to dust off old code and remember what is does. I don't know where people got the idea that typing lines of code is the most time-consuming part of programming.

>>27209 I'm not sure what you mean exactly. Haskell solutions aren't necessarily less lines in general. Often we do things like qualify imports and have clean layers. What I'm confused about is why you think that the main benefit is mainly in LOC. One of the stronger points of Haskell is the type safety and how easy it is to see how lines compose. Likewise people use map, filters, applicatives, and monads because they are much easier to read and reason about than a for loop. Especially as functions get long imperative code it becomes impossible to read loops as one has to concern themselves of what local state is being changed. It is thus much easier to think of what the code is doing with proper types (types give away the shape of data) and more meaningful functions. Further I don't see why you would consider functional langauges and the like "less natural languages." then imply that C is more natural. To me it feels like you grew up on languages like C and thus have internalized the idioms. After playing with functional languages and having to stop caring about state changing all around me I've found reading more "natural languages" to be much harder as they make understanding the flow of data and properties about any particular piece of code very hard.

>>27209 Having functions for doing frequently used things is, in my opinion, a lot easier to read than a for loop that can do arbitrary things. For is like a goto, except a little different. Let's say you're running map (1 +) somelist , here you know that all this code does is get you `somelist` where all numbers are incremented by one. int arr[foo] = { ... }; int newarr[foo] = {0}; for (int i; i < foo; ++i) { newarr[i] = arr[i] + 1; } Here, you need to keep track of what foo is, what the loop does, when it stops.

>>27234 I'm not talking about basic functional programming, I'm talking about more advanced features that reduce the intelligibility of programs. An abstraction is only good if it both simplifies code and makes it easier to understand. I might change my tune if I actually took the time to properly understand advanced functional programming but it seems to me like it takes something very simple and wraps it up in graduate-level mathematics for a small or non-existent gain in productivity.

By the way, I'm not trying to be inflammatory, I'm just venting frustration because I programmed so much, it injured my neck and I have chosen functional languages as the target of my anger.

>>27239 Well, that explains the tone of your post. Would you care to provide examples of abstractions or features that you've struggled with? I sense a profitable discussion there. In a sense, an abstraction is a necessary evil - it's better than the alternative, because it's supposed to come in when the complexity is too large to handle. Of course, once you get comfortable using an abstraction and thinking in terms of it, you'll want to use it all the time to make your code more general, terser and more readable (to you). This has the frustrating effect that you describe, where to a programmer with a different background the code instead appears opaque and confusing. I've felt this way many times when dealing with GUI/TUI toolkits and other such complex libraries: often, their interfaces (and documentation) are expressed in terms so abstract and far removed from the problem domain that it is harder to figure out how to use them than it is to use a more low-level library and build your own abstractions on top of it. >it seems to me like [functional programming] takes something very simple and wraps it up in graduate-level mathematics for a small or non-existent gain in productivity This is a good point. FP (and Haskell in particular) has a reputation for this, and for a good reason. But, as we know, usually the concepts are not as complex as they sound - it happens, instead, that it is often the simplest and most pervasive concepts that are the hardest to grasp. This ties in with a paper by Sussman that I read recently, about the legacy of computer science - maybe identifying and naming these pervasive concepts, such that they can find their way into mainstream thought, will be the field's most meaningful contribution.

>>27236 > I'm not talking about basic functional programming, I'm talking about more advanced features that reduce the intelligibility of programs Idk about those but I love basic FP, map, reduce, remove-if, etc are almost always what I think of when I need to iterate in my hello worlds

I usually see programming as a necessary evil to create results I love Haskell is the only language I actually love for its sheer beauty and just programming it is a bliss, however I'm not intelligent enough to get good at it

>>27296 I feel the same except for the last part.

I'I originally learned Haskell for an absurd reason, that being, someone had suggested that to improve at metaprogramming in C++, you should learn Haskell or some other functional language, since templates are a functional language. This advice I think is pretty ridiculous, just due to the fact that picking up a language in such an alien paradigm just to improve at one marginal aspect of C++ is probably not worth it. Tangentially, you experience the same funny phenomenon in template metaprogramming as you do in languages like Haskell, when programs compile, they tend to just work the first time. It's a startling experience when you're used to writing languages like C++ or C. That being said, I'm glad I learned Haskell and I could still recommend it for other reasons. There are some things these languages (like Haskell), in my experience, are much better at doing. By better, I mean that it is easier and less error prone to do things in these domains in these languages than in others, and this allows you to spend more time making your solutions more general and complete. In my personal projects I essentially exclusively use Haskell and C++, when C++ is not necessary I will use Haskell. It's a very simple language to program certain things in. I prefer C++ when writing numerical mathematics and Haskell when writing symbolic mathematics, since ADTs and other features make Haskell generally much simpler from my experience to work with symbolic mathematics in. My preference for C++ in numerics is just that when I want a program to be performant I like to be able to reason about what exactly my code will do on the machine, to some extent, and with numerics I am often concerned with performance. One of the things about languages like Haskell specifically, which uses concepts from category theory, I am unsure about is the educational benefit to interacting with these algebraic concepts. On the one hand, it initially seems like a great practical exposure to ideas like functors, monads, and so on, but in practice I think people get a very hazy and improper understanding of these concepts. If I were going to give someone a great prototypical example of a functor, I would like to give the example of a singular homology group of a topological space, because it shows the utility of functors. You've turned a very general object into a somewhat simpler one, an abelian group. You can study the group and due to the functoriality of the association you can distinguish objects by distinguishing their (simpler) images under the functor. It's very difficult to motivate and explain category theory if someone has no prior exposure to algebra, and Haskell will not provide that exposure to algebra. Because of this, the teaching of these objects in Haskell suffers, and you find monads, functors, and other objects explained via intuitive analogy. There's nothing wrong with intuitive analogy when it fits the situation, but when its used too much as a crutch, the exposition becomes very vague and unclear. I've heard functors described as "a computational context", I don't blame any beginner or person learning Haskell who has never heard of a homomorphism if they find that entirely opaque. I feel that oftentimes this way of learning produces confusion and borderline mysticism in people.