Right at this moment the Artima front page contains several articles that concern the same problem:1) grid computing: distributed processing; a distributed information system.2) Spring validation framework: data validation in a web framework for a distributed information system.3) the Java content repository API: a distributed information...

If it ain't broken, don't fix it...

> I definitely agree it's not about programming languages.> I'm not even sure it's that much about technology. If you> work with poorly defined requirements that keep changing,> if you have tight deadlines such that you can't think of> the design and its implications, then you can hardly> produce a good system. Technology can't help you much...

> Thanks for the link! It looks very similar indeed (the> CompC++ approach), although it lacks an adequate run-time> support (at least in the way I described it above). For> example, the application in CompC++ needs to be compiled> with connection definition, so you can't change> connections after the system has been built. This makes> the...

> Interesting thing, I actually experimented with something> that sounds similar to this. I created a simple language,> its compiler and the run-time system that allows you to> create independent components that communicate with each> other through input/output ports and connectors. For> example, you can specify a component that calculates a>...

> > Yes. I am not talking about a single programming> language,> > but a computing environment where a) data are> independent> > of code, b) persistence is automatic, c) the simplest> > execution unit is the function and not the executable,> d)> > networking is transparent, e) the O/S is an> > interpreter/compiler itself.> > I guess we had that...

> If I understood you right, it seems to me that this would> require a complete set of standards - from hardware up to> the application layer. No, no hardware changes would be required. I am speaking only about software.> This way one OS or application> could talk to another (perhaps on a different type of> computer), reuse each others...

> > The reason there is complexity though is because we> have> > not yet captured the essense of computing. Very few> people> > actually have understood how computers should be like> and> > what should they do.> > > ... and that is?The essence of computing is that an O/S is one function...so the bottleneck is the barriers between the various...

This is a very serious discussion and there are a lot of points raised in the short article above.> There's an insatiable demand for features—whether> underlying characteristics, such as security or> reliability, or actual feature sets or Web pages, or> screens, or editing tools. There's just no limit to the> set of things people would like to...

> And that would imply that functional languages aren't> needed to achieve this result. That sounds like an> argument against functional languages to me.Indeed.Personally, I think functional programming languages are marginally better than imperative ones, and that's the reason functional languages have not been widely adopted.

> While this comparison is written with a Java developer> in mind, it doesn't show or highlight differences in these> languages that go beyond mere syntax. In many ways, those> difference are more important than syntax.The only conclusion I have is that those languages are almost identical. Their differences do not really matter a lot for...

> Finally we can connect with Christopher Diggins'> frequently stated concern about order dependence.> > The problem is that with imperative languages (including> OO) we cannot be sure that the second time we say egg> yolks produces the same result as our first call for egg> yolks (some hidden state change may have scrambled our> eggs in the...

> > My Java programs are usually correct from the first go.> > Isn't that an argument in favor of functional> languages?> > Sorry, you lost me with these two sentences. How is that> an argument for functional languages?Supporters of functional programming claim that "once the functional program passes the type checker, it is usually...

> There are two big schisms in the programming community:> one along dynamic versus static type checking and another> along functional and procedural programming styles. I> believe that there is no real difference between these> so-called paradigms, and they are just different, but> limited ways, at looking at the complete space of> programming...

> > To me, Godel's theorem of incompleteness is the root> cause> > of errorism !> > Could you elaborate on why you think so?It's simple, really: nothing can be proven until it happens. This has a foundamental effect on programming: algorithms can not be mechanically proven correct.