Is Clojure a language for growth?

[aboy021]

Is Clojure a suitable language for a company that needs to grow quickly?

If a company wants to be able to hire staff and get them up to speed, as well as have options for bringing in contractors and outsourcing some work, is Clojure a good choice?

We've had trouble finding Clojure devs, and others have complained of how hard it is to learn Clojure and read the code from open source projects, especially for those with backgrounds in languages like C++.

I think Clojure should be a good fit for us because it is expressive, flexible, and we are still discovering new aspects of the problem domain. I'm biased on this because I really enjoy Clojure at home, and want to use it commercially.

I'm really looking for arguments that will help me persuade my boss that the risk of starting our next project in Clojure is one worth taking.

Thanks for any suggestions.

[Rangel Spasov]

Good reasons here http://www.quora.com/Clojure/Why-would-someone-learn-Clojure 

[Henrik Eneroth]

Have you read Paul Graham's beating the averages? I find it absolutely amazing, but one of the reasons that Clojure is such a phenomenal choice, if you can deal with the incidental complexity around it, is that it still is a somewhat non-obvious choice. Make your boss read the article as well, if s/he hasn't.

As for recruiting, I'm not sure what input to give, as I haven't had to deal with that particular issue myself. I have a hunch that if you tried to engage people who have a background in functional languages rather than C++, you may find that they have an easier time to adapt and to learn how to read code. I'm guessing that the trouble that C++ devs find themselves with when trying to read the language has much more to do with patterns than grammar. I had a fun time showing core.async to someone who'd only worked with callbacks and futures/promises previously, and it took quite some time for them wrap their head around it.

I think that it's possibly a feature rather than a bug that the patterns are non-obvious to someone completely new to the game. If not, they would be incremental, and the performance benefit for your organization would be similarly incremental. If you want a new level of something, rather than an increment of something, then logically, the stuff you need to learn is going to be somewhat alien.

Clojure, provided that it is done in a "Clojure" kind of way, has all manner of benefits, if you discount the availability of people and how approachable it is to a person who has never seen it before. You and your organization has to decide if it's worth the effort to get the people who can do this, or if it makes more sense to settle on something that is widely available. Just bear in mind that if you go for what is common, your performance is most likely going to be on an average level as well.

[Joshua Ballanco]

My advice on convincing your boss to use Clojure for a new project: don’t.

Projects succeed or fail for any number of different reasons, but I can guarantee you that if you *start* a new project with Clojure, and it does happen to fail, then the choice of Clojure will bear the brunt of the blame whether it deserves it or not.

Luckily, you don’t *have* to convince your boss to use Clojure. You only have to convince your boss to use the JVM. Whether that means Java, Scala, Groovy…or whatever. These languages and their respective libraries have come a long way, so it wouldn’t be the worst thing in the world to have to, for example, start with Java and Spring. But! Once you’ve got a JVM up and running then it’s trivial to sneak Clojure in the back door, as it were.

It’s much easier to convince someone with code than arguments, and if you’re already getting push-back from management on Clojure, then even if you do convince them to use Clojure, I bet you will not have so much fun. Trust me…I’ve been there. If you do, be prepared for every bug, every delay, every tiny hiccup to be blamed on Clojure.

