What's clojure killer app? I don't see any.

[Paulo Suzart]

Hi all, (warning, this is kinda confusing email)

Been following the list for some time and specially paying attention to what could be the killer clojure app as Akka is for Scala.

I keep seeing small libs (I like libs) popping up like ants, but I don't believe none of them (alone at least)  can make clojure explode and become main technology in a old school /ordinary company.

People say clojure is good for data. But where are the cases? And more specifically, where are the frameworks and libs to support it? Are they talking about wrappers around java for Hadoop? Sigh...

Pulsar is quite dead, core async isn't clear regarding remoting, and avout? And lamina? And aleph? Where are the tools that can make clojure to cover from Web to big data and batch?

Luminous,  caribou, etc, are they going to become the next grails? Huumm.. Will take lot of time. Clojure Script alone will not go any further than the current server side.

What made me give up scala was Scalaz, and I hope the "create thousand disconnected libs and publish a post with ANN sufix" approach doesn't make me give up clojure.

Sorry guys, I've been posting about Clojure since 2009, and still can't see it becoming the main technology even being the CTO of the company.

What is the killer app for you? Or how do you think we can make clojure supporting apps like Facebook or something big like that?

[Thorsten Jolitz]

Paulo Suzart <paulo...@gmail.com> writes:

> Sorry guys, I've been posting about Clojure since 2009, and still can't
> see it becoming the main technology even being the CTO of the company.
>
> What is the killer app for you? Or how do you think we can make
> clojure supporting apps like Facebook or something big like that?

Being on the list a few days only I can tell you the 'killer-use-case' a
complete newbie was looking for: clojure for android.

Clojure apps that run as smooth as java apps but are (by the very nature
of clojure) much more convenient to write would probably open up some
doors in the enterprise world. I've seen real Scala for Android jobs
already, hopefully there will be Clojure for Android jobs in the future
too.

--
cheers,
Thorsten

[Andrey Antukh]

Hi Paulo.

2014-04-19 18:15 GMT+02:00 Paulo Suzart <paulo...@gmail.com>:

Hi all, (warning, this is kinda confusing email)

Been following the list for some time and specially paying attention to what could be the killer clojure app as Akka is for Scala.

I keep seeing small libs (I like libs) popping up like ants, but I don't believe none of them (alone at least)  can make clojure explode and become main technology in a old school /ordinary company.

People say clojure is good for data. But where are the cases? And more specifically, where are the frameworks and libs to support it? Are they talking about wrappers around java for Hadoop? Sigh...

Pulsar is quite dead, core async isn't clear regarding remoting, and avout? And lamina? And aleph? Where are the tools that can make clojure to cover from Web to big data and batch?

Pulsar is dead? Really? https://github.com/puniverse/pulsar/commit/1bb398cff65017c79d04bedd26915bca03a77521 24 days ago the last commit preparing new release. I follow the development of pulsar and quasar and it not seems dead.

distributed/remote communication is not target of CSP and core.async but can be implemented without much problems over any existing transport protocols: http://niwibe.github.io/jnanomsg/#_async_support (example implementing clojure channels over nanomsg)

Luminous,  caribou, etc, are they going to become the next grails? Huumm.. Will take lot of time. Clojure Script alone will not go any further than the current server side.

What made me give up scala was Scalaz, and I hope the "create thousand disconnected libs and publish a post with ANN sufix" approach doesn't make me give up clojure.

Creating one unique library that includes and integrates everything is really a solution? I believe not.

Sorry guys, I've been posting about Clojure since 2009, and still can't see it becoming the main technology even being the CTO of the company.

What is the killer app for you? Or how do you think we can make clojure supporting apps like Facebook or something big like that?

In summary: erlang/elixir has actors, scala has actors (and very slow compiller...), prolog has logic programming, go has csp and clojure has all them. Really you need a killer app? 

Sorry I don't understand the motivation of this email :(

Andrey

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrey Antukh - Андрей Антух - <andrei....@kaleidos.net> / <ni...@niwi.be>

http://www.niwi.be

https://github.com/niwibe

[Alexander Kyte]

The 'killer' problem domain for clojure is the same as that of any
lisp: the creation of domain-specific languages. There exist a
plethora of problems which are awkward to solve using conventional
programming, and clojure's macros make it easier.

