Fog Creek Software
Discussion Board

future of software engineering

What do people see in the future? Any new pardigms or foundations coming up?

Saturday, March 22, 2003

Just speculating: Executable (UML?) models.

Saturday, March 22, 2003

It's funny how people speculate that in the future anybody will be able to write a program.

What ever came of all the 4GL talk in the 80s?

Having said that I think Scripting will play a very important role in the future, letting you develop programs much more quickly:
Scripting: Higher Level Programming for the 21st Century

Matthew Lock
Saturday, March 22, 2003

"Just speculating: Executable (UML?) models. "

good one

Daniel Shchyokin
Saturday, March 22, 2003

Executable UML does exist...

Although at $12,000 to $20,000 a pop plus 18% annual support and maintenance, it ain't cheap.  It's targeted at real-time software development and uses UML 2.0-specific features.

Sunday, March 23, 2003

Matthew, I don't think that in the future anybody will be able to write a program. Sure many will be (and already are) able to develop (well, now I'm very cautious) *"software"* with products like LEGO Mindstorms: Just put a few modules together and voila. But we agree, that's not an n-tier application?

For those who want to develop complex systems, there will be something like xUML. I don't know if it'll have "UML" in it's name, but we'll have it! Why? Because probably the best way to understand what's going on in a software system (i.e. to cope with complexity), no matter if it is a new system you're developing or you're maintaining an existing system, is to make some diagrams.

There is an example ( from the world of real-time software development. It's a very mission-critical system but it's still not a method to develop each and every kind of software.

That's why ODN, if Telelogic want's us to read "real-time" we should do that. They admittedly don't write it's a silver bullet. xUML exists but we can only solve 15 percent of the problems we face in software development. Therefor 80 or 90 percent in the world of real-time doftware development.

For me executable UML (?) still isn't there. It still isn't ready for the primetime.

Sunday, March 23, 2003

Isn't the big hype building for aspect-oriented programming?

Sunday, March 23, 2003

The more things change, the more they stay the same.

The future is going to be LISP, as it always has been. OOP, AOP, metaprogramming, scripting, whatever; All of these miraculous inventions are library-level in LISP, which means that you don't need a new compiler, new environment or new training when the next buzzword comes along.

Unfortunately, it also means that it's never going to be fashionable.

[And, if the IT industry had any sense, the future would be APL, as it had once been. This is even less likely to happen]

Ori Berger
Sunday, March 23, 2003

"[And, if the IT industry had any sense, the future would be APL, as it had once been. This is even less likely to happen] "

I've never used (or seen) APL, so my question is, why?  I'm curious.

Monday, March 24, 2003

"Simple things should be declarative, complicated things shoul d be procedural" is a quote I read recently.

Basically, end-user programming is going to become more declarative (i.e. functional/logical), and the library and language support that needs the efficiency will retain the state handling, threading and the like needed for efficiency.

BTW, if you disagree with this statement, just consider that spreadsheets are a simple declarative program - which means that there are probably more declarative programmers than any other kind.

David B. Wildgoose
Monday, March 24, 2003

I'm sure that visual programming is the next thing, but I doubt it will be UML.

Wonderful though UML is, it is just too abstract.  Something more concrete will be needed.

And a visual language will most likely be declarative, because that is so much easier to implement that procedural.

Ged Byrne
Monday, March 24, 2003

APL is a functional vector language; It's been in use since the early 60's, and it's still alive and well. In the past, APL used many non-ASCII graphic characters, which made it problematic to print listings and use it on non-dedicated displays (think text mode displays -- these have been dominant until the 90's!). But APL does have an ASCII representation.