> --
> 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 (mailto: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 (mailto: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 (mailto:clojure+u...@googlegroups.com).
> For more options, visit https://groups.google.com/d/optout.

[Phillip Lord]

aboy021 <arthur...@gmail.com> writes:
> We've had trouble finding Clojure devs, and others have complained of how
> hard it is to learn Clojure and read the code from open source projects,
> especially for those with backgrounds in languages like C++.
>
> I think Clojure should be a good fit for us because it is expressive,
> flexible, and we are still discovering new aspects of the problem domain.
> I'm biased on this because I really enjoy Clojure at home, and want to use
> it commercially.
>
> I'm really looking for arguments that will help me persuade my boss that
> the risk of starting our next project in Clojure is one worth taking.

You will have problems finding developers with lots of experience of
Clojure. It's relatively new. There again, finding good developers is
hard in any language. You might find more luck looking for good
developers and then ask them to learn the language. If there are other
developers around, if they are good, they should be productive after a
couple of weeks, especially if there are other developers around to ask
questions of.

When I got my first Java job, I had no experience at it; day one was
popping into town to buy a "how to program Java" book.

Actually, I had very little experience and no qualifications in
programming at all; perhaps the world was a different place then.

Phil

[gvim]

On 20/08/2014 14:09, Phillip Lord wrote:
> When I got my first Java job, I had no experience at it; day one was
> popping into town to buy a "how to program Java" book.
>
> Actually, I had very little experience and no qualifications in
> programming at all; perhaps the world was a different place then.
>

How long ago was that?

gvim

[Nando Breiter]

Perhaps the question is more "Is your boss (or company) suitable for Clojure?" 

[Marcus Blankenship]

+1 to Joshua’s answer.  If you want to make sure that Clojure never gets used, convince your boss to try it and then fail to meet expectations for ANY reason.  One thing I know, poor Clojure will take all the blame and be booted from the company.

When my company was young, I convinced my partner to try Rails, a new comer in the web space.  (He was a PHP guy.)  While the language was fine, he found the tooling at the time to be difficult and confusing, and so we pitched it out in favor of something else (python / django, as I recall).  For the next 6 years, every time I brought up using Rails (which grew in popularity like CRAZY) he would say “We tried that and Rails sucks.  Not doing that again.”  I’d hate to see the same thing happen to you.

When I introduced Clojure to my company, I took a senior dev aside and said “For the next project, I’d like you to try this new thing.  Here’s a book and a Heroku account, give it a whirl.”  If the project had gone sideways, so be it, but I wasn’t going to hang it all on the language’s fault.  I’d be willing, as always, to take the blame.

Just my $0.02,

Marcus

--
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.

Best,

Marcus

Marcus Blankenship

\\\ Problem Solver, Linear Thinker

\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

[Jonah Benton]

To add a data point to this, while the technology is great, it is not necessarily right for all companies at all lifecycle stages.

My experience has been that C++ skills and interests don't necessarily translate directly to Clojure. The kinds of microdecisions one makes in modeling, algorithm design and so forth are quite different, and the costs one optimizes for in C++ land don't make sense in Clojure. What I have seen more often is motivated C++ers transition to Scala- getting up to speed on the JVM and the APIs, get a little bit of a REPL, while retaining types and compilation and a lot of the mental model- and then go from Scala to Clojure. But since Clojure is a different toolchain and level of abstraction, changing both at the same time even for the motivated can be a bridge too far.

I would also not look at Clojure as a commodity tool, in the enterprise IT staffing model where one wants to just be able to throw bodies at problems, shift them around between teams, scale them up and down quickly with fluidity between staff and consultant roles. It's currently significantly more specialized and elite than that.

On the flip side, because it is a different level of abstraction, the right team + Clojure can be incredibly productive in a wide variety of domains.

If you have a budget and can afford to frame a Proof-of-Concept in your domain for a consulting team to demonstrate this, I would highly recommend getting in touch with Cognitect themselves. I don't think it is widely known that aside from being the creators of Clojure and Datomic, they have an extremely proficient consulting practice. Watching them work can be mind-blowing, from both technical and management perspectives.

--
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.

[Phillip Lord]

Long enough ago that buying a book was my first port of call, rather
than googling for tutorials. More specifically, 1998. I was writing
applets in Java 1.0, server in 1.1.

Somehow I don't miss those days at all.

Phil

[Quzanti]

I'd agree with this.

A closely held (financially) company with a small team of very bright programmers (preferably with a decent stake in the outcome so they stay around) will be able to exploit the power and productivity of clojure to do with a small team fast what would need far more people in Java

The type of company that wants to throw money and people at a project to scale it up would be a disaster with Clojure. Even the people that manage to master functional programming won't be able to understand each other's code because it tends to be more abstract and there are more ways of expressing things.

Java is a brilliant lowest common denominator language where your options are deliberately restricted and you really have to spell everything out explicitly so any idiot with a debugger can work out what is going on.

As a general point about doing anything 'new' if the guy "where the buck stops" is driving it, it can be made to work/covered up if it goes wrong. If you are NOT the guy where the buck stops but are the guy with his name against a decision then as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. 

[Henrik Eneroth]

 … as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. 

Good lord, truly? Perhaps this is a good time to ask what culture OP lives in. This wouldn't happen where I live/work.

[Quzanti]

Whenever there is an external institutional stakeholder it is almost guaranteed to happen. Someone in that external institution has a bonus or promotion depending on the outcome, and will demand results. They will also have penalty clauses in the contract which can be anything from non-payment, to seizing control of a start up, or even shutting it down.

I have seen it happen myself in England and Germany, and there are plenty of well documented cases from the States so I don't think it is culturally dependent in the sense of national culture.

If you live in a blame free society let us know where as it would be an excellent place for a start up!

[Quzanti]

Just looked at your profile. Sweden? A very enlightened place. I am a big fan of the Paradox Interactive games. What happens in Sweden when investors lose their money?

On Wednesday, August 20, 2014 7:16:55 PM UTC+1, Henrik Eneroth wrote:

[Ashton Kemerling]

I personally snuck it into my company in a limited fashion by selling its libraries, test.check in particular. This has gone quite well. 

--

[Linus Ericsson]

Well, for better or worse we don't like conflicts that much. This has benefits when it comes to some kinds of problem solving (the way to consensus in Swedish companies is worth at least a chapter in a big book about antrophology). This shyness for open conflicts can lead to stagnation.

This means that status quo is not turned over that easily, but when it does, it happens like an avalanche (cow oscillator comes to mind). Stockholm University has Clojure and Erlang in its second year curriculum for computer science. Just saying.

Apart from that, its 3kloc database queries and Java classes galore and Wordpress shops all over, like everywhere else. The single larges group of workers in Stockholm is of course computer programmer. 33000 people out of a million of so.

If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well.

"In Sweden we have a system..." the ironic saying goes, but the truth is that even though the housing situation is outright catastrophic, you would not ever be put on the street if you wasn't psychotic enough not to accept the help offered (worst case you would end up in a sad, sleepy, far far out suburb with long commuting distances, but hey). The social security system is simply generous enough to make sure people gets back on track, should it be long time unemployment or whatever (this, and elderly care jobs, are powering much of the popular music industry here). 

Ah, everybody generalizes all the time. Henrik can nuance the picture.

I have been programming and promoting Clojure quite aggressively for some years (it's hard not to), and the last months people have been starting to say "yeah, my java friends really likes it" or "yes, my bf likes it too".

Wind of change.

/Linus

working at Agical AB, a consultancy in love with technology and sometimes hosting Clojure Meet ups with Stockholm Clojure User Group and wov, so much thing I really can help companies with everywhere, epic win

--

[Quzanti]

"If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well."

Hence the need for a scapegoat. Generally if an investor can make 20% of their startups work, people will blame the technologists for the failure of the other 80%, and the investor will have a PR machine to distort the history if needed. But yes, startup hubs work best when there are angel investors who want to build a personal reputation or where the institutional investors have strong links with the universities producing the start up talent and so don't want to jeopardise those (eg the Stanford University system). Even the best VCs will shut down the majority of their start ups though, so you'd think that would make people avoid them, but there are always people out there who need money to try and realise their dreams. 

All a bit tangential to the the original thread question though, which was assuming a high growth, high pressure, scale it up fast, need results kind of culture, would Clojure be a good fit?

On Wednesday, August 20, 2014 11:46:48 PM UTC+1, Linus Ericsson wrote:

Well, for better or worse we don't like conflicts that much. This has benefits when it comes to some kinds of problem solving (the way to consensus in Swedish companies is worth at least a chapter in a big book about antrophology). This shyness for open conflicts can lead to stagnation.

This means that status quo is not turned over that easily, but when it does, it happens like an avalanche (cow oscillator comes to mind). Stockholm University has Clojure and Erlang in its second year curriculum for computer science. Just saying.

Apart from that, its 3kloc database queries and Java classes galore and Wordpress shops all over, like everywhere else. The single larges group of workers in Stockholm is of course computer programmer. 33000 people out of a million of so.

If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well.

"In Sweden we have a system..." the ironic saying goes, but the truth is that even though the housing situation is outright catastrophic, you would not ever be put on the street if you wasn't psychotic enough not to accept the help offered (worst case you would end up in a sad, sleepy, far far out suburb with long commuting distances, but hey). The social security system is simply generous enough to make sure people gets back on track, should it be long time unemployment or whatever (this, and elderly care jobs, are powering much of the popular music industry here). 

Ah, everybody generalizes all the time. Henrik can nuance the picture.

I have been programming and promoting Clojure quite aggressively for some years (it's hard not to), and the last months people have been starting to say "yeah, my java friends really likes it" or "yes, my bf likes it too".

Wind of change.

/Linus

working at Agical AB, a consultancy in love with technology and sometimes hosting Clojure Meet ups with Stockholm Clojure User Group and wov, so much thing I really can help companies with everywhere, epic win

On Wednesday, August 20, 2014, Quzanti <quz...@googlemail.com> wrote:

Just looked at your profile. Sweden? A very enlightened place. I am a big fan of the Paradox Interactive games. What happens in Sweden when investors lose their money?

On Wednesday, August 20, 2014 7:16:55 PM UTC+1, Henrik Eneroth wrote:

 … as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. 

Good lord, truly? Perhaps this is a good time to ask what culture OP lives in. This wouldn't happen where I live/work.

--
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+unsubscribe@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+unsubscribe@googlegroups.com.

[Henrik Eneroth]

Sweden has some things going for it, and some not, as always. I think business overall is somewhat less cutthroat here than in the States, which is why it struck me that I might be making assumptions about what OP should or should not do out of ignorance of his situation. The scape goat reasoning really brought this home.

At the two most recent places I've been (I'm a consultant, a UX designer), they've worked with autonomous teams. That is, the teams are themselves responsible for deciding how to solve a problem, sometimes including what programming language to use. One result of this seems to emerge (I only have a sample size of two) a microservice centered design and a general decoupling between the teams.

Also, it naturally seems to lead to a more heterogeneous environment, for good or for bad. This seems to be somewhat self-regulating however, as other most members of a team will protest if one member wants to write the new service in the Shakespearean Programming Language, for example. It also leads to the same kind of resistance to more sensible choices as well, like Clojure. But unlike SPL or Brainfuck, they actually have chance of being used if they show merit, probably by filling some niche role to begin with.

When I was with Spotify, I learned that they had snuck in some Clojure in one of the teams of the organization. No one has been fired yet, and everyone seems happy enough. Especially the people who now get to do at least *some* Clojure during their work day.

Oh, and like Linus, I try to promote Clojure wherever I go. As a designer, I'd love to work with a team that uses Clojure. That is, a team that understands that incidental complexity eventually seeps out to for the user to deal with, and so on. Unfortunately, being framed as a designer means I have less natural authority when I say that Clojure is awesome. Although this is somewhat mitigated somewhat by the sheer shock of having a designer saying something comprehensible about a programming language.

[Henrik Eneroth]

+ Grammar. I should not write correspondence before having coffee.

[Arthur Boyer]

Thanks for all the great advice. I think it really reinforces another thing I like about Clojure, that it has a wonderful community.

One idea that's come up several times is the notion that if we push Clojure then any problems we have will get blamed on Clojure, and unfortunately this rings true to me. At the same time, my boss is keen on choosing one language and sticking with it, something I disagree with, and if we do that it is unlikely that we'll get another chance to use Clojure in the foreseeable future.

Beating the averages was a great essay, and one that encouraged me to learn Clojure. I'll pass it on to my boss.

We're tending to focus on hiring smart people rather than people with a particular set of programming skills. Ironically one of our interview questions is around immutability, since we all agree that's crucial to building great systems. I'm optimistic that once we have some enertia it will be easy for smart devs to come on board and get up to speed with Clojure.

I think the dev team is a good fit for Clojure, currently there are only three of us (we're in a hiring phase), and two of us have used, and really like, Clojure. Unfortunately the boss' experiences with C++ and to a lesser extent Ruby seem to have made Clojure not a good fit for him. He's had a play with Clojure, and completely turned against it after trying to write a Sieve of Eratosthenes and creating something really, really slow. The boss isn't going to be writing any code, but is very opinionated about what we should be using, at this point he strongly favours Groovy. At least it's not Java.

The Cognitect proof of concept idea is a good one, and in a different situation, or different stage of the situation I'd go for it.

I've read quite a bit about the kind of microservice architectures being used at places like Spotify, and I think it would be a good way for us to go, but unfortunately at this stage we're a small core in a company that's trying to grow quickly, so that kind of thing is further down the line.

--

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/TfyA0qPIjmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Luc Prefontaine]

+1 same weakness + big fingers on
small iPhone keyboard :(
Urgent need for a second one...

We choose Clojure in 2008 strictly for efficiency.

In 2009 after being in prod, we were told that hiring would be a major problem.

We dealt with this noise by accepting the fact
that we will train people.

Why ?

Because we need 7 to 10 times less people.

Everything got simpler from design
to deployment.

We get people to learn by adding
tests. I can't stand TDD but I agree
that safeguards like automated tests
add value.

So let the newcomers do the boring
stuff while they learn :)

I think that there is a huge perception
problem. For some reason apparently in the industry complex systems = huge teams.

It looks to me more like a peeing contest more than anything else.
My team is bigger than yours, blablabla,....

Like if bigger meant better....

To me big teams are mostly a sign
of inefficiency except if you intend
to send men on the moon or
similar unusual goals.

Luc P.

> >>>> 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.
> >>>>
> >>>
>

> --
> 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.
>

--
Luc Prefontaine<lprefo...@softaddicts.ca> sent by ibisMail!

[Magnus Therning]

Personally I'd stop looking at a specific language for implementation,
and instead look at the architecture of the system. Concentrate on
loose coupling and finding a good technology for the interop of the
various parts. If the problem allows it you'll end up with a
situation where the implementation language of each part matters very
little, and then you simply choose the language best suited for each.

/M

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

Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
-- Alan Kay

[Jan Ziniewicz]

If a company wants to be able to hire staff and get them up to speed, as well as have options for bringing in contractors and outsourcing some work, is Clojure a good choice?

My friend works in a project which is being rewritten from Rails to Clojure (due to usual scaling problems with Rails). They don't have hiring problems. However, they are not looking for Clojure devs but devs who want to learn Clojure - and they don't have any problems with that. Usually, each new developer is able to code in Clojure after one month. Of course, every new team member has to read a book or two after hours and requires some mentoring from other members in a team. 

 

We've had trouble finding Clojure devs, and others have complained of how hard it is to learn Clojure and read the code from open source projects, especially for those with backgrounds in languages like C++.

Clojure is as hard to learn as any other language. People who complain about strange grammar (those bloody brackets) or a few new concepts in the language won't be a good buy for a fast-growing company.

 

I'm really looking for arguments that will help me persuade my boss that the risk of starting our next project in Clojure is one worth taking.

I had the same problem with Scala a few years ago. Persuade you boss to start with very small project. Make it awesome, show it to your team and remember - you 'll have only one chance. If you fail - they won't allow you to use Clojure again :)

[Kalina Todorova]

If a company wants to be able to hire staff and get them up to speed, as well as have options for bringing in contractors and outsourcing some work, is Clojure a good choice?

My friend works in a project which is being rewritten from Rails to Clojure (due to usual scaling problems with Rails). They don't have hiring problems. However, they are not looking for Clojure devs but devs who want to learn Clojure - and they don't have any problems with that. Usually, each new developer is able to code in Clojure after one month. Of course, every new team member has to read a book or two after hours and requires some mentoring from other members in a team.

 

Somewhat right but what about the people that are mentoring them, the clojure community is not big therefore is hard to find really experienced developers if some of the experience ones start to quit there is quite lower possibility for the owner to find somebody to replace them and the company becomes kinda more depended on the 'good-will' of the developers

 

We've had trouble finding Clojure devs, and others have complained of how hard it is to learn Clojure and read the code from open source projects, especially for those with backgrounds in languages like C++.

 

Clojure is as hard to learn as any other language. People who complain about strange grammar (those bloody brackets) or a few new concepts in the language won't be a good buy for a fast-growing company.

There is big difference between OOP and functional programming and if one is coming straight from Java or other OOP without any background in functional programming it is really hard to break some of this OOP mind-set and it takes time to get used to. I would agree that a person understanding the concept of functional programming can pickup quite quickly the lisp syntax and it will probably take about a month for him to be production ready but if he is totally new to the concepts I believe that it could take maybe more like 3 months.

I'm really looking for arguments that will help me persuade my boss that the risk of starting our next project in Clojure is one worth taking.

 
What we did last year were 2 things: participate in ClojureCup so you can show that you can provide fast value in Clojure and make some small prove of concept project

 

Kalina

--

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.

--

Best regards | Med venlig hilsen,

Kalina Todorova

T: 0045 52 64 93 73 E: ad...@ki6i.com	Trongårdsvej 46, 1 2800 Lyngby

[Sean Corfield]

On Aug 21, 2014, at 1:48 AM, Arthur Boyer <arthur...@gmail.com> wrote:

One idea that's come up several times is the notion that if we push Clojure then any problems we have will get blamed on Clojure, and unfortunately this rings true to me. At the same time, my boss is keen on choosing one language and sticking with it, something I disagree with, and if we do that it is unlikely that we'll get another chance to use Clojure in the foreseeable future.

It's a shame your boss - who won't be coding and clearly has fairly limited experience with modern programming tools - seems so intent on dictating technology to the rest of you.

The boss isn't going to be writing any code, but is very opinionated about what we should be using, at this point he strongly favours Groovy. At least it's not Java.

At least he's bought into the JVM so you're on the right path. If he's concerned about performance you may find Groovy too slow for certain things (depending on what exactly your company does) and that may be a way to sneak in small libraries that you write in Clojure to replace slow pieces of Groovy.

Where I work - World Singles - they had historically been a Windows / ColdFusion shop. When I joined as a part-time contractor five years ago, they were just starting on a complete rewrite of the dating platform. They were still happy with ColdFusion but early on in the project, the new contractors they'd hired pressed for a move to Linux and to Railo (a JBoss community project that provides a FOSS implementation of CFML with a smaller footprint and better performance).

One aspect of the platform had always been problematic: the email generator. It really needed to run 24x7 as a background process and CFML is only a web language so they'd tried a few other technologies. Once I was onboard, I suggested a rewrite in Scala (to leverage actors) and got a reasonable version working (in about 1,000 lines of code). It was back in the 2.7/2.8 days so the Actor library had known memory leaks (and the tool chain was a PITA as new versions of Scala broke everything).

I was exposed to Clojure in early 2010 - I attended a local "bootcamp" run by Amit Rathore (Clojure in Action) - and thought that might be a promising alternative to Scala for the email generator with parallel map, agents, futures and so on. I wrote a proof of concept (in about 300 lines) and demonstrated it. It didn't suffer from the memory leaks of the Scala version so it was:

a) much more stable

b) much simpler code (being one third the size of the Scala version)