An example is twitter's storm project. It's a real-time processing
project, which partitions your problem space into a set of nodes which
route data between them in 'streams.' There are two most common ways
to interact with it, the clojure dsl and the scala project called
Summingbird. In clojure, it is possible to define the entirety of the
logic that is related to the structure of the system in about 10
lines, plus another 2-3 for each transformation or input/output. In
scala? You'll need to make sure that your Producer[P#Store[Datatype,
Producer], Sink[Producer[Store]] type wrappers line up in *every
single part of your logic*. I exaggerate, but inherent in this
comparison is a truth that both systems need to do the same thing to
interact with the library. In other languages, the exceptional part
of your domain will taint every line of logic that you seek to write.
In clojure, a library writer can do the heavy lifting for you. They
can silently constrain what you can instruct, for safety and
expressiveness. You don't write clojure, you write the entirely new
language that you've made for your domain.

With macros, it is trivial to make a solution only need to state the
solution in the language of the problem domain, rather than the
language of the programming language. Lisp, and clojure, allow you to
grow the language up to meet you. In such a way, you can achieve high
productivity without sacrificing safety or performance. The killer app
for clojure is whatever you make it out to be.

If you've found that you cannot recommend clojure because there isn't
an amazing library or framework for your problem domain, the fault
lies not with the language but with you.

[Max Penet]

Hi, 

And there's Storm that could be worth mentioning... used by some (very) large companies (twitter ,groupon, etc...) and a success story. Also prismatic is a good example, and I could mention more companies/products, some that were acquired by big players, others used by millions, netflix comes to mind. 

About data access we have clients/drivers for any datastore you can think of, and there are tons of excellent web related libs both on front/back-end sides. I am not sure a huge monolithic monster ala rails is something to desire really. 

Depending on what you do, clojure can be a very good choice for a company/product.

We use it as our main backend techno were I work, and we dont' regret that choice, kind of the opposite. Having access to the immense java ecosystem paired with the versatility that clojure gives us (+ its ecosystem) is a big win.

[Guru Devanla]

One point that makes me wonder is this: One of the points touted a lot is the availability of immense ecosystem of Java. How does one balance switching between immutable and mutable objects once Java objects are brought into the mix. I have never used Java and Clojure together yet since this question has always bothered me. I tend to think that this mix would negate a lot of strength Clojure would give me, barring the functional style of programming I get to use along with Java objects. 

I would also love to see some good example of such a mix and if there are any guidelines on how to use them seamlessly without doing the guess work of dealing with a mix of immutable and mutable objects.

Thanks

[James Reeves]

Why does Clojure need a single "killer app"? I use Clojure because it has a wide range of useful tools, not because of any one tool in particular.

To my mind, any language that promotes itself on the basis of a single tool is indicative of specialisation, which isn't what I want in a programming language. For instance, back in 2008, Ruby on Rails was the killer app of Ruby, but the rest of the ecosystem of the library was rather bare. Nowadays Ruby has a far greater range of libraries and tools, and Rails has become just one tool out of many, rather than the sole reason people turn to the language.

That said, Clojure boasts several tools that aren't found many other places, and yet are extremely useful. Recently I've been using core.async, and now I find it difficult to imagine handling asynchronous communications without it. I'd almost say that was a killer app if Clojure didn't have so many other tools that have features that are just as compelling.

- James

--

[Gary Trakhman]

Clojure's killer app is immutable datastructures.  Libraries can interoperate extremely easily because their interface is described with simple data structures. 

What's Java got for this? Spring? Design Patterns?

[Timothy Baldridge]

When people say "killer app" what they mean is "silver bullet". The problem with silver bullets, is while they are quite exceptional at killing vampires, they are often somewhat subpar when it comes to dispatching other monsters of the night, such as ogres. Or at least so I've been told by my friends. 

I think the biggest strength of Clojure is that it tries at all costs to avoid silver bullets. Sure, actors may work for your project, but they are very horribly suited to most of my projects. Logic programming has its uses, writing a logging system is probably not one of them. Frankly I find it a shame that Akka has taken off to such an extent that apparently many Scala developers reach to it first, the moment they hear "distributed". 

