peerreynders

peerreynders

He is a bit of a “rebel for the static strongly typed pure functional cause” - and even though he makes some good arguments that isn’t going to stop me from referring to work like that from Pierre-Yves Saumont if I should find myself trapped in Java-land (for whatever reason) anytime in the future.

I would argue that “functional tactics” in imperative languages are ultimately more effectively wielded by developers with experience with “real functional languages” - but never(, ever, and not even close) to the full effect and impact of actually using a “real functional language” for the task at hand (which ultimately is one of the points that Erik Meijer is making).

[quote=“mkunikow, post:20, topic:1771”]
You will always need to deal with state and side effects. But there should be clear separation in code: pure functions vs rest.[/quote]

In the Clojure community it is often said that good functional design “pushes the [impure aspects] to the edges of the system”‡ - leaving the core logic pure and minimally “complected”.

‡I seem to recall David Nolen using that phrase fairly regularly in his communications.

1
Post #21
kostonstyle

kostonstyle

Now I am very confused about what is functional programming. I feel, none languages out there support pure functional and a language can never be 100% perfect.
So close the eyes, do something greet with elixir, I really love the language. :grin:
And elixir contributors, your guys do amazing work, thanks so much.

0
Post #22
StefanHoutzager

StefanHoutzager

concerning static + strongly typed he is not an envangelist acording to what I read: https://www.ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04meijer.pdf

0
Post #23
peerreynders

peerreynders

  • 2007 - LINQ
  • 2009 - Reactive Extensions
  • 2011 - “Static Typing Where Possible”
  • 2013 - RxJava
  • 2014 - (PHP) Hack
  • 2014 - “The Curse of the Excluded Middle”

Interpret that timeline whichever way you seem fit - but he always struck me as a person who can be pragmatic when it suits him - at the same time he never seems to lay off his “learn Haskell” campaign (and that the type system needs to identify side-effects). So he may not be an “evangelist” but he has never been afraid to voice his strong opinions.

Erik Meijer: One Hacker Way (GOTO 2015)

The Original: The Hacker Way (A Rational Alternative to “Agile”) (Reaktor 2014)

Open your eyes and watch the Scott Wlaschin video I linked to above - you’ll likely need to watch it in pieces and multiple times because he covers a lot of ground in that hour.

If you’ve read Programming Elixir you’ll probably be familiar with this tweet:
https://twitter.com/jessitron/status/333228687208112128

Lots of her videos are available on the Web but you may find this one helpful to start with:
Jessica Kerr: Functional Principles for Object-Oriented Development (GOTO 2014)

@vasspilka already made a good start for you on the “purity” aspect but as simple as it may seem on the surface, the implications go quite deep. The programming language you choose is like a carpenter’s toolbox - even if it is stocked with the best tools available there is no guarantee that you will be crafting only “top of the line”, “world class” cabinets - that part is ultimately up to you and your (developing) skill.

Elixir can’t stop you from writing Spaghetti Code - that responsibility ultimately rests with you.

1
Post #24
StefanHoutzager

StefanHoutzager

I have seen that youtube item from Erik Meijer before. Strong opinions indeed, but I can understand his problem with the agile / scrum hype / industry. Interesting subject by itself. Even people like Dave Thomas have a problem with what has come from his work, although he is more subtle (see youtube). IT Guru Simon Wardley has said interesting things on the subject also, see this great presentation https://www.youtube.com/watch?v=Ty6pOVEc3bA or read Bits or pieces?: Why Agile, Lean and Six Sigma must die ....
Nice one on scrum: Anti Agile: Day 1: Why I hate Agile methodologies

1
Post #25
Onor.io

Onor.io

A lot of that depends on how one defines “pure”. If a program did exactly the same thing every time it was run there wouldn’t be much point in running it more than once would there? A program has to have some side-effect to be useful. Side-effects aren’t inherently bad; uncontrolled or accidental side-effects are the problem.

Stop looking for absolutes. Few things in life are always right or always wrong.

2
Post #26
Qqwy

Qqwy

TypeCheck Core Team

Yes, the definition of ‘pure’ is a difficult one.

There is no true 100% pure language (that works and is used in practice; Lambda Calculus itself is pure, but you directly run it on hardware), if only that the languages that for the most part are pure, have some ways to cheat (for Haskell: unsafePerformIO).

Haskell, for instance, archieves purity by allowing programmers to pass on the ‘IO baton’ from one side-effectful action to the next. This ‘IO baton’ can therefore be considered ‘the state of the whole von Neumann computer this program runs on, as a whole’. In this way, one can still consider these side-effectfull actions to be pure, from the viewpoint of the programmer (and of the language).

Of course, what happens behind the scenes is not important in this case, as long as the end result is that we can show ‘look! when you would call this function again with the same input, you would indeed get exactly the same output’.

2
Post #27
gregvaughn

gregvaughn

In the style of Joe Armstrong, I’m going to bring physics into the discussion. “Pure” computation exists only as a thought experiment. Once you execute on a physical computing device, you cannot ignore physics. Hardware fails; a cosmic ray may flip a bit it memory, etc. However rare these may be, they are non-zero probabilities. A “pure” computation run on physical hardware may return a different result when run again.

This bit of brilliance led to supervisors for when you need truly robust systems. And IMHO is a core bit of the difference between computer science and software engineering.

That said, it is still wise to isolate side effects to one/few places in code. The IO monad is one way of doing that. It’s one that appeals to the theoretician more than the practitioner though.

3
Post #28
Qqwy

Qqwy

TypeCheck Core Team

You hit the nail right on the head! I couldn’t agree more with what you’ve said. It was i believe last friday when an interesting exploit on Android phones was published, which alters the state of the software by exploiting a physical hardware peculiarly.

1
Post #29
— All posts loaded —