c) slower than the Scala version

That initial version was capable of about a quarter of a million HTML emails a day (running lots of database queries and lots of calls to a search engine we use - Discovery by Transparensee). It was enough to get it accepted as our production version.

A few, relatively small, tweaks to the code boosted performance to three quarters of a million HTML emails a day and subsequent tweaks boosted it to about one and a quarter million. We added two more instances of the process, configured for different searches, and the search engine became the bottleneck. We've just completed an upgrade and reorganization of the server infrastructure and now we're ticking along at three million HTML emails a day.

Once I'd shown Clojure was viable for us (back in 2011), we started rewriting a lot of low-level parts of our CFML code base in Clojure and gradually started adding other processes fully written in Clojure. Our real time chat service is all Clojure on the back end. Nearly all of our scheduled tasks are pure Clojure and all of our "24x7" processes are pure Clojure. We have 21,000 lines of Clojure at this point. We're slowing moving toward a time in which CFML will remain only for Views and Controllers and our entire dating platform Model will be Clojure. Eventually I hope we'll replace CFML with Clojure even for the Views and Controllers. We're also building an internal app entirely in Clojure(Script) using Om and Sente (core.async over Web Sockets).

Based on my experience at World Singles, here's my recommendation: go with his choice of Groovy to start with (and Grails, I assume?). Look for small pieces to write in Clojure and sneak them in where they improve performance or dramatically improve maintainability. Don't go overboard - do it only where you can show a clear improvement over the Groovy solution you've already created. Don't push to cross-train other developers. Don't push to write all new code in Clojure. Slowly, over time, you'll just find you're using more and more Clojure and having fewer bugs and being able to adapt to changing requirements faster. As long as you don't make a big deal of it - and you're careful to make sure each new piece of Clojure is a success - better than the Groovy equivalent - your team will slowly make the change.

