[xquery-talk] Izzit Bcos I is functional?
ihe.onwuka at gmail.com
Wed Jun 17 10:47:23 PDT 2015
I wish I could agree with you but I think it is different this time.
Couple of days ago I saw an update on the Scala group, somebody saying that
the upsurge of interest in Spark could be the killer app that catapults
Scala into the mainstream. Much as I would like to see it happen for a
functional programming language, everybody except Scala dev's knows that
the language is just too damn complicated to ever go mainstream.
Even if this criticism could not be levelled at Scala, suspend disbelief
for a minute and accept that Spark is indeed this killer app, alas it is
not going to catapult Scala anywhere because the people employed in that
domain will demand that it is delivered in Python and/or R and the people
that hire them will acquiesce and say verily so.
In the 1990's the bell tolled for the Cobol mainframe programmer. It's not
like that now. On the JVM, the message is not adapt to Scala/Clojure or die
it's don't worry mate stick to what you know and Java 8 will bail us out.
The IT industry has presided over the widepsread and rudimentary
amateurisation of software development. So when the right solution comes
along it encounters a rearguard resistance from people who depend on the
technological status quo for their jobs and who roll out their stock in
trade objections (performance usually high up on the list). It's not like
1990 when mainframe programmers were saying I need to learn Unix/C and an
Rdb and/or 5 years later I need to learn Java and what they thought to be
5 years on they will be looking at Java 10 and still writing Fortran with
classes. The industry goes along with it because they can continue to
source bodies cheaply.
I absolutely agree that what you said should be the way it is goes but I
don't see how it is going to happen with the vested agenda's at play.
On Wed, Jun 17, 2015 at 1:10 PM, daniela florescu <dflorescu at me.com> wrote:
> Well I have no particular beef with the format itself other than the lack
> of tools. Now that we have JSONiq I am less bothered about that (assuming
> one has the opportunity to use it).
> Well, JSONiq is only implemented by Zorba (and another implementation in
> IBM middle tier).
> And Zorba is a dead piece of code.
> So, having “JSONiq” as a specification…...doesn’t mean much, isn’t it ?
> Unless is adopted by other XQuery processors.
> (which I cross fingers they will do…)
> I agree with your ideals (1 and 2 above) too but it should be evident from
> the sociology of the JSON community that these things are not going to
> Well… nope. Not clear at all.
> I started working on query languages for XML in 1996.
> Same as now, the whole industry was for using SQL for querying XML —
> including ME, I had
> a system running, a bunch of PhD students working on that, etc.
> The decision of the W3C NOT to use SQL for that purpose was taken in 2001.
> 5 years later. You know how many query languages have been proposed during
> those 5 years ?
> Tons: UnQL, XML-QL, etc, etc.
> Those things need TIME.
> People need to try SQL first, before they realize it’s a dead end.
> that’s a dead end.
> The industry moves MUCH, MUCH slower that one can expect.
> You have people putting stuff in JSON databases without thinking how are
> we going to get it out and coming up with half-assed solutions for doing
> so. This is not progress and this is not good.
> Again, patience is golden :-)
> There will be tons of those half baked solutions (MongoDB’s JSON query
> language, CouchDB’s..), before people realize that this
> is not going anywhere….some of those databases will be acquired, never to
> be seen again, them or their query languages….etc.
> Honestly, I give it 5 years for the JSON query languages to stabilize.
> 2020 would be my estimate. Even later if there is a database bubble crash
> in the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk