What are the best coding languages?

Post Reply New Topic

APL is deceivingly versatile, a source of both strength and weakness.

I have said that I wouldn't use it for large commercial applications, although I still do use it extensively for complicated multidimensional data analysis, OLAP, and prototyping larger systems.

It's has two massive advantages for these purposes:
1. APL is an array-oriented language. Multidimensional data structures are handled in the native language as single units. This allows a programmer who is able to mentally manipulate multidimensional abstractions to assemble very complicated analytical modules in an amazingly short time, with very few lines of code (typically one-tenth to one-twentieth of a comparable C++ solution.
2. APL is interpreted, so it is its own test harness. You can fix-and-replace and immediately resume execution (like DevStudio introduced five or so years ago), and all program elements are effectively tracked in your "watch window". Small-scale development does not require the creation of an infrastructure just to get started. Furthermore, as you build a program, you can keep trying out the next line of code until you have it right, testing multiple cases "on the fly" on a line-by-line basis. This allows the disciplined coder to dramatically curtail the introduction of bugs into the system. Furthermore, it is portable between platforms as long as interpreters are available for those platforms, since the delivered product is in source form.

With client-server versions available, and with interoperability between operating systems and other languages and databases, you can build a large-scale, multi-tiered application - and quite quickly at that. However, APL has several weaknesses - many the flip side of its strengths - which these days cause me to be cautious in selecting it for any major development effort:

1. APL is interpreted and is not strongly typed. Run-time interpretation, which entails behind-the-scenes intermediate compilation, adds an unavoidable overhead to run time. Full-array operations replacing coded loops reclaim some of that, making the performance penalty quite modest in many circumstances (as little as 10%) but APL can never be expected to match the performance of an equivalent C++ operation. APL's memory management is sophisticated, freeing the programmer from the details of data typing; however, that also comes with a significant cost in performance, and requires exquisite care in the program's design. If there is a large user volume where run time matters (i.e., most major commercial operations), it is usually worth the additional up-front effort to code in a high-performance compiled language.
2. The global population of fluent APLers is probably in the tens, or at best hundreds, of thousands. Assembling and maintaining a programming team can therefore be challenging, and can represent a major risk to a development project and its ongoing maintenance.
3. APL is a specialised language best exploited by people who think in a particular way. Other coders will tend to "use APL syntax to write C programs"; i.e., sequentially, linear and loopy rather than using full-on array manipulation. Most programming teams cannot count on having a hypersystemising autistic savant on board.

Personally, I use APL extensively for prototyping, specifying and validating major parts of larger systems (I'll be spending much of today prototyping a new system using APL), but for reasons #2 and #3 above have not attempted a large-scale APL-based product, even one supplemented by C++ bits, for over 10 years now.

Last edited by melissa17b on 01 Nov 2009, 5:18 am, edited 1 time in total.

I prefer coding in C#, very similar to Java and seems most natural to me. Also the intellisense in visual studio does half the job for you.

Is there any way an interpreter could quickly convert it into a .exe file? A lot of interpreted languages would probably run much quicker if that were the case. (Now that's an idea, an interpreted language that can also be compiled directly to Binary.)

It really sounds quite nice, but the overhead is the one issue that sticks out for me. If it were possible to compile the language (or figure out how to build a compiler), then it would really stand out as a great language to work in (right down to the need to systematize).

It has been tried on occasion over APL's nearly 50-year existence, but never with great success. When building major applications, I have instead relied on old-school techniques:

1. Understand your code and its behind-the-scenes effect on the interpreter. One power of a language like APL is that you can be working with a (say) 25x25 matrix of numbers, and then expand it to (say) 26x26 on the fly. It takes less than 10 keystrokes to do it. However, the interpreter has to allocate a new data structure and transfer the original 625 values to their respective positions in the new array. This is not free, so it should be minimised if performance matters.

If I know at coding time that I will progressively build an array, rather than create it one-time using direct array operations, then I will create a target array of an arbitrary large size and assign the elements in specific positions, just as I would in C++. If I underestimate my size needs, no matter - I can (with a small but now one-off time penalty) bump up the array size by another reasonably large increment.

2. Profile your code, and consider "outsourcing" any bits where you are being reamed in performance. For example, an array language doesn't offer any particular advantage in many numerical iterate-to-convergence algorithms, such as Newton-Raphson iteration. All modern APL systems allow you to call external code, such as DLLs, COM components and .NET assemblies in Windows. It is common in complex business analysis systems to make millions of calls to a set of small and isolated functions, such as statistics libraries and numerical quadrature routines. I maintain a highly optimised library of these in C++ and call them from APL, dramatically reducing the run times while maintaining the complex core of my model in APL.

3. Some aspects of a major system are less sensitive to run times than others. I will go to great lengths to optimise run times on program components that run on the server side or which are called massive numbers of times. I am far less concerned about raw speed with things like GUI programming. Above all, it has to work intuitively and has to look good. A 20% performance delay from what C# might give me will be totally unnoticed by an end user. As long as the system "pops" and is responsive without awkward delay, its UI is fast enough.

4. It is universal regardless of language that a system will succeed or fail by its design. If you listen to what the eventual users want and need both in the way of features and performance, and design an architecture that resolves conflicts consistently with the users' priorities, you will wind up with a good, although never perfect, system. Also, don't underestimate the value of rapid development - most people would rather a slightly slower system now than a moderately faster one next year.

I really, really like rigid compilers that will do their best to tell you about a mistake when you compile, instead of during the execution of the program. I mean, in dynamic scriptings languages you can have a variable name wrong and won't find out until an exception shows up while you are running the program.

But I love them for quick stuff.

How about Forth for being able to customise it.