Immutability. I didn't really understand the benefits of having immutable data structures until I tried building a service with no mutations whatsoever... and noticed I didn't get any weird, head-scratching bugs that took hours to reproduce and debug. That led me to go down the Functional Programming rabbit hole - thus changing my entire view on what code is/could be.
To add to this: functional programming. Getting rid of state in objects was a DREAM for me.
I used to think: come on you better than though hipsters... this shit looks ridiculous, and it isn't intuitive... There's no way it's worth it to learn. It's just the new fad.
First -- over a few years -- I had slowly started writing functional-ish code in Ruby on the backend and React/Redux on the front-end.
Ruby is kind of nice in that there's not an easy way to iterate over a list without functional code. You start mapping and reducing pretty regularly, and then discover the power of higher-order array functions, and how it lends itself nicely to functional programming.
React/Redux is nice in that it pretty much forces you to wrap your head around the way functional programming works.
React/Redux was definitely a step up from Spaghetti-jQuery for me, but I'd stop short of calling it an enjoyable experience. It wasn't until I started playing around with Elixir that I really fell in love with functional code.
In a lot of ways, Elixir is really similar to Ruby, which makes it pretty easy to dive in (for a Ruby-ist). But in subtle ways, its functional nature really shines. The |> is perhaps my favorite programming concept I've come across. It's so simple, but it forces you to think about -- and at the same time makes it natural to comprehend -- the way data flows through your application.
Don't get me wrong, Elixir is still very much a functional language. It's allure in that it looks like an imperative language and has a lot of similarity to Ruby is misleading.
The learning curve might not be as steep as say, Lisp, but it' still quite steep. And I think it'd take around the same time to be meaningfully proficient in either.
A "me too" for Elixir. Coming from a Ruby background, picking up Elixir wasn't hard at all (disclaimer: I have done some FP in the past). What I found really good about Elixir is the solid documentation[1], easy comparing of libraties[2], the mix[3] tool that made starting a project really simple.
But what really blew me away were doctests[4]. Basically I ended up writing my unit tests where my code was. That was my documentation for the code, so there was no need to maintain unit tests and documentation separatetly.
I wrote a rinky-dink Web application while teaching myself Ruby and Ruby on Rails. It turned out most of the pages were constructed from a database query returning a batch of results which then needed filtering, sorting and various kinds of massaging. I ended up really enjoying doing this work by applying a series of higher order functions like for() and map() to the data set. This got me started on thinking functionally.
Years later, I decided I wanted to do more with Lisp while continuing to work with the Java ecosystem. Clojure is a Lisp that runs on the JVM and is rather solidly functional. It's possible but very awkward to do mutation. If you don't want to run with shackles, you need to embrace immutability and FP. I found myself fighting FP until eventually I saw the light and was able to productively embrace it.
Here's a "me too:" I'm working on a small-ish Java application with a couple of former FORTRAN developers. Last Thursday we got a bug report from our integration testers saying that some data from earlier messages was showing up in later, unrelated messages.
Sure thing, the data buffers are objects being re-used with mutation rather than being built from scratch per new message. Immutable objects, or a kind of "FP light" would have made this particular problem impossible.
I feel like Rust has shown that mutability is ok, as long as you don't have both mutability and aliasing. Having a mutable object accessible from many places at the same time definitely is a recipe for bugs.
Some languages deal with this better than others through structural sharing, which reduces overhead significantly. The performance hit is usually unnoticeable in those languages and only becomes a problem in very specific cases ie. processing large strings, appending items to long lists, etc... some of those will cause you to rethink the way you do certain things (that is part of the FP journey).
In languages like JS or Ruby though, you might need to compromise. Generally I start with the immutable approach and refactor if performance becomes an issue.
I would normally agree, but Apple has a good track record of yanking out things that were considered crucial and turned out to be relics from the past in desperate need of innovation (or replacement). My optimistic prediction: the increased demand for wireless headphones will drive manufacturers to constantly improve their products and drop prices to remain competitive - two years from now, we won't even remember the day our phones had a headphone jack.
Oh we will. Because the people listening the most to music are musician, and they entire stack is linked by jacks. So they will carry adapters everywhere, one for thunderbolt, one for usb-c, and hate it.
I know I will, because I won't buy a new headphone in the next 2 hears, mine being very expensive.
That doesn't mean I think it's a bad move. The thunderbolt migration was a good move. Removing the floppy and the DVD player is a good move. And removing the jack it probably one.
I actually look forward for the day where my phone, laptop and flatscreen only have USB-C port as input and ouput.
But it will be annoying for a while, and way more than 2 years.
Espacially since wireless headphones are a f*ing pain to use.
Do you recommend any framework for Haskell web development? I really liked toying around with the language, but I hit a brick wall when trying to build something "real" with it - it's hard to find decent guides that made the jump between the basics of writing functions, using recursion, etc and using the language on a full-on application.
Given I have been working with web development in Ruby and PHP for years, I would love to find a nice "getting started" guide for a good/well established Haskell framework.
Great news, good work guys. I've been following Padrino for a few months now and it's by far my favourite Ruby framework - I find it to provide a very elegant and powerful layer of functionality on top of Sinatra. I really hope it gets more recognition and a bigger/more active community as IMO that is the only area where Rails is unquestionably better. Congrats again on the new release - looking forward to 1.0!
[edit: spelling]