Also, its very strange to see these concepts illustrated with Javascript. I imagine thats something like trying to learn Chinese using the roman alphabet. Not that it can't be done, but a lot of important details are necessarily missing.
That would explain why C is still so prevalent, as opposed to being 'yet another language from the 70s' ;)
On my own, if you don't come from CS or EE background you hardly will get through HR.
NB I don't have a CS or EE background.
Without a degree very few companies will bother.
In France, Germany and Switzerland one should at very least have a technical experience level and written references from past jobs.
There is also the language barrier.
Not many accept working in English, and we had some customers from well known multinationals that only upper management was willing to use it.
Besides the degree, knowing multiple languages and soft skills really helps.
So basically, completely normal and reasonable? (see http://languagelog.ldc.upenn.edu/nll/?p=10554)
I think you're being sincere in expressing a common attitude within the Lisp/FP community, but it's an unfortunately limiting attitude. It would appear strange to an ancient Sumerian to see the Epic of Gilgamesh translated into English, but the translation is far more accessible and thus far more influential than the original.
I'm a front-end dev and I got into Clojure and Elm because of some books/libraries for functional programming in Javascript. It's doubtful I would've ever had enough interest to learn if no one in those communities made an effort to translate some of their concepts into a language that I already use.
well said!
(i'd have found es5 more accessible still.)
That's the way most front-end devs learn new things. People talk about FP attitude here, but it is no-www attitude actually.
Chinese kids learn chinese characters by learning the roman alphabet first. Primary-school kids in China learn pinyin, which then helps them to learn chinese characters.
I will say though for the exact cases you mention, they probably should be clear why this isn't exactly the concept as described.
Programming languages have procedures, not functions. (Yes, even Haskell. Consider the possibility of divergence.) Functional programming is a style that:
(0) Emphasizes values over physical object identities.
(1) Emphasizes procedures that compute functions - mappings from values from a domain, into values from a codomain.
(2) Discourages distinguishing between procedures that compute the same function.
Functional languages are languages that facilitate and encourage functional programming. Does JavaScript? IMO, it doesn't even do (0) very well, which is a precondition for discussing whether it does (1) or (2) well.
> garbage collector, persistent data structures
Don't conflate “purely functional” with “persistent”. Purely functional programming can deal with ephemeral data structures just fine - using substructural types. In the other direction, there exist persistent data structures whose implementation internally uses imperative assignment.
> powerful and flexible
Those are desirable qualities in a language, but they are orthogonal to whether the language supports functional programming.
> express all of these ideas in an accessible way
JavaScript doesn't even make it easy to talk about structurally equal values. Since everything is mutable, the only notion of equality that the language will actually respect is equality of physical object identities.
Without the ability to talk (soundly) about structural value equality, you can't formulate algebraic laws (e.g., the monoid or group laws), which is the basis for equational reasoning - one of the key benefits of programming in a functional style!
Haskell the language also knows nothing at all about invariants, and the language will happily let you make something a Monad even if it doesn't obey the right laws. The culture and libraries of course take invariants quite seriously, but some aspects of the Javascript culture also take invariants quite seriously, like Promises for example.
I would call Racket a functional language. Common Lisp? Nope.
> Haskell the language also knows nothing at all about invariants
I'm aware. But I'm not talking about mechanically enforcing equational laws. I'm talking about the ability to state them in the first place. For this, you need a sufficiently rich value language, where, for example, the list [1,2,3] is always the list [1,2,3] regardless of where it resides in memory.
In JavaScript, [1,2,3] isn't a list. It's an expression that, when evaluated, constructs an object whose initial value is one particular list, but its value at another point in time might be a different list. Furthermore, if you evaluate [1,2,3] twice, you get completely different objects. Although the objects are first-class, the list values aren't, so you can't (soundly) formulate any equational laws about lists. And object identities have an equational theory so weak (“everything is equal to itself and nothing else”) that it's completely useless.
The point is that I can reason about equality of ML and Haskell expressions in ML and Haskell themselves, with a few minor extensions (e.g., the usual laws of arithmetic, applied to pure `int` expressions), whereas reasoning about equivalence of JavaScript programs requires carrying out the entire reasoning process in a separate metalanguage. The latter is obviously far more tedious, which is why programmers have largely given up on actually reasoning about JavaScript programs, preferring testing as an alternative.
> Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition,
Equality testing (a runtime operation, only valid for types with decidable equality) is different from propositional equality (a type constructor on its own, which can be used on any type). See https://existentialtype.wordpress.com/2011/03/15/boolean-bli... for details. Haskell doesn't have a propositional equality type constructor.
> and cannot cope with equality on functions (I guess).
Indeed, and, in any higher-order language, this is a feature, not a bug.
I do not see how you can reason about Haskell in Haskell either, as this is a programming language and not a proof language (maybe I am missing something?).
> Haskell doesn't have a propositional equality type constructor.
This is what I meant. Since with both Haskell and JavaScript you will need to define a propositional equality, in my experience this does not help that much to have a better decidable equality.
http://www.haskellforall.com/2013/12/equational-reasoning.ht...
http://www.haskellforall.com/2014/07/equational-reasoning-at...
The reasoning is entirely carried out by replacing Haskell expressions with contextually equivalent ones.
> Since with both Haskell and JavaScript you will need to define a propositional equality
No, you need much more than a propositional equality to be able to reason about JavaScript programs. If you try to use Haskell-style equational reasoning on JavaScript objects, you can only pick between your reasoning being trivial (because every object reference is only equal to references to physically the same object) or unsound! So if you want a more useful notion of program equivalence, you'll have to use a separate logic (e.g. Hoare logic) or axiomatic system (e.g. Dijkstra's predicate transformer semantics) for reasoning about imperative programs.
Alas, not all CS programs are created equal. Many skip entirely over FP because it isn't 'what the industry does'.
Indeed.
And I don't like it at all. It seems as if everybody is afraid that web developers won't understand the concepts if they are expressed with mathematical symbols instead of JavaScript functions.
I just really sorely need examples in a syntax I understand.
You can use Hoogle (eg https://www.stackage.org/lts-6.9/hoogle?q=%3E%3E%3D) to look them up.
It's a bit daunting at first. But most code actually only uses operators from at most a few libraries. Once you understand Monoid, Applicatives and Monads and their operators, you'll be doing OK.
There are alphabetic names for their operators. But they are not used much---working programmers prefer the symbols. Alas, learning wouldn't be much easier with them either, because most of the work is in understanding the concepts. People would complain just as much about the cryptic names as about the cryptic symbols.
(The only mainstream library that really goes crazy with the symbols is 'lens'.)
I saw one of the problems was, that I had higher math in German and some translations aren't straight forward (monoid -> halbgruppe) so I often thought things I knew were entirely new concepts.
Yes, it's a bit of a shame that some things are so abstract that we can really give it good names. For example, the operation in the monoid is just any old operation that's associative. What name do you want to call that? I don't see anything that improves on the little Kringel that we make on the black-board, or the <> that Haskell uses.