So at that point, there's less imperative for the user to know the details of the algorithms. But there's a very big imperative for him to recognise e.g. when a problem can be best-described using matrices.
That makes me think about SQL. SQL makes it really easy for just about anyone to manipulate a database but, those without any knowledge of what may be going on inside (the indexes and algorithms used) can cause some real problems (performance problems being the most common ones.)
SQL is a good example. In the hands of somebody with the right mindset it can do some /very/ complex things, and a good implementation will optimise them well. But at that point one has to ask whether it's appropriate to "massage" an operation into the declarative paradigm, or whether one would be better leaving it as an algorithm written in the style to which workers in that particular field are accustomed... hence in the case of SQL various server-side languages such as PL/SQL.
(As an aside, since an algorithm is normally understood to describe a sequence of steps, I'm not sure whether the word really applies to the declarative paradigm where a sequence of steps can be replaced by a single SQL or APL etc. expression.)
I don't have a good SQL example to hand, but I've seen description of techniques which have a lot in common with
https://en.wikipedia.org/wiki/APL_(programming_language)#Prime_numbersMy feeling is that comparatively large languages such as Leda are on the wrong track.
I definitely tend to agree but, I have mixed feelings about that. It's nice to have something that operates at a "descriptive" level of some kind (such as SQL and even Delphi/Lazarus to some extent) as long as the user can "see" (or at least has a reasonable idea of) what's going on behind the scenes. That's important for the tool/language to be used effectively. The problem is that, it's not always obvious what is happening in there which can easily cause poor use of the tool/language.
Bottom line: the results show that cushy high level languages can't make up for user's lack of knowledge.
[/quote]
Undoubtedly true. However I'd still like to emphasise the usefulness of being able to merge programming styles, ideally in the same unit (e.g. you're assigning something to a Pascal variable which you can see is being selected using PROLOG-like logic). But I think that my major point is that a language should be extensible in directions its designers haven't anticipated: it's not just enough for its designers to say "In version x.y we've added syntax to support logic programming", it should be possible at the user (or at least library-writer) level to add a particular style of logic programming even if this demands syntax enhancements.
As a particular example, ALGOL had its I/O operations hardcoded into the language, and in one anecdote when somebody from the sales team complained that customers were having a hard time with it the star compiler writer spent a weekend of his time sorting out the semantics. Pascal is obviously in a similar position, with the implied polymorphism of WriteLn() etc. being handled as a "special" by the compiler.
It's not generally known, but several versions of the NT family of OSes (certainly v3 up as far as XP, and possibly later) embed a PROLOG engine in the program that handles network connections. If you pull a particular DLL to pieces you can see the rules that control it.
MarkMLl