32

I'm developing some application with clojure(lisp) alone in my team. It starts as small application. No problem. But as it's having features and extending the area, it's becoming important program.

I worried about maintenance or something. No one in my team knows clojure or lisp nor is interested in languages such as them.

So, isn't it wrong to do programming in unpopular languages? (for my own fun?) Should I use more popular languages? (at least such as python)

I'm sure if I leave the team, --not saying I'm leaving. :)-- no one would maintain it. This program will be destroyed and some will develop with other language.

I'm very enjoying developing with clojure though, I came across with that this might be not for my team.

What do you think about this? I think many programmers loving unpopular languages have been concerning similar issue.

Improve this question
4
  • 2
    Do you not have local programming standards regarding the use of languages for development locally?
    – temptar
    Feb 7, 2012 at 11:32
  • No, there is no such standards. I just told my boss and it was accepted without any comments. I think my boss just respected and permitted my decision.
    – Hybrid
    Feb 7, 2012 at 12:28
  • 12
    "Unpopular" isn't the big problem. "Unsupported" is far worse. E.g. Lisp beats VB 6.0 hands down.
    – MSalters
    Feb 7, 2012 at 13:41
  • 1
    If the app is so important, they'll replace you with someone who knows what they're doing. Just because your current team is limited doesn't mean they can't find anyone who knows this language.
    – JeffO
    Feb 7, 2012 at 14:48

13 Answers 13

Reset to default
23

I feel your pain, I would love to do more coding in functional programming (Haskell looks so fun!). I feel like I have only just scratched the surface because I have yet to use it in a business context.

I would strongly suggest against doing it though. If you program in a language only you know then only you will be able to support it. Unless you want to have to deal with every support issue (Even when you have other deadlines/priorities) then code in a language your team know and can support. What happens when something breaks while you are on holiday? What happens if you want to get promoted?

I would recommend you get at least one other team member on board with you. Show them some cool language features. With two people on board it becomes workable and you wont be loaded with all the support.

Improve this answer
4
  • 8
    I have to disagree. If a different language is the right tool for the job, use it. A lot of the incidental complexity in modern software development comes from programmers forcing their entire application to fit in one language. If your language does concurrency poorly, for example, then it might be quite appropriate to use another language to handle message passing.
    – quanticle
    Feb 7, 2012 at 19:03
  • @quanticle OP states " So, isn't it wrong to do programming in unpopular languages? (for my own fun?)." If there is a strong case for using another language such as concurrency then I agree it would be worth the support problems.
    – Tom Squires
    Feb 8, 2012 at 11:41
  • 1
    @quanticle: The opposite is true: Too many languages (i.e. more than one) lead to redundancy, duplicate efforts and needless reinventing the wheel.
    – ThomasX
    Feb 8, 2012 at 12:25
  • Right, support is definitely important. I love your suggestion getting other team member on board. I'll deeply think about such like that.
    – Hybrid
    Feb 9, 2012 at 3:02
17

I'm sure if I leave the team, --not saying I'm leaving. :)-- no one would maintain it.

Possibly False.

If the program has value, and management sees the value, they will task someone with learning Clojure and maintaining it.

Happens all the time.

This program will be destroyed and some will develop with other language.

Always true. So why worry about it?

All programs must eventually be replaced.

Improve this answer
5
  • Since Clojure runs on any of JVM, CLR, or javascript even if none of Hybrid's coworkers want to use clojure getting a (probably ugly) translation of the source in a mainstream language should be possible. In the former cases by reflecting on the bytecode/msil, in the latter by capturing the js being emitted directly.
    – Dan Is Fiddling By Firelight
    Feb 7, 2012 at 13:50
  • 2
    @DanNeely - You think a valid maintenance path is compiling Clojure to IL through a (very cool) homebrew project and then decompiling that code to C#? I'm not totally convinced that is easier than asking someone to learn the language.
    – user23157
    Feb 7, 2012 at 14:03
  • @TheMouthofaCow I suspect, especially for a larger application, learning Clojure would be easier; but the big hammer approach would let stubborn mono-lingual programmers make modifications without requiring a complete rewrite. Eventually refactoring to remove reflection cruft would probably result in a de-facto rewrite; but spread the cost out over a number of modifications instead of requiring it to all be done before adding the first new feature.
    – Dan Is Fiddling By Firelight
    Feb 7, 2012 at 14:11
  • Thank you. It's very supportive in my mind. As I get through this situation somehow, I could get having in mind such optimistic thoughts too.
    – Hybrid
    Feb 9, 2012 at 3:05
  • 1
    "All programs must eventually be replaced." Oh, would that that were true. There is a lot of COBOL code running that was written back when disk storage was terribly expensive, and that was patched to survive Y2K (remember Y2K?), and that is still running. In actual fact, most programs either die young from dis-use, or live essentially forever. So the choice of technology is actually very important. Because your offspring may be maintaining these programs.
    – Ross Patterson
    Feb 10, 2012 at 1:14
