6 ms·

Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?

by tobr 7y ago

7thaccount 7y ago
Julia is pretty good at this. Immutability is the default with functional composition. It is primarily intended for numerics though.
xenihn 7y ago
Swift.
ummonk 7y ago
JS with React is great if you use an immutable data structures library and compose functions.
- deckard1 7y ago
  ES6 and newer JS is a great functional language. That said, I do not recommend immutable libraries. Here are the reasons: 1. They provide false comfort. Nothing in JS is truly immutable. People are just going to end up breaking the rules (purposely or inadvertently). 2. Boxing and unboxing regular JS objects becomes a pain in the ass and a maintenance horror show. You'll never know what an object is and you'll have to jump through countless hoops to get plain old JS objects to do anything with anyway. Much better is to educate developers, and make sure code is properly reviewed before merging. Immutability doesn't need to be built into the language. Code customs and practices can go a long way.
ISO-morphism 7y ago
This is Clojure. It's functional, but more as a side effect of focusing intently on simple, immutable, persistent data structures and their compositions. I'd strongly recommend looking into it, along with many of the presentations by its initial author Rich Hickey.
- BoorishBears 7y ago
  Imo no Lisp variant can claim to not be in the "dorkier" side of things ("dorkier" being read as "hard to approach" in my eyes). I'd say Kotlin over Clojure.
  - adamkl 7y ago
    I’d suggest you watch Rich’s talk “Simple made easy”. [1] It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allows you to write code that is much simpler to reason about. I have no particular beef with Kotlin (or most any languages... right tool for the job and all), but I have lately become infatuated with Clojure and many of Rich’s viewpoints. [1] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
    - BoorishBears 7y ago
      Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day). This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems. Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in this context, it's harder because Clojure syntax uses parenthesis. Like that's literally it. Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity. I think a lot of developers feel "It looks funny" is not a fair critique of a useful tool, but just look at Erlang vs Elixr. I love Erlang, much more than I like Elixr, but Elixr gained mind share in large part because it's Ruby-like. Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about
whiletruu 7y ago
Elm.
vereis 7y ago
In my opinion Erlang (and by extension Elixir) are functional-ish languages that are at their core very pragmatic about not being too _dorky_.
swamp-agr 7y ago
Haskell.
tempguy9999 7y ago
What is 'dorky' WRT functional programming?
- c256 7y ago
  Offhand, I’d say “too much theoretical math in the starting and middle stages of mastering the language.” Syntax that is based around/descended from APL. Lambda calculus prominently featured in the learning process. Things like that. It’s definitely a feel argument, and thus highly subjective.
  - Multicomp 7y ago
    I'm not a FP expert, but I do try to use FP as much as possible and yes, I agree that there is some serious dorkiness possible with certain PLs. Anecdote, not data, but I've found that Rust, Erlang, and F# (if MS stack) tend to be in the sweet spot of expressive enough without drowning in symbols, without being as mushy as, say, Python/Ruby/pick something.
soulnothing 7y ago
Kotlin for me. Val is immutable and they differentiate collections, i.e. list vs mutableList. This is still hampered by the JVM but it works. Combine that with multi platform productivity. If you do want to get dorkier there are fully functional libraries.
pkolaczk 7y ago
Scala / Dotty, or its smaller brothers like Kotlin or Swift

Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?

by tobr 7y ago

Is there a language that leans heavily towards immutable data, but steers clear of the, shall we say, dorkier side of functional programming?

7thaccount 7y ago

Julia is pretty good at this. Immutability is the default with functional composition. It is primarily intended for numerics though.

xenihn 7y ago

Swift.

ummonk 7y ago

JS with React is great if you use an immutable data structures library and compose functions.

deckard1 7y ago
ES6 and newer JS is a great functional language. That said, I do not recommend immutable libraries. Here are the reasons: 1. They provide false comfort. Nothing in JS is truly immutable. People are just going to end up breaking the rules (purposely or inadvertently). 2. Boxing and unboxing regular JS objects becomes a pain in the ass and a maintenance horror show. You'll never know what an object is and you'll have to jump through countless hoops to get plain old JS objects to do anything with anyway. Much better is to educate developers, and make sure code is properly reviewed before merging. Immutability doesn't need to be built into the language. Code customs and practices can go a long way.

ISO-morphism 7y ago

This is Clojure. It's functional, but more as a side effect of focusing intently on simple, immutable, persistent data structures and their compositions. I'd strongly recommend looking into it, along with many of the presentations by its initial author Rich Hickey.

BoorishBears 7y ago
Imo no Lisp variant can claim to not be in the "dorkier" side of things ("dorkier" being read as "hard to approach" in my eyes). I'd say Kotlin over Clojure.
- adamkl 7y ago
  I’d suggest you watch Rich’s talk “Simple made easy”. [1] It’s one of his main points that something like a language being “hard to approach” can be overcome by spending a little effort to learn it (as opposed to sticking with something like Kotlin just because its easy to pick up because it’s familiar). The benefits of learning the unfamiliar (in his case, he’s speaking specifically about Clojure) being that it allows you to write code that is much simpler to reason about. I have no particular beef with Kotlin (or most any languages... right tool for the job and all), but I have lately become infatuated with Clojure and many of Rich’s viewpoints. [1] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
  - BoorishBears 7y ago
    Eh, I've used languages that were "hard to approach", one of my favorites (Erlang) is one of those (I use quotations especially because learning all of Erlang's syntax takes about a day). This is a misapplication of the presentation really. It speaks to a level above selecting a language and is really about the design of systems. Picking up Kotlin or Clojure is not "harder to approach" by virtue of what's provided in this context, it's harder because Clojure syntax uses parenthesis. Like that's literally it. Clojure with the same exact constructs represented with more C-like syntax would, at the level the presentation speaks to, allow the same level of simplicity. I think a lot of developers feel "It looks funny" is not a fair critique of a useful tool, but just look at Erlang vs Elixr. I love Erlang, much more than I like Elixr, but Elixr gained mind share in large part because it's Ruby-like. Cognitive overhead is lower working with a language that at least "looks like", what you're used to, and more developers know C-like languages, thus a language like Kotlin is "easier to approach" but necessarily "easier" in the way the presentation talks about

whiletruu 7y ago

Elm.

vereis 7y ago

In my opinion Erlang (and by extension Elixir) are functional-ish languages that are at their core very pragmatic about not being too _dorky_.

swamp-agr 7y ago

Haskell.

tempguy9999 7y ago

What is 'dorky' WRT functional programming?

c256 7y ago
Offhand, I’d say “too much theoretical math in the starting and middle stages of mastering the language.” Syntax that is based around/descended from APL. Lambda calculus prominently featured in the learning process. Things like that. It’s definitely a feel argument, and thus highly subjective.
- Multicomp 7y ago
  I'm not a FP expert, but I do try to use FP as much as possible and yes, I agree that there is some serious dorkiness possible with certain PLs. Anecdote, not data, but I've found that Rust, Erlang, and F# (if MS stack) tend to be in the sweet spot of expressive enough without drowning in symbols, without being as mushy as, say, Python/Ruby/pick something.

soulnothing 7y ago

Kotlin for me. Val is immutable and they differentiate collections, i.e. list vs mutableList. This is still hampered by the JVM but it works. Combine that with multi platform productivity. If you do want to get dorkier there are fully functional libraries.

pkolaczk 7y ago

Scala / Dotty, or its smaller brothers like Kotlin or Swift