Have you ever done a project using a languages that is not the mainstream choice for the specific niche of the project? Why? [closed]

Question

I was thinking about my academic experience with Smalltalk (well, Squeak) a while ago and whether I would like to use it for something, and it got me thinking: sure, it's as good and capable as any popular language, and it has some nice ideas, but there are certain languages that are already well entrenched in certain niches of programming (C is for systems programming, Java is for portability, and so on...), and Smalltalk and co. don't seem to have any obvious differentiating features to make them the right choice under certain circumstances, or at least not as far as I can tell, and when you add to it the fact that it's harder to find programmers who know it it adds all sorts of other problems for the organization itself.

So if you ever worked on a project where a non-mainstream language (like Smalltalk) was used over a more mainstream one, what was the reason for it?

To clarify: I'd like to focus this on imperative languages.

Answer 1

I'm using Falcon in a commercial game project, as scripting language.

It's not my dayjob though.

The main reason is that I want something as easily embedable and controllable from C++ as Lua, but with a syntax and language features more like Python. Python can be embedded but I find it to be APITA to embedd, even if it can be done.

Falcon do have a similar syntax to Python but provide more paradigms, so you can use thoses more suited to work with your specific project. It's fully written in C++ and made to be embedded (not in a Luabind way, but more laike manipulating a specific engine library). You can inject your modules in the languages, modules being written in C++ (or fully in Falcon). Once you've done an application-specific module, you don't have to do anything else to allow Falcon to work with it.

Another alternative that match my requirements but that is yet too young is ChaiScript - that is really promising. I'm trying to use it in a toy project but couldn't work a lot with it yet.

I'm using this one in another project. For the moment I'll use Falcon, but it's being refactored on the embedding system to make it even easier. If the refactoring is complete once I need to complete the scripting part of my project (not soon) then I'll keep with it (even if the scripters will have to write in yet another unknown language, I don't care for this specific project, and it's easy to learn for people familiar to Python or Ruby anyway).

Answer 2

In my day-job, I recently wrote a small throw-away tool that exposed some functionality via a slightly modified version of Picol (a very small Tcl interpreter).

As these things go, the tool wasn't thrown away but instead grew and is now a critical tool for the project :(

I used Picol out of my fascination with interpreters and I thought I could get away with it because none of my colleagues were supposed to see the tool.

Answer 3

I've used Haskell to program a critical middleware program. I could make this choice because I was the only in the team doing this (which in itself is not a good thing). Other reasons for choosing it was that the project was very time-limited and also that the resulting program had to run in relatively low resource environment.

And finally, I was hungry for trying Haskell for something real, having studied it for years.

The result was pretty good. The worst problem was a library (which was a wrapper around a C library) that leaked memory badly, but fortunately, I was able to replace that with a pure Haskell library. The profiler tools helped to find the problem in this case. Also, finding a good XML library was quite a hassle.

The best parts were that implementing the whole thing was generally fast and fun. Also, I was able to make sweeping changes, and ghc protected me through the process.

Making people get interested in a new language is tough. Especially more experienced ones are used to being good at programming, and it seems that it's pretty much a motivation killer to realize that their skills are quite specific.

Answer 4

I used Tcl/Tk for a cross platform prototype of legacy COBOL system in transition without a determination on a specific destination host/stack. The customer had not decided if the their 3 year and 5 year tech plan would continue to require Solaris desktops, and if not they wanted to move to NT/2000. It was at the onset knowingly throwaway code

The objectives were to move from terminal interfaces to native windowing, and outputs that were richly formatted. Using Tcl/Tk I could change layouts quickly, and use its internal exec to interact with existing Cobol executables with minimal adaptation to be driven purely by commandline options.

Answer 5

I'm not sure what counts as mainstream languages these days, but I've done (a long time ago) quite a bit of Auto/Visual LISP programming to faciliate some Autocad automatic generation of models and drawings. In the end, most of the generating code was in LISP (it started as a Fortran/C project, but that part was so simple, we just ported everything to LISP at one point). I left that place at some point, but I wouldn't be suprised if the project is still alive.

Answer 6

I do most of my Ph.D. research coding in D. It's admittedly been somewhat of a PITA because I've had to deal with the immaturity of the language and toolchain. This has been quickly improving now that the language spec is stable. If I had to do it again, though, I definitely would, for the following reasons:

1. Most of the stuff I write is pretty memory-hungry and performance-critical, but is also prototype-ish code where development speed is important. D is about the only language I know of that scores well in both programmer convenience and runtime efficiency. (Maybe C# would fit the bill, but it doesn't have template metaprogramming like D, which makes coming up with efficient reusable/generic solutions much harder. It also has the vestiges of Java-style shoving OO down the throat and other similar bondage-and-discipline features.)

2. I wrote several libraries myself to make up for D's lack of library support and this was a tremendous learning experience. I wrote my own SMP parallelism library, which is now in review for inclusion in the standard library. I wrote my own statistics/machine learning library, and now I feel like I know this stuff orders of magnitude better than when I was taking classes in it. I wrote my own plotting library and learned a bunch about data visualization and GUI programming from it. Furthermore, these are all open source projects that I can put on a resume. If I stuck with a more mainstream language, I'd probably feel like all the "interesting" library development stuff had been done already.

3. Participating in the discussions about language design, etc. has also been a tremendous learning experience.

4. If noone ever endured any short-term pain to make a clean break with crufty legacy technologies, we'd all be programming in Fortran '77. Call me an idealist but this isn't the future I want.

Answer 7

Smalltalk on its own, probably, is not that much a killer thing over the existing mainstream technologies. But if you take Seaside, it certainly may justify the choice.

Also, there are non-mainstream languages that are so much more powerful than any of the popular technologies, that for a complicated project which requires as much power as you can get there is simply no choice. I am using Lisp predominantly for the most of my development work, and I've got a huge toolchain of domain specific languages designed on top of Lisp - it simply would not be possible to do that in any other language. So now I'm using non-mainstream languages much more than mainstream ones.

Another case for "non-mainstream" is old legacy systems with their own weird scripting languages - e.g., CADs.

Answer 8

I've worked on several projects using custom languages specific to the companies for which the systems were developed. I've also worked on several projects using an obscure new language called Java back in the mid/late 1990s, a language that at the time experts predicted would never become widely adopted but happened to do what we needed it to do. And I've worked on a very large project in a custom dialect of Cobol, another language people now claim is dead. Then there's the project I've been somewhat involved with in Fortran, another one in QuickBasic, Delphi, all languages that would by now fit your "not mainstream" but at the time were far more common.

Answer 9

Im my country, anything that is not Microsoft, is considered "non mainstream", including programming languages that may be "mainstream" in other places (Java or Delphi, anyone?).

In any country, many companies or goverment depts. are afraid not to get developers for a given (programming language and programming framework), so they prefer mainstream languages.

But, in my experience, "mainstream" languages can backfire, because that means that your developer may easily get a better job, and leave the project.

And developers working in a non mainstream language, are usually more careful about software quality.

Having too much developers, means there will be more with lower quality. And in some places, companies cannot filter bad developers, doesn't know how to filter them, or even, don't care about filtering bad developers, as long as they are cheap.

Worked in a Delphi project, where we need it more developers, and the customer knew it. We hire some C / VB developers, and teach them about the language and framework, and even, check their algorithm / design patterns skills. Teaching them a non mainstream language, in purpouse, helped us, make us sure, that they knew how to solve problems, as well.

Answer 10

Did a heuristic optimization project in TI Lisp where the rest of the project was in a different language (CMS2, if you must know).

Similar uses of emacs lisp scripts in C/Java environments.