Some criticize CSP (and core.async) of being ill suited to distributed programming, that may be somewhat true, since channels are transactional and provide guaranteed delivery, but so what? Nothing's stopping developers from removing a single CSP channel from their system and replacing it with RabbitMQ, JMQ or any of a dozen other methods. In fact, certain aspects of actors (mailboxes) can be implemented on top of CSP. Many people (including myself) have done that with core.async. 

As far as enterprise adoption, I see blue skies there. Both Walmart and Staples had booths at Clojure/West. 

So what's the killer app of Clojure? I think it's werewolves. I heard an quote once from an interview with one of the developers of Datomic. The question was: "How long would it have taken you to build Datomic without Clojure". His response was: "about 4 years...2 years to write Clojure from scratch, and another 2 years to write Datomic on top of it." The idea being, that the very essence of Clojure, the concurrency primitives, the immutable data structures, the fact "normal" code is pretty darn fast, is a killer app in and of itself. 

As a co-worker once said, "Clojure doesn't give you silver bullets, it turns you into a werewolf!"

Timothy 

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Plinio Balduino]

Gary:

  Immutability is awesome, the ease to work with concurrency in Clojure is fantastic and the interop with Java is very good when you compare with others JVM mainstream languages. But I'm affraid that these technical features that are very important for us, devs, don't sell the language for the standard developer or for most of companies. 

  I started to work with Clojure because I saw the beauty of the language and I feel in he wild the boost of productivity after some time of slow development, but I cannot sell the language in my company only presenting thoses facts.

Andrey:

   I think Paulo showed us a problem (of many others) that we're refusing to see. Clojure, as a LISP, is a powerful and elegant tool. As a JVM language, is built on a powerful and solid platform, with a whole world of mature and well finished components to almost every problem. But, as I wrote, it's not enough to sell Clojure to the 'common people', and even worst to the 'common manager people'.

  I think the syntax of Clojure is so dead easy that I have a presentation where I can explain the whole idea in five minutes. But again the Average Joe just will mumble about 'too much parenthesis' and won't see any advantage with Clojure. To the Avg Joe, Scala is nice because 'it looks like Java'.

  The same Avg Joe thought the Ruby syntax was awkward, but Rails made an army of Joes (like me) to dive into Ruby and after to a better way to work with OOP, even today Rails is not the main use of Ruby.

  I share the same concerns of Paulo, and I don't see a mainstream future for Clojure as a main language without a really attractive tool as a showcase.

Regards

Plínio

[Michael Klishin]

2014-04-19 20:15 GMT+04:00 Paulo Suzart <paulo...@gmail.com>:

People say clojure is good for data. But where are the cases? And more specifically, where are the frameworks and libs to support it? Are they talking about wrappers around java for Hadoop? Sigh...

I see lots of companies of all sizes use Clojure successfully for data processing. The great thing about data

processing is that there are many ways to do it. Some use Cascalog, some use libraries unrelated to Hadoop,

others use just Clojure. So while there may or may not be a single "killer app" like Rails, Clojure is fantastic

at this particular group of problems, as demonstrated by companies from < 10 to 10s of thousands of people.

--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

[Paulo Suzart]

Unfortunately I'm not a Stuart or a Emerick, or a Miller. So I can't really contribute to clojure that deep. I'm in the user /tech consumer side.

That said, it is not my concern only. I have dozen colleagues that can't foster clojure because they want a language with tools that fits every day. Not tools for very specific cases that may come out if they work in a very specific company in a very specific country.

I don't know, I still have all my coins on that. Really hope we can have almost pure clojure clojure solutions as we have pure java solutions.

Thank you all for your opinions.

--

[Timothy Baldridge]

" I have dozen colleagues that can't foster clojure because they want a language with tools that fits every day."

Can you explain this statement? I'm not sure I understand. I haven't touched any language but Clojure for "every day work" in months (years?). I can write a game in Clojure, I can write swing/javafx apps if I want, I can write webapps, I can write distributed systems, I can write high performance code as well as "hack it out fast" code.

So far in my career as a software developer, I've learned, C, C++, QBasic, VB, Delphi, Python, C#, Python, and Erlang. I left every single one of those languages because at one point or another they restricted what I could do with them. There came a day where I said "wow...if I could just do X this would be so much simpler". That day hasn't come yet for me with Clojure. Even after 4 years. 

