woodsmailbox wrote:

> Expressive power boils down to doing more work with less code. So you
> can imagine how long a talk this can get. So I don't quite know where
> to start, or whether to start at all. Besides there's plenty of that
> on the net.
>

There is a trade-off between expressive power and
clarity/maintainability. APL, for example, pushed expressiveness to the
degree that it was next to incomprehensible.

Can you give an example in a database context where Lua is more
expression than JavaScript?

>
>> No, that's not good at all. It's a kludge to get around a missing
>> feature. I don't want to force people to have to invent their own
>> language layered on top of other languages.
>>
>> Exception handling is a very strong feature that should be built in to languages, not layered on by programming convention. C, it can be
>> argued, has exceptions if every function returns a boolean indicating whether it worked on not. A certain unmentionable open source database product does that. It makes the code difficult to read and write and leads to all sorts of problems.
>>
>
> I think you're making a confusion between extending a language and
> just infering that a feature is there by programming convention, like
> with your C example, or worse, coding it using a language with no extensibility features.
>
>

The difference remains that JavaScript has exception handling and Lua
does not.

I care a great deal less about extensibility than I do about actual
built-in features.

>
> All that being said, if you read the post about Lua exceptions again,
> you'll see the difference.
>
>
>> Uh, 97.6% of languages do name resolution during compilation.
>>
>
> ... maybe 97.6% of *compiled* languages, but that leaves another
> 12345.6% of *dynamic* languages out of discussion... weren't we
> talking about those?
>

Not necessarily. There is nothing in my list of requirements that
dictates a dynamic language. In fact, I'd go so far as to say that the
efficiency requirements argue against a dynamic language.

The advantage of a dynamic language is that the "compilation" (or lack
thereof) is cheap, though you pay for it at execution. Java, for
example, is more efficient that JavaScript, is cheap to instantiate, has
no issues with threads, etc. The cost of compilation, hassles with
class files, and strong typing make it much less attractive.

Traditional database languages are cheaper to instantiate than Java, but
lack complex data structures necessary to return complex results.

I could probably design a better language for the problem. The question
is whether it would be sufficiently better to justify the effort
involved in the design and in the endless explanations of why a new
language was necessary.

I'll probably extend the JavaScript implementation to handle 64 bit
iinteger with decimal scale factor and maybe BigInt.

>
> Ugh. That's a long one. Hope I'll find the time to argue that out. But
> until then, could you please tell me how do you plan to represent a
> "rowset" with a javascript object?
>
>

As a ResultSet with a method "next" to fetch the next row returning
whether or not there was one, and a property for each column in the
select list:

var results = connection.execute("select first_name, last_name from
people where town=?", "Manchester");

while (results.next())
doSomething(results.first_name, results.last_name);

delete results;

Simple enough?

--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]