Re: The Holistic Approach to Software Engineering as a Way to Handle Complexity
Posted: Nov 29, 2010 3:12 AM
> Then why is it that all that happens is, we keep creating
> "new" ones that are only syntactically different from
> existing ones? Adopting new syntax isn't progress.
It's only Haskell that is created because there was a theoretical advancement in computer science. All other languages are born due to economic reasons or fun projects: Java started as Oak because its creators couldn't program their embedded devices in C++, C# started because Microsoft wanted to rival Java, D started because Walter Bright wants to be a programming language pioneer etc.
> we ignore the issue: users care about the data, not the
> language. We have a robust model of data, but not the one
> (hierarchy) which has bubbled up to popularity from the
> distant past of IT/SE. Why do we constantly babble about
> API's, but refuse to deal with data in a systemic way?
> All of these language zealots compete to become the
> e dominant language (COBOL before, and java now, though
> possibly fading), so as to enforce the use of their
> particular API set. A tower of Babel is the result.
Very very true. That is why I said: "make the computer information-aware. Computers are currently information-agnostic".
> Yes, I'm talking about Dr. Codd's invention. There's no
> better data model (arguably the only data model), but
> coders keep re-inventing implementations of old algorithms
> in freshly minted syntax (those "new" languages). The
> only point to this charade is to keep churning the
> process, such that "old" skills are displaced by "new"
> skills; yet nothing semantic or fundamental has changed.
SQL is fine and sweet, but its data types do not match what computers can currently do efficiently. The relational model is fine and sweet, but it needs to be the main way to storing information on a computer.
> The whole multi-processor/parallel/concurrency meme is a
> perfect case in point. Today's young-uns believe that
> this is a new class of processor, and that it requires a
> new class of language to be able to solve old/existing
> problems. Functional languages are said to be the answer.
> But such machines were profligate in the 1980's, and, lo
> o and behold, there just weren't many problems such
> machines could answer better than others. Language wasn't
> the stumbling block; appropriate problems was. Such
> machines are perfect for supporting multi-user server
> programs (ones which can parallelize individual queries to
> some data; running individual queries serially through a
> core/processor is a solved problem). No one, and I repeat
> NO ONE, has found a class of client/standalone problems
> which benefit from these processors. Until such is
> accomplished, this will be a fools journey.
Again true, but it would help if we can improve our methods of developing software, even if there is a limited number of problems that can be solved with parallelism/concurrency.