I'm not sure what these people want?

Timothy

[Andrey Antukh]

Hi!

2014-04-19 23:00 GMT+02:00 Paulo Suzart <paulo...@gmail.com>:

Unfortunately I'm not a Stuart or a Emerick, or a Miller. So I can't really contribute to clojure that deep. I'm in the user /tech consumer side.

That said, it is not my concern only. I have dozen colleagues that can't foster clojure because they want a language with tools that fits every day. Not tools for very specific cases that may come out if they work in a very specific company in a very specific country.

 

This contradicts with "single killer app" in my opinion..., because single killer app is usually for specific use cases. 

:S

Andrey

[Paulo Suzart]

Andrey,

Yes. With killer app, I really don't want to find a silver bullet. But something or some things that mostly pushes people to use the language.

Thanks to your contribution

[Paulo Suzart]

Yes.

That's the point. You are taking about a bunch of wrappers. They are not bad, but will not make these people to move their asses from java. Even if they can introduce clojure in their tools set.

Thanks

[Timothy Baldridge]

"But something or some things that mostly pushes people to use the language." 

If that's the case, then building cool stuff is probably the correct answer. And in that case, this probably applies quite well to Clojure: http://paulgraham.com/avg.html

[Michael Klishin]

2014-04-20 1:26 GMT+04:00 Paulo Suzart <paulo...@gmail.com>:

You are taking about a bunch of wrappers. They are not bad, but will not make these people to move their asses from java.

Ask someone who's used Cascalog if they want to go back to writing Hadoop jobs in Java.
"Just a wrapper" can be a drastic productivity booster.

[Timothy Baldridge]

"That's the point. You are taking about a bunch of wrappers. They are not bad, but will not make these people to move their asses from java. Even if they can introduce clojure in their tools set."

That's utter bogus. Who has ever said that..."I won't move to Clojure because I can do it in Java". Because Clojure has a terse syntax, and sane defaults, most Clojure code will be 1/10th the size. Smaller code often means less bugs, etc. 

But a bunch of wrappers? Don't be ridiculous. Go look at test-check, core.async, core.logic, Datomic, ring, compojure. None of that stuff is a wrapper. 

But I guess what irritates me the most about comments like this is that they completely miss the goal of software engineering. The goal is to engineer a solution to a problem. If people are just taking whatever stuff Oracle/Microsoft/Google/Cognitect/Clojurewerkz/TypeSafe hands them and saying "welp...I guess we'll use X because that's what the big boys use." Then they're a lost cause IMO. Software engineering and design is about thinking about the problem and coming up with simple solutions. It's design, not an assembly plant.

Timothy

[Paulo Suzart]

Thanks Timothy. I also took some time to let it go and be able to criticize/show my concerns about something that I really like.

thanks for your 50 cent.

[Andrey Antukh]

2014-04-19 23:39 GMT+02:00 Timothy Baldridge <tbald...@gmail.com>:

"That's the point. You are taking about a bunch of wrappers. They are not bad, but will not make these people to move their asses from java. Even if they can introduce clojure in their tools set."

That's utter bogus. Who has ever said that..."I won't move to Clojure because I can do it in Java". Because Clojure has a terse syntax, and sane defaults, most Clojure code will be 1/10th the size. Smaller code often means less bugs, etc. 

But a bunch of wrappers? Don't be ridiculous. Go look at test-check, core.async, core.logic, Datomic, ring, compojure. None of that stuff is a wrapper. 

But I guess what irritates me the most about comments like this is that they completely miss the goal of software engineering. The goal is to engineer a solution to a problem. If people are just taking whatever stuff Oracle/Microsoft/Google/Cognitect/Clojurewerkz/TypeSafe hands them and saying "welp...I guess we'll use X because that's what the big boys use." Then they're a lost cause IMO. Software engineering and design is about thinking about the problem and coming up with simple solutions. It's design, not an assembly plant.

+1 