10

I'm in exactly the spot you envision your successor being in. I was tasked with adding features to a legacy program that used Clojure and Erlang to do asynchronous searching and turn it into a program that does distributed asynchronous searching. When I came into this job, all I knew was Python and Java.

My advice to you: use the best tool for the job. If that tool is Clojure, then so be it. Programming languages aren't that hard to learn. Well written code in a language that's appropriate to the task at hand is always easier to read than code that attempts to do something that the language wasn't designed to do. It'll be easier for your successor to read clean Clojure than mangled Java.

Improve this answer
5

Adopting new languages or "stand alone" language by some task is an high risk in a project.

If that part of system have a problem or that part must be dismiss instead you must find a programmer who must learn the skills about that language. In both cases you lost a lot of time.

In some case this problem can be used to improve and diversify the skills of a team by future task.

Improve this answer
1
  • I agree, I though one of advantages developing in clojure is affecting my team someway. I also agree this is a high risk. I should be careful. Thank you.
    – Hybrid
    Feb 7, 2012 at 14:31
4

Clojure might have a small installed base at present (it appeared in 2007) but it's hardly unpopular - in fact it's possibly the "hottest" new language around. I'd be surprised if you couldn't find other people interested in learning it.

Anyway, whether to adopt a new language however should always be a decision based on value to the business. You might discuss with your manager along the following lines:

Advantages of adopting Clojure:

  • More productive than other languages used - as evidenced by the amount of useful functionality you have delivered in a small amount of time and with fewer lines of code
  • We already have one important app (yours) written in Clojure so it is worth building Clojure skills to maintain it (rather than doing an expensive rewrite)
  • Use of Clojure will be seen as innovative and may be a good way to motivate talented developers to join / stay at the company.

Disadvantages of adopting Clojure

  • One extra language to support
  • Developers may need more training and time to get up to speed

If I was a manager evaluating this decision, I'd probably like the idea of higher productivity from Clojure enough to allow some limited experiments, and defer the decision until it was clear how well the team were taking to it. In that case, you would probably need to be an advocate, act as a good teacher and help bring the others on board.

Improve this answer
3

Don't worry, be happy.

Clearly the program has value, or you wouldn't be extending it. Congratulations on a successful project. Presumably you chose Clojure because doing so saved time and hence saved your employer money. If you had written it in Java, the program would be therefore be even more difficult to maintain. Even if your colleagues could more easily understand the program line-by-line, would they be able to maintain it and extend it?

Improve this answer
2

I'd say more power to you! Lisp is the Grandaddy of computer languages and is still relevant today; the fact that it is not so popular I think is due to the fact that it doesn't have the warm fluffy IDEs of C# and Java and the main compiler implementation in Windows only runs under Cygwin (yuk!). Development seems to take place in Emacs and I guess it plays better with Linux or a Mac.

This coding competition was won by a Lisp program in 2010: http://planetwars.aichallenge.org/

Way back in the day they could debug it live from about 100 million miles: http://www.flownet.com/gat/jpl-lisp.html

You are definitely waiving a maintenance red flag, but think of it as providing a learning opportunity for someone else. If you were using some nightmare language (like MUMPS) or some tedious language (like TCL) then I think questions should be asked. But I think you should be thought of as a guy trying to uphold the best of the old traditions :)