APL also has offsprings called J and (my favorite) K. The examples I give below are in K (because that's what I remember), but J and APL are not much different.

/ A function that averages a vector of numbers:
/ read "avg is (plus over x) divided by count of x"

/ output from below is '2'
/ read "avg of 1, 2, 3"
avg 1 2 3

/ A function that returns the distinct elements of a vector,
/ in the order that they appeared originally
/ read "distinct is x at each first of the
/          equivalence classes of x"
distinct: {x[*'=x]}

/ output from below is "a" "bc" "de" "f"
distinct "a" "bc" "a" "de" "f" "de"

APL programs are often 100 times shorter than their C or Java counterparts, and this ISN'T an exaggaration. APL routines are seldom longer than 3 lines (Consider "distinct" above, and think how long it takes to implement, _efficiently_ in your favorite language - the K implementation is either O(n) or O(n log n) depending on what kind of items are in the list).

For a good intro to K, see:
[ ]
For the origin of everything K see:

J can be found in
[ ]

An efficient open source APL interpreter (Unix only) can be found in []; This is the work of Arthur Whitney before he went on to create K.

Good examples of K code can be found in [ ], pay special attention to  't' [ ], which implements in 16 lines (only one of which is longer than 40 characters) a small relational database, that includes insert/update, selection, sort, aggregations (sql 'group by'), and random table generation. Do note that this is a slightly optimized version, a shorter and simpler (albeit slower) aggregation mechnism is also given on that page.

And beyond that, google is your friend.

Replies to what some of you are planning to answer (yep, I'm experienced in this kind of debate)

* "But it's horribly unreadable! What's with all this punctuation? That's unmaintainable! It's ugly! It looks like line noise" (etc.)

About as confusing/unreadable/unmaintainable as:  '*' as syntax for dereferncing pointers in C, '||' to mean 'logical short-circuit or', '2/3'  to mean integer division, or 'continue' to mean 'go back to the beginning of the inner most loop', or using 'static' to mark routines which have local scope (I'm picking on C as a relatively common denominator, but such examples exist for every language -- yes, even Python).

It's just a matter of getting acquainted; you get used to calling the pipe symbol '|' bitwise-or and the double pipe symbol '||' shortcircuit-logical-or. In K you get used to calling +/ "sum", &/ "min", |/ "max", ,/ "join", ,// "flatten" etc -- except that they aren't special cases - rather, the meaning is consistently derived from the basic atoms. Once you get used to them, it's no longer unreadable or unmaintainable.

It does take longer to read a line of K/APL than it does to read a line of C or Java - 10 times as long even if you're experienced. Yet, 50 to 100 times less lines are required to get the same job done, so you do profit.

See also an earlier post of mine [ ] about the subject (and Benji's post [ ] which inspired it.

* "But it's only short/useful for a small class of problems it was specifically designed to solve; In real world cases APL/K won't do better than <insert favourite curlybrace scope language here>."

It is true of many languages, but not of K/APL. Most software engineering buzzes today (e.g., OOP / AOP / UML / <insert favourite here>),  make the assumption that the basic elements, control structures, scoping and building blocks of common languages (C, Java) are sufficient, and try  to address inefficiencies and problems by adding more and more layers. APL and K, on the other hand, attempt to get rich "primitive" elements right before building upon them. And believe it or not, it works -  Steve Apter's examples at show that K has the right primitive for just about any kind of task.

To give a more concrete example, let's say you have a list of employee records, and you want to list the names of employees, sorted by salary. In K, it's as simple as writing[>emp.salary]

And if you want them by job and only then salary, it's[>emp.jobtype,emp.salary]

How much code do you need to do that in straight C/C++? assuming the standard C library? Assuming MFC? Assuming STL? This is a rather common requirement, and yet non of the standard libraries support it properly (e.g., what if the fields to sort by, order and direction, are determined by the user at run-time?)

The function "distinct" I gave earlier is, in fact not needed - there is an operator called "range" (written '?') that does that.

The point is that the building blocks that K provides make it simpler to build things from scratch than doing reuse in most other languages.

* "Ok, so you've got a nice trick in your sleeve. It doesn't change anything in the long run".

It does. Check out Kdb from Kx systems (the K guys). While it does lack some features compared to e.g. Oracle or MS-SQL, it's tens to hunderds of times faster than they are on many queries, it's got hot backup, a native GUI interface, a WEB interface, ODBC/JDBC drivers, RPC, etc. -- all in a 250K of uncompressed code and data. (Yes, that's 250 Kilobytes).

It's small, it runs awfully fast, it has lotsa features, it was developed by a very small team in a very small time. And it IS thanks to K (in fact, if I understand correctly, K was created mostly in order to implement Kdb). It DOES make a difference.

* "You're crazy."

Guilty as charged.

Ori Berger
Monday, March 24, 2003

I agree, K is cool.  But it is priced way outside of what most developers can afford.  Last time I checked it was tens of thousands for *one* user license (I believe it was around US$55,000).  They're going after the financial analyst market, not typical software development.

Thursday, March 27, 2003

*  Recent Topics

*  Fog Creek Home