it is a reality, and I find that reality many times :(

I completely agree with you!

--

[Mike Haney]

What's "killer" about clojure is not an app, but an idea. Simplicity. Everything else stems from that idea. Immutability, decomplecting, data first, consistent abstractions - all the things we like to talk about in clojure are really about simplicity. It's about getting all the crap out of your way so you can focus on solving the problem YOU want to solve, not the problems foisted upon you by your language or framework or methodology/dogma.

I've heard all these promises before over my 20+ years in the industry, and had just about written it all off as a pipe dream. I'm sure you have too - and we all known that if something seems too good to be true...

But not this time. Clojure is true.

[Sean Corfield]

On Apr 19, 2014, at 9:15 AM, Paulo Suzart <paulo...@gmail.com> wrote:

Been following the list for some time and specially paying attention to what could be the killer clojure app as Akka is for Scala.

I don't think Akka is a "killer app" for Scala. Scala is a multi-paradigm general purpose language that is a "better Java" as well as a functional programming language. I think the whole "killer app" for a language is a ridiculous idea to be honest.

I keep seeing small libs (I like libs) popping up like ants, but I don't believe none of them (alone at least)  can make clojure explode and become main technology in a old school /ordinary company.

The more important question is "Does Clojure need to become 'mainstream'?" for some definition of 'mainstream'. I think the answer is no. We're past the time of "one language to rule them all". For years it was C/C++, then it slowly shifted to Java, and then C# became a dominant language for Windows while Java dominated everywhere else. But that homogeneity has pros and cons. Lately we've seen an explosion of programming languages, most of which are general purpose, and many of which are based on the JVM. Now we have choice: we can use whatever language we find most suitable for the task at hand - or even whatever language we just plain ol' prefer! A company can use multiple languages and know they'll all play nicely together. Each team can choose their favorite JVM language and it won't cause problems with other teams. This is a HUGE improvement on the "only Java" world in my opinion.

What made me give up scala was Scalaz

Well, that I can understand :)

Sorry guys, I've been posting about Clojure since 2009, and still can't see it becoming the main technology even being the CTO of the company.

A lot of companies are using Clojure for everyday things. A lot of companies are quite happily using Clojure as their main technology. But if the CTO is too conservative to pick Clojure, that's their choice. It's worth remembering that Clojure "endeavors to be a general-purpose language suitable in those areas where Java is suitable." -- http://clojure.org/rationale

At World Singles, we use Clojure for accessing databases (MySQL and MongoDB), interacting with third party web services (JSON, XML, REST, even SOAP - ugh, but it's so much nicer than doing it in Java!), analyzing data, transforming data, managing internationalization, logging, environment control... pretty much everything. We use it for all our long-running background processes - one of which generates and sends about 1.5M HTML emails a day and runs millions of JSON queries against a custom search engine. We have a real-time chat server written in Clojure (based on a Java Socket.IO implementation). We're just starting down the path of using ClojureScript for an internal-facing analysis app - using Om and D3 for real-time data display, with core.async over web sockets (via Sente).

All new server-side development is in Clojure for us. Two reasons:

* The Clojure code is much simpler, shorter and easier to maintain.

* The team *love* writing Clojure! They're having more fun in their jobs than ever.

The immutability, easy concurrency, DSLs and so on - those are all icing on the cake.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Daniel Kersten]

For me the "killer" thing about Clojure isn't a specific library or feature, its the philosophy that the community fosters and the collection of features and libraries that this nurtures:

• Simplicity
• Decomplection (extreme separation of concerns)
• Data-centric code (data-structure-first, explicit data, sequence abstraction, ...) 
• Immutability (which is really an enabler for the above)
• Managed state and side effects
• Small libraries that do one thing well, but can be composed as needed to build solutions that are well fitted to the problem

All these things lead to easier to understand, easier to maintain, easier to test, easier to extend and adapt code.

But.. if we must name some libraries and tools that I consider part of the "killer" ecosystem:

• Om
• core.async as a "glue" between components and libraries
• Enlive, enliven, enfocus, kioo
• If it lives up to its promises, Pedestal, when its ready
• Typed Clojure looks like it could become an integral and indispensable part of the ecosystem
• Storm
• Though I haven't yet used it, going by the community response, Datomic
• Ring

Together these things, in my opinion, make Clojure quite special.

[Paulo Suzart]

Very valuable, Daniel.

Really thanks

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Paulo Suzart
@paulosuzart

[Mike Haney]