Improve this answer
2
  • Tcl is a nice language, I wouldn't call it tedious. Just look at Tkinter (in Python) to see that it is a nice tool to know.
    – Francesco
    Feb 7, 2012 at 14:28
  • @Francesco - I should point out that I said Tcl not Tcl/Tk. The graphical toolkit might be great. I said Tcl was boring because I went for a job interview a few years ago in a place that only uses Tcl (they take in junior programmers and then teach them a very unmarketable language to make it hard to leave) and turned the job down because Tcl looked tedious. I'm not saying that it isn't functional (it might be) I just thought that I'd end up chewing my arms off if I had to write Tcl for more than a couple of days. I stand by that.
    – user23157
    Feb 7, 2012 at 14:58
2

There are lot of good answers but I would like to add a point.

I have been in similar situation but with a different language. I had to learn everything the hard way i.e through trial and error method due to lack of guidance. What I learnt' from my experience as you pointed out maintenance / extensibility would become an issue as one might not be knowing effective approaches due to lack of guidance.

I suggest you talk to your manager for adequate help so that you can avoid any issues in the future.

Good luck!

Improve this answer
2

In some cases, a language like Lisp can make it faster or easier to implement functionality that would be very difficult in a different language. It also influences the way you look at problems, giving you a perspective that others on your team may not have. Having a wider array of capabilities and a broader view of what's possible can be very valuable to a company that's able to understand and use them. The price for those capabilities, though, is a lack of standardization.

Many companies try to standardize on one or two languages because it gives them more organizational flexibility: they can move developers from one project to another without having to retrain them, they have a built-in reserve of knowledge about the languages that they do use, and managers don't have to consider the strengths and weaknesses of using one language or another for a given project. When all you've got is a hammer, everything looks like a nail.

As I've outlined, both approaches have certain benefits and drawbacks. As is so often the case, there's not a right or wrong approach. You're just trading one set of benefits and drawbacks for another. A company doesn't have to go entirely in one direction or the other, either. It's perfectly reasonable to do most work in C++ or Java, but dip a toe into Lisp or Python from time to time to try them out and see what works. It sounds like that might be what your company is doing.

So go forth (but not Forth), learn as much as you can, and become the Clojure expert that your manager can rely on for insight that your colleagues might not have. And don't feel bad about it... worrying about the organizational stuff is your managers job.

Improve this answer
1

I would recommend to start rewriting your program in different (more convenient) language when you start feeling that maintenance has high chances to be dominating issue.

If you managed to write it in closure (which you didn't know when you started creating your app, as I understood), then it will be no problem to rewrite it using more familiar/convenient language. Closure uses completely different concepts and therefore implementation might be difficult to transfer into another language. But the thing is that if you had fun with writing new app in closure, then you might find it interesting to transfer concepts and ideas you used into another convenient language. It might be fun to compare different languages and their capabilities. I think your case is perfect for such experiments.

Improve this answer
1
  • I do this quite a bit. I'll write what seems like a one-shot utility in Perl or Erlang, then it gets used often enough that it becomes a utility, so I rewrite it using whatever the project's main language is (Java or C#).
    – TMN
    Feb 7, 2012 at 19:12
1

It's certainly not wrong to do programming in "unpopular" languages. Why do you actually care if they are popular or not? I fully agree with @quanticle on this. If Clojure or another non mainstream language is the best tool for the problem you are solving, you should pick it.

I don't see why maintenance will be a problem. If you apply Unit, Integration, etc. Testing and document your code any programmer with interest in functional programming will be able to maintain your program. IMHO the fact that your colleagues don't care about Clojure isn't a good argument for not using it, except if it's a company's policy that you need to respect.

Improve this answer
0

Whether or not the program is continued after your departure does not concern you in my view. You can use the programming language you to make something your boss likes, sounds pretty good to me. Worrying about continuation is something your boss should do.

Improve this answer
2
  • 3
    It's your boss's job to worry about continuation. But it is your job to make sure the boss is aware of the issues they should worry about. You should talk it over with the boss.
    – MarkJ
    Feb 7, 2012 at 11:57
  • I agree, although the OP should not worry about it if the boss decides to do nothing.
    – Paul Hiemstra
    Feb 7, 2012 at 12:06
0

Organize a tutorial or a training session. If your team members don't want to act like professionals and increase their knowledge, especially if the program is becoming more important, than it's out of your hands. In the worst case, you can talk to management and they can maybe mandating this kind of training session. You might look like a jerk, but at least you won't be the only one that has to maintain the program. The other option is to suggest that a 2nd programmer who knows clojure be added to the team.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.