The Old Joel on Software Forum: Part 1 (of 5) - future of software engineering

future of software engineering

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

anon

Saturday, March 22, 2003

Just speculating: Executable (UML?) models.

Enjoy

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

http://home.pacbell.net/ouster/scripting.html

Matthew Lock

Saturday, March 22, 2003

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

good one

Daniel Shchyokin

Saturday, March 22, 2003

Executable UML does exist...

http://www.taug2.com/tausolution/taudeveloper/

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.

ODN

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 (http://www.omg.org/mda/presentations.htm) 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.

Enjoy

Sunday, March 23, 2003

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

Tj

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.

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"

avg:{(+/x)%#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...