I'm glad Daniel mentioned Enlive, because it's a great example of something that AFAIK is completely unique to clojure. It was one of the first libraries I dove into when I started with clojure, and I was blown away. It is such a logical approach to templating that seems so obvious in hindsight, yet I've never seen anything else like it in any of the languages/tools I'm familiar with.

[Daniel Orias]

On Saturday, April 19, 2014 9:15:38 AM UTC-7, Paulo Suzart wrote:

Hi all, (warning, this is kinda confusing email)

Been following the list for some time and specially paying attention to what could be the killer clojure app as Akka is for Scala.

Etc.

The languages that you do use daily. What was their killer app? What are the 25 killer apps for the Top 25 programming languages as ranked by mention in a survey of programmers? With C, the answer of Unix is fairly straight-forward, but C's popularity is not because people kept making os after os and since the late 70s people have been creating language after language to polish off C's very rough edges. Perl ruled web applications for a bit, by virtue of string processing and regexes. What is the most popular app written in C#? What was the killer app for C++? The primary use case for Python? Not being perl?

Objective-C is more popular now than ever in its third decade of existence and that is by virtue of its affiliation with a very successful platform. Android is a more popular platform and, yet, have we seen folks reigniting the passion for java that was there in the late 90s? 

You also may misunderstand the "killer app" theory, which I think is about how novel applications move platforms from early adopters into a mainstream. The most successful platform of recent times has been the smartphone. Its "killer apps?" Maps, Phone, Music, Messaging, Browser? All of the above?

Every new programming language is a commentary on its antecedents. The language designers imagine that a class of algorithms or processes could be more quickly and safely programmed or execute better if a language expressed the solution more clearly. From mathematics, we know that every sufficiently powerful language is as powerful as another. We also know that some problems are undecidable and some programs will yield answers that are occasionally sub-optimal because the correct answer won't be outputted until after the heat-death of the universe.

Within a few pages of any book on Clojure, one may see the comments the language makes on predecessors, including Lisp, Java, and Haskell. (Not all comments are along the lines of "they got it wrong.") The primary directive for the language was to make concurrency more manageable while leveraging Lisp's first class and higher order functions and code as data, the jvm's engineering, java's library, and Haskell's laziness.

I respectfully submit that you ask the wrong question, just as those who early last decade asked "Where's java's popular desktop app?"

What problem does your company have to solve? Are you really going to rewrite all your existing products if you find the most awesome language? If Akka is sliced-bread good, why keep looking? What does technical debt mean to you? What types of bugs show up all the time and would a different language exchange those bugs for easier to find and fix bugs? Can you hire enough great people to make the changeover work, or will it be an uncanny valley disaster as management underestimates resource requirements and time-to-expertise? Does the person using a reliable COBOL program really care that the language hasn't been hip since 1959? Users and customers. That is the focus. If Clojure helps you deliver better value to those groups or if it seems to make problem solving more fun or efficient, use it. Don't expect the advantages to be obvious. The processes that are "obviously" better are the ones more likely to be fads or traditions wrapped in buzzwords. There are no silver bullets.

[Magnus Therning]

On Sat, Apr 19, 2014 at 01:15:38PM -0300, Paulo Suzart wrote:
> Hi all, (warning, this is kinda confusing email)
>
> Been following the list for some time and specially paying attention
> to what could be the killer clojure app as Akka is for Scala.
>

[...]

>
> Sorry guys, I've been posting about Clojure since 2009, and still
> can't see it becoming the main technology even being the CTO of the
> company.
>

> What is the killer app for you? Or how do you think we can make
> clojure supporting apps like Facebook or something big like that?

It's LISP. That's the killer app. It's that simple!

/M

--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

In a hierarchy, every employee tends to rise to his level of incompetence.
-- The Peter Principle

[JPH]

I think that because of Clojure's resistance to heavy-weight frameworks,
you won't necessarily see a "killer app" in the way Rails was for Ruby.

I think the killer feature of Clojure is the sum of its parts. At first
glance it's hard to immediately see the value, but once you start
plugging together reliable components, taking advantage of the Java
interop and tooling from Leiningen, the advantages begin to appear.

This doesn't make it easy to advocate until you've first sold your
audience on the value of Clojure principles: functional, simple, immutable.

