Business programming
June 7th, 2010 | Published in Uncategorized | 5 Comments
Adam wonders what I mean by a language “optimized for business programming,” and I can’t really blame him because I’m not sure myself. However, my thinking isn’t really going the direction he guessed.
It may be nothing more than “a language that feels familiar to programmers coming from COBOL or Natural.” Languages like Java and PHP have gotten a lot of leverage out of having a “familiar, C-like syntax” (even if I always thought that was like saying, “familiar, IRS-like customer service”) and there is probably some value in providing this kind of familiarity. My main motivation in suggesting a Natural-like language that integrates with the JVM or CLR was as a migration path for legacy Natural programs.
I have a feeling, though, that mere familiarity is only part of it. Most programming languages are developed by people with relatively strong mathematical backgrounds, and I have the impression that they are in some sense “too mathematical” for people with a strong business focus.
I don’t know if this would actually work, but here are some ideas about a “business-optimized” language:
- Give variables value semantics. While you can often ignore the issue, I suspect that variables with reference semantics cause problems for lots of people.
- Include tolerance for redundancy. Programmers are usually lazy (and in fact I think unwillingness to do extra work helps make for better programming) so in Natural we usually write “READ EMPLOYEES BY PERSONNEL-ID”, but we can write “READ ALL RECORDS IN FILE EMPLOYEES IN LOGICAL SEQUENCE BY PERSONNEL-ID”. Human languages have lots of redundancy for good reasons, and if we allowed more in programming languages it might help, at least in reading comprehension.
- Segregate higher-level abstractions from basic capabilities. We want a language with coroutines, functions as objects, etc., but it should be easy to write simple programs without dealing with them.
I realize that these ideas might actually make things worse, but who knows.
(In response to Ross’s comment, I would like to develop an Adabas library for Python at some point. I’m just not sure if that’s really best.)
June 7th, 2010 at 3:51 pm (#)
What you suggest sounds more like a DSL than a full language. DSLs are pretty easy to write (difficult to perfect) in dynamic languages like Groovy or Ruby. I’m not really sure of a CLR suitable equivalent. There exists a Ruby CLR hybrid but it’s not really a CLR-native solution.
When I think about the kind of data we crunch here, it’s generally not very math intensive. Most of what we’re working with is textual manipulation of Lists and Sets. This is the bread and butter of functional programming languages. Scala and Clojure are two highly-performant functional languages for the JVM, and F# is Microsoft’s new CLR functional language.
June 7th, 2010 at 3:59 pm (#)
I agree that most programmers think like mathematicians, or think they should think that way. Making a computing language that was more compatible with how businesspeople think, or for that matter how any non-mathematician field thinks, requires someone who understands how to work with current modes. That’s a pretty small group.
Some things I think of, that mathematicians want but most people don’t:
1) things can only be defined once. If you define it more than once, even if the definitions are compatible, that’s an error.
2) everything must begin from first principles.
3) examples mean nothing, and cannot be used to show what anything is, or how anything works.
4) if there’s an error, anywhere, stop everything and proceed no further, anything built atop an edifice with any non-zero amount of error is worthless
One of the amazing things about HTML, CSS, javascript is that (4) is discarded. This alone helped make it far more approachable than most programming environments. Getting rid of 1-3, however, would probably require fuzzy logic, neural networks, or some other non-traditional kind of programming, and that’s a big shift.
June 8th, 2010 at 10:13 am (#)
Functional languages tend to be a lot more “mathy” than other languages. I think the history of functional languages suggests that only a subset of programmers can use them with much success, so turning to them for use by business-oriented people doesn’t seem likely to succeed.
What I was trying to suggest with my “segregate higher-level abstractions” point was that I’d want functional tools (and similar abstractions) available in my ideal language, but you’d have to go out of your way to say “yes, I know what I’m doing, and I need this extra power,” and most programmers could work with more simple concepts.
June 10th, 2010 at 11:20 pm (#)
adapya – Adabas database API for Python
http://pypi.python.org/pypi/adapya/
June 24th, 2010 at 9:38 am (#)
This would be a better example of a highly mathematical, symbolic programming language: http://www.vector.org.uk/archive/v101/whitney101_74.htm