Depends what you call “mainstream” (or successful) for a programming language…...
Is it calculated in (1) #developers ? Or is it calculated in (2) #instances running it ? Or is it calculated in (3) #millions of dollars revenue from it ? ========== A. If (2), the Scala will be a HUGE success — because of Spark. IBM just offered to put more then 3000 (!! and that’s a LARGE number) of developers on Spark. Cloudera just seemed to have dumped Hadoop to become a Spark reseller. So…. in terms on number of instances running it, Scala WILL be a huge success. (how is Tyrpesafe, the company that does the Scala compiler making money … that’s another story…) B. If it is (3) — millions of $$$, I can probably give you the most “cost-effective” programming language in the world. https://en.wikipedia.org/wiki/K_(programming_language) <https://en.wikipedia.org/wiki/K_(programming_language)> It’s used for high end financial systems, and a copy of this compiler costs about $1M. Not bad …. Number of developers writing code in this language … probably in the 100s…. C. If it in terms of (1) number of developers …. are we really sure it matters ? Who makes money today out of Javascript ? (arguably the most popular programming language …) Nobody. ====================== So, which one do you care about ? I care about (2) and (3). Best Dana > On Jun 17, 2015, at 10:47 AM, Ihe Onwuka <[email protected]> wrote: > > 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 OOP. Hence 20 > years later we are still talking Java, Javascript and SQL and 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 <[email protected] > <mailto:[email protected]>> 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 >> happen. > > 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. > > MarkLogic needs to try Javascript on the server side, before realizes 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 > meantime. > > Best > Dana > > > > > > >
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
