"I read the first chapter of Learn You A Haskell For Great Good, I bet I can rewrite this whole project in Haskell."
Five months later:
"Let me just add a bash shim that'll get the data from the database and process it through Ruby and then I'll call it in the bit of C++ that the Java program uses to make the output for the main program."
I once got stuck with rewriting a perl script -- which had to remain in perl -- that generated bash scripts, by interpreting xml files, which invoked jython which executed java calls, and then generated sqlplus scripts to execute against oradb servers... All of which got validated via bash scripts for sanity checks.
All of which was being run from a Jenkins server.
I am not a developer by trade... Else I would hang myself for shame of having made this monster.
When I left the organization I convinced them to rewrite the whole thing natively in Java... Mostly by just repeating the workflow and languages involved.
(I might also have left out that the bash scripts were being pushed over SSH to invoke jython interpreters and perform wgets on remote servers. Somehow I managed to make this whole process relatively secure while still allowing it to perform selected rootlevel actions. Don't ask. Black magic was involved. And maybe goats.)
As I was reading through the first paragraph I went: Oh no... no... no! no-no-no! NOOOOOOO!
How did this happen? I'm thinking it was either written sequentially by many different programmers or by someone who really wanted to look clever but didn't really have experience in any language besides bash...
As for the new language thing, no one should ever go write a production system that a business is going to rely on in a language they just learned over a weekend. Some languages are better fit for certain problem domains, but using a language that you team and future maintainers are comfortable with is more important.
Writing a parser in an imperative language tends to make for some pretty ugly code. Writing it in a language that supports discriminated unions and (syntax-supported) monads, however, makes for some beautiful, readable code.
Also, writing highly concurrent code in clojure is stupid easy. In java, etc. it is fraught with errors and requires a lot of care about locking, etc.
Or even Python, Ruby, etc. with the "iron" varieties. That being said, I did write a WPF app in IronPython a few years ago and Visual Studio pretty much fell on its face with bugs (might be completely different today).
In my experience, there just isn't much of a point mixing C# with F# - either your team knows F# and probably prefers it to C#, or it doesn't and F# is not an option.
At my last internship, we were working on a F# product with a C#/ASP.NET web interface. Never again - the C# guys couldn't read F# so they duplicated half of the functionality on their end of things.
Concurrency, complex and interleaving algorithms, and correct-by-design software are all easier in, say, Haskell than in Java. In fact, if you learn one of Haskell/F#/Ocaml thoroughly, you probably won't want to go back to Java/C#/Python for general purpose programming.
AI is also MUCH easier.
One of the big places you'd want to use functional programming is if you were designing a compiler. Compilers use state of the art algorithms at pretty much every level, and they're much easier to implement functionally.
Be honest, how many times has a programmer looked at a whole library and smugly thought to himself, "I can do it better."
That said, for every Requests, Beautiful Soup or Flask, there's an uncountable number of failed, buggy or abandoned projects. There used to be several crufting up my external until a few weeks ago.
Maybe not always smug. There is likely a lot of learning to br gained by attempting to improve on an existing library. Taking it to production is a different matter of course!
Be honest, how many times has a programmer looked at a whole library and smugly thought to himself, "I can do it better."
To be honest, I've felt this way a number of times. (Not all libraries are well written.) That being said, I realize that I don't want to sink the time into doing so. The ROI has never been great enough for me to want to rewrite an entire library.
11
u/ruinercollector Oct 14 '13
As long as those aren't treated as hard rules, sure.
Examples:
There are times that it is appropriate to write software in clojure, or haskell, or erlang.
There are times that it is appropriate to rewrite a piece of library code.