Amen Brian. Profound truths there.

On Thu, Jul 14, 2011 at 3:41 PM, Brian Leach <> wrote:
> I've missed this discussion because I've been busy designing a website and
> app for a client.
> This being the real world, the site will eventually - of course - be
> delivered using SQL Server and C#, with the front end using AJAX calls to
> JSON services delivered through WCF. Which will no doubt take an age to
> develop, test, deploy and then reconfigure all over all again.
> So before getting to that stage, I've written a fully functioning prototype.
> Which is - of course - written in UniVerse and mvScript. Which means I've
> developed it all front to back in a few hours and it's robust and flexible
> enough that I can work through it sitting with the clients tomorrow and make
> changes in near real time as they come up with ideas.
> Which tells the story, in one, of what I do and don't like about U2.
> As to some of the other points:
> 1. Someone mentioned SQL Server and the GUI word again. Please ... SQL
> Server has no UI. If you're coding a UI for SQL server you use C#. If you're
> coding a UI for U2 you can use C#. If you're coding business rules for SQL
> Server you can use SQL Manager. If you're coding business rules for U2 you
> can use BDT or mvDeveloper. It's a red herring.
> 2. The other thread has been talking about locking. If there's one reason to
> use U2 over all else, it's pessimistic locking. The SQL world is full of
> script kiddies and wizard users who *think* they know SQL and don't have the
> first idea about concurrency, locking and merging.
> 3. Yes, we now have CLR in SQL server, but how many SQL developers are
> actually using it? The initial push to add it was a horrible cludge and put
> off many of those who might have experimented, and for the rest of the
> community it's too alien. I think we'll see TSQL as the main language for
> back end work for a long, long time - and that doesn't begin to measure up
> to UniBasic. (but read on before you jump on this...)
> 4. Having middle tier logic may be the norm but that does not mean it a good
> idea. It's the least worst response to a bad situation - not having business
> logic close to the database. It's more to test, develop, deploy and change
> control. And to be successful it still needs to call stored procedures at
> the back end.
> 5. But if you really want a middle tier, you can still add one and use C#
> and it's 'proper libraries' with U2. If you really, really want.
> 6. And either way, not having to stare at query optimizer output is a very
> good reason to like U2.
> That doesn't mean U2 can't be improved by taking on some of the better
> features of the outside world.
> The indexing is still very primitive, the SQL support is weak, and it would
> be great to have some other languages built into the database runtime. Even
> java - <shudder> - would be better than nothing, and would provide those
> 'missing' OO and library features that people think they want.
> Add OpenQM's version of objects into Basic while you're at it and make the
> Basic on the two products more similar. It's just a pain having to use two
> sets of syntax: Rocket could easily create a superset on both.
> Nowadays you can at least integrate the query and Basic language by using
> SQLExecute() function calls to @HSTMT - something that was always missing
> from the original Pick model. But it's not obvious and doesn't work from
> phantoms.
> For the client side, we need javascript bindings made easy - especially to
> JSON - as that is the most important language for new developers today. Look
> at all the new development platforms like Titanium that are built on top of
> it or that compile down from it.
> Just publishing the UniRPC protocol would be another good start, then
> developers could write native binding in other socket-supporting languages.
> Oh sorry - I've been asking for that for about a decade.
> Linking to a distributed memory cache - like Oracle does with Coherence
> (which it took as an open source product) - to give linear scalability and
> failover. Temporary tables for workfiles, in memory and/or reserved per
> session and cleared down on session end. Hint - per-session means no impact
> on the lock table for concurrency or for extension.
> And get rid of Eclipse. It's horrible.
> And from the commercial angle - produce a version that get can entice people
> into the product at the bottom level, with limits that will constrain it but
> an upgrade path to the full version as the usage grows and the business
> benefit becomes clear - like MS does with SQL Express. Allow developers to
> redistribute it. And make it appealing for web development. Right now it's
> not, whilst the charging model is still on a per-user and additional
> connection pooling basis: that puts it out of scope for those zillions of
> sites that need cheap lightweight data sourcing.
U2-Users mailing list

Reply via email to