I was the only Clojure developer at World Singles for quite a while, then another developer switched (she had experience outside of CFML). Now a third developer is coming up to speed. We're at a point where "all new code is Clojure" is the official position even when it isn't quite the reality - after three years of slowly introducing Clojure where it made sense and expanding those islands into a continent. Oh, and just last week, our database systems guy, whose been doing a huge amount of data migration via Java said he was just starting to learn Clojure and was looking forward to getting away from objects and Java's verbosity and fussiness!

Good luck!

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)

[Steven Degutis]

Call me old-fashioned, but this seems like not the best way to
approach choosing a language. It should be chosen pragmatically, by
considering what works best for the task at hand, not because of
arbitrarily set rules, and never because a language is new and
exciting. Good programming techniques are timeless and
language-agnostic, and most of what you'll write can be done in almost
any language pretty cleanly, so it's best to use whatever language
makes the task the most practical. For example, I'll be writing some
code this evening that downloads several .tgz files, extracts a
docs.json file out of them, and uses these to build an HTML suite, all
without touching the disk. I was going to use Ruby, but Go has much
better support for in-memory I/O streams/buffers, so that's what I'll
use. Also, trying to stick to one language is only going to cause more
problems, in my experience. Different real-life problems need
different tools, even when the problems are related and inter-mingled.
In fact I wrote about this in a recent blog post for some reason, and
it seems relevant to the point I'm trying to make:
http://sdegutis.github.io/2014/08/18/age-of-the-polyglot/

> 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