On 04/20/2014 12:15 AM, Paulo Suzart wrote:
> Hi all, (warning, this is kinda confusing email)
>
> Been following the list for some time and specially paying attention to
> what could be the killer clojure app as Akka is for Scala.
>

> I keep seeing small libs (I like libs) popping up like ants, but I don't
> believe none of them (alone at least) can make clojure explode and become
> main technology in a old school /ordinary company.
>

> People say clojure is good for data. But where are the cases? And more
> specifically, where are the frameworks and libs to support it? Are they
> talking about wrappers around java for Hadoop? Sigh...
>

> Pulsar is quite dead, core async isn't clear regarding remoting, and avout?
> And lamina? And aleph? Where are the tools that can make clojure to cover
> from Web to big data and batch?
>
> Luminous, caribou, etc, are they going to become the next grails? Huumm..
> Will take lot of time. Clojure Script alone will not go any further than
> the current server side.
>
> What made me give up scala was Scalaz, and I hope the "create thousand
> disconnected libs and publish a post with ANN sufix" approach doesn't make
> me give up clojure.
>

[doug smith]

i am a language hobbyist with absolutely no formal training. i have an idea for a killer app.

what i envision includes:

-pedestal om session datomic type framework for teaching clojure  while it analyzes  YOUR learning process.

-an entry point that assumes no prior knowledge -but could be grown to an expert level

-is VERY fun and VERY entertaining

this could be a 'bridge'  to learning without 'complexity'

i'm ready to help

   

 

[Mike Haney]

This sounds similar to what the Cognician guys are doing.

[doug smith]

For sure I see using the libs I mentioned.  I was referring to an app for very basic leaning  of " stuff".  Is that what you have heard they are working on ? 

On Wednesday, April 23, 2014, Mike Haney <txmik...@gmail.com> wrote:

This sounds similar to what the Cognician guys are doing.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/YCnG3rmOp5w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Ustun Ozgur]

Paulo, I understand your concerns, you are basically taking a bet in choosing Clojure and you want some confirmation that you will not be wasting time/money during the process.

Please watch Jay Fields' talk on this topic. I think he presents the upsides and downsides of his journey very well. One remark is that it was very tiring, it has been like having a second job (he remarks that he luckily didn't have any children during the process IIRC) but it was worth it in the end.

http://yow.eventer.com/yow-2013-1080/lessons-learned-from-adopting-clojure-by-jey-fields-1397

Ustun

[Paulo Suzart]

Really thanks. Great talk.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[douglas smith]

I would like to revisit this thread on 'killer-apps' for clojure. Hope you don't mind.

For quite some time I have been trying  to teach myself to code. -even before clojure was 'born'. (slow learner?...   probably)

I have read many books and spent many hours 'dinking' as my wife says.  I find it very very interesting and fun.

 

MOOC's  and in particular Udacity.com  have wet my appetite for learning again.  

I am taking several courses and enjoying the interactive  format.  I am even doing some screen-casting of the homework.  

I enjoy following your community and have learned a lot.    

I have installed emacs, light table, cider,org-mode, session, om -you name and enjoy going the different tutorials.

I am really finding the simplicity of 'code as data' and 'immutability' to be very helpful.

Anyway....   I may need to switch to decaf!   NAAh

Here it is:

A killer app for me and I think MANY others like me would be something very similar to a Kovas' 'Session' 'pretty like Light Table'  and beefy like IPythons Notebooks. 

I see a great opportunity for clojure to provide a pathway to learning to program the 'right way' from the start.  It seems you have all come to clojure after realizing that yourself.

I can't help but think many of the current students just starting out are going down the same path many of you did.

Lets teach people eager to learn using the best 'hand-tools' available..... i told you i have been watching...

 

Anyway thanks for sharing all the cool stuff you folks do.

I would love to help any way I could.... 

Doug

[Jony Hudson]

On Monday, 2 June 2014 18:42:32 UTC+1, douglas smith wrote:

 

A killer app for me and I think MANY others like me would be something very similar to a Kovas' 'Session' 'pretty like Light Table'  and beefy like IPythons Notebooks. 

