Hacker News new | past | comments | ask | show | jobs | submit login

Great talk. Most of these talks on functional programming make perfect sense. These also look ideological superior.

My only problem is Object oriented programming looks more pragmatic in the real world. There are libraries, tools, tutorials, help forums and a lot of other stuff out there which helps anybody who wants to start learning OO from to go from nothing to far places.

You can't say the same thing about functional programming. The community is too elitist, the tutorials are math heavy. And the tools are too ancient. Having to use simple text editors and selling them as technologies used to build large applications is a contradictory philosophy.




> The community is too elitist, the tutorials are math heavy. And the tools are too ancient. Having to use simple text editors and selling them as technologies used to build large applications is a contradictory philosophy.

Careful. Statements like this only create more "elitists" by insulting people. Have you seen leiningen, Counter Clockwise, or La-Clojure? Part of the reason you need all that tooling is because of the objects. If you haven't become proficient in a functional language, can you really say the tooling is insufficient? It's like telling someone their movie sucked without seeing it, or only staying for the first 5 minutes. When I get rid of my Foo, FooImpl, JPAFoo, FooService, FooServiceImpl, FooDao, Bar, BarImpl, etc, the requirements for my editor and tooling suddenly change. If I'm not using big heavy frameworks, I no longer need all those plugins. I don't need to be able to click on my spring configuration and jump to the implementation. When I'm working in repl, I don't need heavy integration with Jetty (for example) because I never need to restart the server. If my restful webservice just needs to be a function that returns a map (ring), then I don't need annotation support, or some framework plugin. If my code is data, my editor already supports both.

I need to move around functions, and compile my code. Code completion? Navigation? Sure, but Emacs, CC, La-Clojure can all do that. I hope you aren't insinuating that Emacs/Slime is a "simple" text editor ;)

Tutorials are their own issue. A new object oriented programming language only needs to teach you their syntax and their API. A Clojure tutorial targeted at someone who has only ever done serious work in an OOPL is going to have to explain not only Clojure, but fundamental concepts related to functional programming. Once you really learn one, the rest all make sense in the same way it's relatively easy to jump around OOPLs.

If you've accepted the technical argument, don't let those other things hold you back. The Clojure community is great, and the Eclipse and IntelliJ stuff has really come a long way.


+1 the requirement for tooling is less. I switch between IntelliJ and Emacs for Clojure development, and tools don't hold me back.

I did a fair amount of Java GWT/SmartGWT development last year and having both client side Java code and server side code running in twin debuggers was handy, but really only crucial because of the complexity of the whole setup. That said, I only write simple web apps and web services in Clojure and Noir and perhaps that is why I don't feel that I need complex tools.


I won't claim any level of tooling/IDE parity, but FPs are quickly getting up there.

As an example, Haskell has a very helpful community, lots of stimulating content (yes, some are math heavy but many/most are not), over 3000 packages on Hackage (many of which are really excellent), 700+ people on IRC at anytime constantly talking/answering questions, at least 3 major web frameworks, many concurrency libraries, database drivers/libraries for almost anything, an astounding number of utility libraries and a real world-class, top of the line compiler (GHC) that produces blazing fast, robust code. Many companies are building commercial/proprietary tools with it for mission critical applications.


I just love it when people try to juxtapose "pragmatic" with "math-heavy". Obviously, in the real world no one ever uses math, all they do is print "Hello World" to the screen.


Unless you use Haskell, in which even printing "Hello World" to the screen is math heavy.


Clojure in Emacs with Slime is hardly a simple text editor. Emacs might be ancient, but that doesn't make it less powerful.

There are also plenty of great documentation for Clojure, Programming Clojure is one, and the online documentation is excellent.


Well now, I love Clojure and write it for my hobby projects, but I have to disagree about the online documentation for it. Every command is documented, sure, but that doesn't make it excellent. For example, here's the doc for the `with-open' macro:

"bindings => [name init ...]

Evaluates body in a try expression with names bound to the values of the inits, and a finally clause that calls (.close name) on each name in reverse order."

I deliberately chose a bit of code that's actually pretty simple and straightforward; also, one that I know intimately. Now, knowing what `with-open' does as well as I do, this doc string almost makes sense on the first pass. But to the layman this is almost impenetrable. I've written a couple variants of this macro and I STILL have to read the docstring a couple of times to understand what it's saying.

The online docs are comprehensive but I would never use the term "excellent" to describe them.


Good point. The clojuredocs version[1] is a bit better, but you're right, it could be better.

[1] http://clojuredocs.org/clojure_core/clojure.core/with-open




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: