I think for the crowd you described, why not use Prolog? Prolog's idea is very much like what Math is to me (I only have a undergrad math degree, so don't count what I think is by any means absolutely correct)- here are some truth/axioms, can you deduce further theorems, and give result whether certain statements are true or false.
As far as I can tell, doing production work in Prolog would be an order of magnitude more difficult than doing production work in Haskell. This is just a guess, as I only have experience with the latter. This is similar to the reason we don't use Idris, Shen, and so on (yet!)
The problem with Prolog is that to get reasonably performant code at all you have to understand the underlying unification algorithm and manipulate it using cuts to limit backtracking. This means that you have to break the core abstractions of the language in order to do anything, which defeats the purpose of logic programming.
Functional programming in Haskell makes it fairly easy to write fast code, though Haskell in particular is tricky to reason about space-wise (due to laziness).
This characterisation of Haskell bugs me a lot, because most reputable mathematicians would have nothing to do with Haskell either. The mathematical parts of Haskell seem to attract logicians, not general mathematicians. General mathematiicians much prefer Sage or Mathematica.
Don't get me wrong, Haskell is a great language, but it's not very "mathematical". It just has terrible ambassadors that give the impression that category theory and Haskell are synonymous. They're not, Haskell has its own breed of categeory theory that I prefer to call Haskellory theory.
This is a reasonable introduction to Haskell that does away with that Haskegorical nonsense:
>It just has terrible ambassadors that give the impression that category theory and Haskell are synonymous
It isn't ambassadors doing that, it is detractors.
>This is a reasonable introduction to Haskell that does away with that Haskegorical nonsense
Note that one of the authors, Don Stewart is almost certainly the biggest haskell ambassador in the history of the language. Which reinforces my other statement quite nicely.
There's abstraction and then there's abstraction. One of the benefits of Haskell is that it actually uses good abstractions rather than leaky ad-hoc ones. Making a Car an instance of Vehicle is not a good abstraction. Making a List an instance of Monoid is.
Then noting that List is isomorphic to the initial Monoid is great abstraction. When you know what that means you have leverage over a large number of valuable properties for both functionality and performance.
Wait...how do I model my car in Haskell? Assume I'm writing a game with things on the screen that might be called objects. The FRP solution would be just to dump all the signals into a bunch of switches, no modeling at all basically.
List is a nice collection if I'm using my built-in support for human language. I'd never call it as a monodic to my wife (or anybody else I care about).
It seems that some people, while going on and on about 'abstractions' and the importance of it, really just want cute metaphors. As soon as they encounter abstractions from the 'premiere' field of abstract reasoning and concept, they're appelled.
For that there are already several good, stable JVM lisps, though. I assume people are moving to Clojure because they specifically want Clojure, not just a lisp on the JVM; otherwise the more conservative choice would be to use ABCL (if you want CL) or Kawa (if you want Scheme).
In many ways a new programming language is similar to a a new product bashing its predecessor in able to position itself as a more superior alternative.
I think spot's formulation is closer to the original intent. The purpose was to create a language for web pages, not an exploration of functional paradigms in procedural languages.
By the time Javascript was designed, having first-class functions or closures was not a radical concept. It had not penetrated to the mainstream languages yet, but it was already to the point where they were very nearly the last holdouts.
Beyond that, Javascript did not particularly ship with any sophisticated FP stuff, and, really, doesn't even ship with any today. It may be nice that Underscore can be written, but for any language with any functional pretensions whatsoever, it shouldn't need to be written, because it ought to just be shipped with the stock language.
It's actually in the source of the page, just commented out:
Javascript: Java is scary.
Also hidden in the source:
Python: Modula-3 is scary.
Curl: Lisp syntax is scary, and XML is redundant.
Arc: Scheme has no libraries, and both could be denser.
There are a lot of languages I haven't been able to figure out
how to describe this way. Suggestions would be appreciated about any
languages missing from the list. What I'm looking for is not exactly what
motivated the language designer (Smalltalk was originally intended
for children) but what niche the language first lodged in. What was
the appeal of the language to its first users?
Actually for TeX it is “modern math typesetting is ugly”:
In the late 1970s, Donald Knuth was revising the second volume of his multivolume magnum opus The Art of Computer Programming, got the galleys, looked at them, and said (approximately) "blecch"! He had just received his first samples from the new typesetting system of the publisher's, and its quality was so far below that of the first edition of Volume 2 that he couldn't stand it.
TOML: Because INI files, JSON and YAML parsers are either too hard to read or write sane parsers for (It's not a language, but hey data formats are people too.)
Elixir: Because I want to be a Ruby hipster and an Erlang hipster at the same time (I'm only a lowly Ruby hipster.)
We're GNU. We don't care so much about the closed/open distinction as we care about the free/non-free distinction. The goal is that you should be able to run and share your code without anyone's permission.
I'm also planning to make Octave expensive as well. :-) Hopefully I'll manage to get this Octave startup off the ground.
More like: "we failed to notice the mistake C made of giving stupid meaningless names to types, rather than introducing meaningful names like int16, int32, int64."
When you say "int", you should get an integer - not an element of a (decided by the author arbitrarily) finite subset of integers.
People are not scared of lisp syntax. They just don't recognise it. First impressions really count. If somebody doesn't even recognise something at first glance then the vast majority of then aren't going to engage with it further. The people who are left are not enough to make something popular. Why don't they recognise it? - Because it's not familiar. Every child learns mathematics in school. In mathematics the convention is f(x) = 2x + 1. The function name is outside the brackets and the parameters are within. Names are important and names of things generally tend to be on the outside. Think about the name of a restaurant, a town, a house, a car manufacturer's badge, a box of cornflakes, filing cabinet drawers, folders in the filing cabinet etc. etc. All of these names or labels are on the outside of the object. Most people aren't afraid of lisp syntax they just don't even recognise it enough to engage with it further.
XML was all about encoding data, not computations. It's far easier to understand data storage than computation. Lisp becomes scary once you start computing and having functional/recursive calls. Look at prolog. Prolog's data storage is very easy for anyone to grasp. dog(fido). man(john), man(dave). The moment, you start computing with prolog recursively, most folks throw up and are ready to stick to their procedural/imperative style.
Syntax helps readability of structure. Lisp fails at this compared to other languages. Its simple, consistent syntax does help with some types of problems but those aren't the ones that dominate most people's daily programming needs.
It's still no surprise that some of the most powerful languages on that list are so because they didn't really "attack" other languages. Lisp and Prolog.
80 comments
[ 2.9 ms ] story [ 132 ms ] threadFunctional programming in Haskell makes it fairly easy to write fast code, though Haskell in particular is tricky to reason about space-wise (due to laziness).
Don't get me wrong, Haskell is a great language, but it's not very "mathematical". It just has terrible ambassadors that give the impression that category theory and Haskell are synonymous. They're not, Haskell has its own breed of categeory theory that I prefer to call Haskellory theory.
This is a reasonable introduction to Haskell that does away with that Haskegorical nonsense:
http://book.realworldhaskell.org/
It isn't ambassadors doing that, it is detractors.
>This is a reasonable introduction to Haskell that does away with that Haskegorical nonsense
Note that one of the authors, Don Stewart is almost certainly the biggest haskell ambassador in the history of the language. Which reinforces my other statement quite nicely.
Really? Is that because they don't like Haskell, or because they don't like programming in general?
List is a nice collection if I'm using my built-in support for human language. I'd never call it as a monodic to my wife (or anybody else I care about).
Miranda: Lazy evaluation should be the default.
Haskell: Miranda is closed-source.
http://research.microsoft.com/en-us/um/people/simonpj/papers...
Edit, previous discussion: https://news.ycombinator.com/item?id=6968775
Some suggestions:
@tensor wrote: "Clojure: lisp promotes mutability too much."
@ajuc: "The JVM needs a good lisp."
1. From that time: https://news.ycombinator.com/item?id=58444
2. Says (old article): https://news.ycombinator.com/item?id=288749
3. Says (2002): https://news.ycombinator.com/item?id=4954663
and 4. unqualified https://news.ycombinator.com/item?id=6968775
web pages are not programmable.
More like: Can functional paradigms be used in a procedural language
Beyond that, Javascript did not particularly ship with any sophisticated FP stuff, and, really, doesn't even ship with any today. It may be nice that Underscore can be written, but for any language with any functional pretensions whatsoever, it shouldn't need to be written, because it ought to just be shipped with the stock language.
Is possible to create a monoculture on top of a badly (non)designed language with not chance in hell to escape it?
PHP: Perl is too much work for web development and C programmers are too expensive.
Matlab: it takes way too much Fortran code to solve Ax=b
Octave: Matlab is closed-source (and expensive)
Julia: Matlab was designed by people who knew a lot more about numerical analysis than programming language design
Python + SciPy: you don't actually need a whole new language just to solve Ax=b
TeX: it's taking too long for people to typeset my books
Markdown: XML sucks for writing things by hand
R: because Perl isn't dangerous enough
In the late 1970s, Donald Knuth was revising the second volume of his multivolume magnum opus The Art of Computer Programming, got the galleys, looked at them, and said (approximately) "blecch"! He had just received his first samples from the new typesetting system of the publisher's, and its quality was so far below that of the first edition of Volume 2 that he couldn't stand it.
http://www.tug.org/whatis.html
TOML: Because INI files, JSON and YAML parsers are either too hard to read or write sane parsers for (It's not a language, but hey data formats are people too.)
Elixir: Because I want to be a Ruby hipster and an Erlang hipster at the same time (I'm only a lowly Ruby hipster.)
We're GNU. We don't care so much about the closed/open distinction as we care about the free/non-free distinction. The goal is that you should be able to run and share your code without anyone's permission.
I'm also planning to make Octave expensive as well. :-) Hopefully I'll manage to get this Octave startup off the ground.
https://www.gnu.org/philosophy/open-source-misses-the-point....
PHP now: We need every feature of every language ever invented. Twice.
Go: Haskell code is too generic.
D: "(C++)++" has terrible SEO.
Java (early versions): C is so fast that nobody wants to buy our new chips.
Scala: Java doesn't have map, reduce, or lambdas.
Java 8: Oh crap, Scala's right.
Java: Lets make C++ simpler and safer for the average bear, and give them a large standard library.
Go: Lets take an OO subset from Java, duck typing from Python, CSP and glue it all together with memory-safe subset of C that is garbage collected.
Because when I get a int, it should definitely be a bloody int.
When you say "int", you should get an integer - not an element of a (decided by the author arbitrarily) finite subset of integers.
Because it was superficially confortable given HTML and its popularity due to the explosion of the web.
Cosmetics are often more important than substantive structure in popularity.
C: Assemby language is too low-level.