Hope you'll excuse a shameless plug, but have you seen Gorilla REPL (http://gorilla-repl.org) ? It may or may not have some of the things you're looking for :-)

Jony 

[douglas smith]

Jony, Hey thanks 

Just finish watching and reading about Gorilla-Repl (will be digging deeper) and WOW really clean and simple UI -Nice. 

Much Much easier to install than IPython notebook was and its Clojure!

Couldn't follow much of your coding as I said I am just starting out.

I like the keystrokes and no buttons - I do need to remap chrome-browser ctrl-g to something else -don't use it anyway.

I like how you can show the underling 'value' of things.

Couldn't this type of application run remotely and potentially provide a 'live work space' for dislocated groups of students?

Maybe a keystroke that toggles screen control.  

- a 'kitchen table coders' thing but virtual.

 -just a thought.

I really am convinced that clojure is a great first language to learn-  and I'm determined to learn it.    

Thanks -Doug

 

 

 

 

On Tuesday, June 3, 2014 6:54:31 AM UTC-4, Jony Hudson wrote:

On Monday, 2 June 2014 18:42:32 UTC+1, douglas smith wrote:

 

A killer app for me and I think MANY others like me would be very similar to a Kovas' 'Session' 'pretty like Light Table'  and beefy like IPythons Notebooks. 

[douglas smith]

found Atl-g in snap-shop -thankyou again -doug

[gamma235]

Hi Paulo, 

I saw this question a while back and for some reason it became lodged in my mind. If you are concerned about whether Clojure is a good practical language to learn, I can understand your worries and say, resoundingly, go for it. Why? because after learning Clojure, and perhaps answering the question of "what is special about it?" rather than "what is the killer app" you will understand the underpinnings and inner-workings of so many important but very opaque concepts: data, language design principles, identity and state. I used many languages before I came to Clojure but I would say that it was through Clojure that I really learned computer science, making me a more valuable programmer. Clojure is a language for people who are interested in "sane", pragmatic approaches to language design in terms of mutability, primitives and the relationship between the data and its code representation (spoiler, in Lisps they are elegantly one and the same thing). Rich Hickey, at every step of the way thoughtfully designed a language for programmers to be effective with. So to reiterate, learning Clojure is not just about learning how to use Clojure, but also about learning why it is designed how it is. And that is groovy.

The reason I picked up Clojure was not to get a job, but because I thought it was cool. People who are focussed on industry from the beginning just take what they hear and run with it. They ignore Clojure because it is not on the top of the popular usage charts. If you can get past industrial adoption of Clojure apps and look at things from the perspective of a learner, you will see that Clojure has many "stories": a concurrency story, a Lisp story, a logic programming story, an asynchronous story. Name a feature and Clojure has it going on. This makes learning it an efficient use of your time: you can learn one language, write a 10th of the code you would otherwise, and tackle an incredibly wide range of problems that you would be using multiple languages to do otherwise. It has a front end story, a back end story, a dynamic story, a functional story... And all of these "stories" are possible due to the incredible library ecosystem that Clojure has, as well as the enthusiastic and creative people that make up the Clojure community. These are people who love to learn and have fun through coding. Which brings me to my next point:

Clojure has an AMAZING community. Most of the time, when I have a dumb newbie question, if I ask it here, the very people who wrote the books I am reading will come clarify things for me, patiently helping me out. In other languages, however, if the question requires a non-trivial understanding of the way the language itself is implemented, those grandmasters are a lot less accessible. As a learner, why pass up this opportunity? I am not saying that other languages don't have great communities, but I am saying that I think Clojure has something special in this department. In fact, I was recommended to learn Clojure by a Haskell programmer for this very reason. Which is telling, because Haskell programmers really love and actively promote that language.

Now with all that said, the question was specifically about apps. I think that Datomic and Storm are both pretty freaking cool. Check them out. Twitter is heavy into Storm. I also know that Citibank is using Clojure, though for what exactly, I am not sure. But in light of the above, is this really what is attractive about learning the language? 

I hope you can get something out of my response. And best of luck learning one of the coolest languages out there!

J

[John Chijioke]

Beautiful beautiful answer. I couldn't have said my mind any better. Thanks for taking the time to construct this expression. One day Clojure will be so dynamic that targeting any platform becomes just a paltry effort.

Cheers!