views:

273

answers:

11

I'd like to begin a personal code library to contain all the small utility functions I use on a daily basis but can't find elsewhere on the 'net (I work in a specialized field). In my work, I switch pretty often between different products, so I want something flexible enough that I won't need to recode it over and over again.

My parameters: I work solely in Windows, and I do it remotely with very little in the way of integrated communication. I send little programs, graphics, charts, etc. off to colleagues by email.

Here's what I've come up with so far:

  • .NET: This seems like a good default choice, but several of the tools I use (MATLAB, MS Office VBA) don't integrate with it, so I couldn't use my library with those tools.
  • MATLAB/Python/interpreted language: Very flexible, easy to write new tools, but bad in integration. Can't call programs directly from any other tool without going through the OS.
  • Java: Better integrated than above, but still not great.
  • Compiled language (C++?): Maybe the best option, if written with COM interoperability. I haven't seen anything yet that can't call a COM routine, but the ease-of-use isn't great.

And one interesting idea I might need to give more though to:

  • Shell scripts: Dead simple, can stuff everything into a directory, pull out the ones you need for a specific project; but inflexible on Windows (.bat files?), if any helper tools are used they require system-level changes (installing things, changing %PATH%)

So if you were creating your own personal utility library that you hope will last for years and would like to remain as flexible as possible, what would you choose?

A: 

C# is simple and also powerful language for 99% of the cases

bashmohandes
+3  A: 

I would choose a language is best for each job, rather than stick to a single language. There is a place for each of the options you mention.

Soo Wei Tan
+1  A: 

Make sure of these things:

  • there are multiple independent implementations
  • at least one implementation is open-source
  • the language has some maturity
  • the language has some traction in the marketplace
  • avoid vendor-specific extensions

These will give the best assurance of your tools remaining relevant longer than your machine or operating system choice.

If you feel you must choose one language, C++ has shown a remarkable ability to not die.

Compilers for it are available on almost every platform imaginable. Open-source compilers (e.g. gcc) of exceptional quality are available.

If you are careful, it will continue to work despite even major changes in machine architecture - 32-bit, 64-bit, big-endian, little-endian, etc.

But there are lots of options; there is much wisdom in writing in languages best suited for each problem - most languages were created to solve specific problems, and it's a good idea to take advantage of that wisdom. And sometimes it is good for old code to retire.

lavinio
+1  A: 

There is no reason why you need to stick with only one language.

For instance you could write everything in C#.

For those programs without C# APIs, write your code in C++ and wrap it with C#.

DevDevDev
You can use IronPython with your .NET libraries and call C++ using C++/CLI.
Jared Updike
A: 

I can't say there is any best option. I can't even say there is a universal language that you could put your entire code library in that would be universally usable. If you need extremely broad interoperability across multiple platforms, products, and languages, that might be difficult. Without knowing more about exactly how you plan to consume this library...I would recommend looking into making the elements of this library services, written in C#, and exposed via WCF (for anything more complicated than the shell script stuff.)

The beauty of using C# and WCF is that you will then have the option of exposing your library in a very wide variety of interoperable, platform, and language independent way. WCF is not just SOAP web services...it is a highly extensible communications framework that will allow you to exchange messages between consumers and your services via HTTP web services, tcp, named pipes, msmq, and even custom bindings that you are free to write yourself. Communication with these services could then be done either directly, or in the case of applications like Office and Matlab, you could write simple service clients that call your services in the language of that platform (i.e. VBA for Office).

WCF: http://msdn.microsoft.com/en-us/netframework/aa663324.aspx

As for shell scripts...I highly recommend looking into Windows PowerShell. This new command line from Microsoft is extremely powerful, with all the kinds of pipeline capabilities of the powerful linux/unix shells, but with full object oriented capabilities.

PowerShell: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

jrista
Could someone explain the down vote? I'm getting tired of these random down votes without explanation... >.>
jrista
A: 

Have you thought about not using a specific language at all?

Two options present themselves:

  • Save the code in whatever language you wrote it in, but make sure you write it in a way that allows you to understand it 6 months or a year later and be able to either use it or rewrite it in the language of choice at the time (and you might want to save that implementation along with the original). Throw it in a file by itself, with perhaps a main method if you want to be able to run it and/or test it. Or throw it in a text file. It doesn't matter.
  • Translate the code to pseudocode and implement it in whatever language your project is in. Keep the pseudocode in plain-text files that can be searched and indexed.
Thomas Owens
A: 

Web apps. You can glue anything together over the web (or over a local server running on your machine). You can code CGI scripts or run web servers in most of the languages you mentioned (except maybe MATLAB). Use JSON or XML and you can make any language/function/algorithm interact with anything else. The web: it's the future.

Jared Updike
A: 

I use VBA/VB since it's simple and therefore easy to convert to whatever I need.

Lance Roberts
A: 

Since you only had two objections to .Net, let me challenge those assumptions:

  • Matlab
  • Office
    • There is a whole framework for integrating .Net with office, and you can easily make .Net code COM Callable. Office automation is done all the time in .Net

If those are your only two objections, then I think you are already convinced that .Net is the way to go.

Josh
Hi, thanks for the comments.Regarding MATLAB, that link seems to be devoted to using MATLAB from .NET, not the other way around. The latest MATLAB (7.8) cant directly call .NET from within a .m file, but I don't have the money to buy that.Regarding COM wrappers for .NET, I thought about that briefly, but it was heading toward needed to write wrappers around an entire extensive third-party library, something much too large and time-consuming to just use it.
jparker
Sorry, the above should be "The latest MATLAB (7.8) CAN call .NET...".
jparker
A: 

Choose the language you feel makes the solution simplest, for the specific type of problems you deal with. The conventional language is that the simple stuff should be simple, and the hard stuff possible.

I'd personally choose a scripting language, since they do usually allow lower level integration, and makes the simple stuff simple. Calling the OS, to exec the interpreter I assume, is not a problem. Everything is done inside the OS anyway.

+1  A: 

I'm a huge fan of C#, but in the interest of portability, I tend to write little utilities I need for myself in Python. It runs everywhere, has a lot of library support (PIL, Numpy, etc), and has good debugger/IDE support.

ראובן