Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Language Popularity & Network Effects; Ruby & Mongrel

 [1/15] from: edoconnor::gmail::com at: 20-Nov-2007 9:57


A few interesting reads I stumbled upon recently: 1. You Work in a Fashion Industry ...if you want to introduce a language, you don't concentrate on making it a good language, you try to persuade the herd of programmers, PMs and tool vendors that your language is the Next Big Thing. The important point here is not how much the language will do for productivity, quality and cost, it is to create the perception that everyone else thinks that this language will be the next big thing. There are two ways to do this.... http://rubygarden.org/ruby/page/show/YouWorkInAFashionIndustry 2. Interview with Zed Shaw, the author of Mongrel, the ruby webserver. What I found most interesting is how motivated the community is, and how they worked to fix some of ruby's problems with arrays and threads. http://www.infoq.com/interviews/ruby-zed-shaw Regards, Ed

 [2/15] from: carl::cybercraft::co::nz at: 21-Nov-2007 8:28


From the fashion industry one... Trained staff in a minority language are going to be rare. This does not necessarily make them more expensive (nobody else wants them), but it does make recruitment much harder and more uncertain. Alternatively you have to train all your existing people in the new language. And for Functional Languages its not just another syntax, its a whole new way of thinking. Two marks against REBOL there. Still, he did suggest a road to popularity - find a niche and own it. What's a niche REBOL could create/take over? -- Carl Read. On Tuesday, 20-Novenber-2007 at 9:57:25 Ed O'Connor wrote,

 [3/15] from: rasmussen:bryan:gmai:l at: 21-Nov-2007 8:38


>This does not necessarily make them more expensive (nobody else wants them)
This is true in theory but in actuality I think it often does make them more expensive because most n minority languages that are established as minority languages that wont disappear tomorrow are already niche languages, and to get that niche support companies often have to pay more. frankly I am at a loss as to what Rebol's niche could be. Cheers, Bryan Rasmussen

 [4/15] from: petr:krenzelok:seznam:cz at: 21-Nov-2007 9:00


Carl Read napsal(a):
> >From the fashion industry one... > > "Trained staff in a minority language are going to be rare. This does not necessarily make them more expensive (nobody else wants them), but it does make recruitment much harder and more uncertain. Alternatively you have to train all your existing people in the new language. And for Functional Languages its not just another syntax, its a whole new way of thinking." > > Two marks against REBOL there. > > Still, he did suggest a road to popularity - find a niche and own it. What's a niche REBOL could create/take over? >
Flash/Flex area - small, agile, distributed self-served PLATFORM, not just a language. There is long term plan - Altissimo - mixture of ViewTop, IOS, Altme, platform for small distributed apps. Another niche? Embedded area? We will see ... Petr

 [5/15] from: carl::cybercraft::co::nz at: 21-Nov-2007 12:28


On Wednesday, 21-Novenber-2007 at 9:00:33 Petr Krenzelok wrote,
>Carl Read napsal(a): >> >From the fashion industry one...
<<quoted lines omitted: 13>>
>just a language. There is long term plan - Altissimo - mixture of >ViewTop, IOS, Altme, platform for small distributed apps.
An online desktop then, but with no need of a central server owned by others? A Google for "online desktop" turns up plenty of attempts, but I suspect all of them are based on central-servers. In other words, designed for lock-in. (No time to test them. I looked at the offerings a year or so back, and some looked promising in that they were relatively responsive, while others were horribly slow.) But won't those who don't like the central server approach also be the ones who expect the alternative to be completely open-source? (REBOL would also be great for a distributed social network, except those who don't like the current social networks being central-server based are not going to accept an alternative with software that isn't open-source.) But yes, technically, REBOL would be great in both those areas. And ought to able to attract those who would like an online desktop/platform and don't care about how it's done. (I'm pretty sure a distributed social-network's a non-starter though.) -- Carl Read.

 [6/15] from: jblake::arsenaldigital::com at: 21-Nov-2007 8:37


SOA implementation. I know it's an "architecture" but to be able to enable a service on almost any server you have; and then write and deploy code to use that service from any server you have; and be able to use the code from any server you have; all with loading an app that's say 1 mg max? I cant wait for R3 so I can use the "services", dbase access and cli part. Then I'll stop using Perl. John

 [7/15] from: ale870:gm:ail at: 21-Nov-2007 17:23


Hello, central servers are a good way, for BIG companies, to "control" what you do, to control you and your PC (make publicity and money!). The same target are Ajax, GWT, Google OS, Flex, Adobe Air, etc... On Nov 21, 2007 2:37 PM, John Blake <jblake-arsenaldigital.com> wrote:
> SOA implementation. > I know it's an "architecture" but to be able to enable a service on
<<quoted lines omitted: 60>>
> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.
-- //Alessandro http://sguish.wordpress.com http://laccio.wordpress.com

 [8/15] from: carl::cybercraft::co::nz at: 21-Nov-2007 20:33


On Wednesday, 21-Novenber-2007 at 17:23:27 Alessandro Manotti wrote,
>Hello, > >central servers are a good way, for BIG companies, to "control" what you do, >to control you and your PC (make publicity and money!). >The same target are Ajax, GWT, Google OS, Flex, Adobe Air, etc...
It's not just 'big' companies though, but any group who has control of those servers when you can't move your software/data elsewhere without losing some or a lot of its functionality. -- Carl Read.

 [9/15] from: edoconnor:gm:ail at: 21-Nov-2007 15:53


Interesting discussion. I like the notion of PHP finding its niche with serving web pages. I'm not sure what REBOL's niche would be. REBOL was designed as a messaging language. I think I'd be struck down to hear someone say, Boy, you need to get your hands on a good, solid messaging language! Or, likewise, "Where can I find a dynamic, highly-reflective metaprogramming language when I need one." :^) I think that REBOL's strong point is it's convenience. I like the fact that I can fire up the interpreter on Windows or OS X and use it to manage my local data files with minimal fuss. Or that I can parse & extract content from web pages quickly. In this personal productivity/end-user programming space, I'd like to see stronger ways of managing/launching automated scripts, like a cron-job on the *nix platforms. The areas where I find REBOL is not so simple is in managing errors, networking, encryption, xml and building DSLs. I'm not saying the power isn't there, just that you need to have a good deal of expertise in these areas to leverage these features. Oddly, many of the aforementioned features might be considered central to the idea of messaging . If REBOL could make these things much more accessible and simple, and co-opt more of the SOA terminology, I think RT could enjoy more acceptance as a quick & dirty scripting language for plumbing enterprise architectures (as well as public ones, amazon S3, etc.). REBOL needs to enable the type of programming experience and end-user apps that people are not getting from current scripting languages and tool-sets. See "We have lost control of the apparatus" for more on anticipating the needs of future users: http://weblog.raganwald.com/2007/09/we-have-lost-control-of-apparatus.html Regards

 [10/15] from: ale870:g:mail at: 21-Nov-2007 22:43


Ed, I think you centered the problem! Rebol is great for communication, so maybe, it could increase its power just in this way: 1) implement more protocols (e.g.: ldap, snmp, protocol for M$ Outlook, XML, SOAP, JSON, etc...) 2) increment quality of client and GUI A lot of "standard" scripting languages exist, but when I use Rebol it is a joy for http handling, html parsing (but maybe, it is still too much complex. I think we need something like DOM navigation, but using Rebol power like native datatypes, blocks, etc...). Rebol has a good area where it can grow: communication, console piping, applications piping, etc... This area has almost no competitor, infact every other scripting language has not so much flexibility that Rebol has! On Nov 21, 2007 9:53 PM, Ed O'Connor <edoconnor-gmail.com> wrote:
> Interesting discussion. I like the notion of PHP finding its niche > with serving web pages.
<<quoted lines omitted: 28>>
> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.
-- //Alessandro http://sguish.wordpress.com http://laccio.wordpress.com

 [11/15] from: tim-johnsons::web::com at: 21-Nov-2007 13:30


On Wednesday 21 November 2007, Ed O'Connor wrote:
> messaging language. I think I'd be struck down to hear someone say, > "Boy, you need to get your hands on a good, solid messaging language!"
Bam! I can tell you - but I can't tell you where - that there are places where rebol is used extensive for "messaging" as in TCP/IP. There's may be more than what I know of - but there are organizations that (and big ones at that) that may be using rebol, but are not going to advertise it like google might advertise its use of python.
> I think that REBOL's strong point is it's convenience. I like the fact > that I can fire up the interpreter on Windows or OS X and use it to > manage my local data files with minimal fuss. Or that I can parse & > extract content from web pages quickly
I use rebol extensively for web scripting not so much for for network stuff, for that it runs rings around python. but read on....
> The areas where I find REBOL is not so simple is in managing errors, > networking, encryption, xml and building DSLs. I'm not saying the > power isn't there, just that you need to have a good deal of expertise > in these areas to leverage these features.
Oh if rebol could just report the file and line number of an error! Python has really got it down for error handling! To elaborate on what Alessandro has said about protocols - absolutely. And they don't have to be native, could be mezzanine or in libraries. Speaking of libraries, what many, many who examine rebol and remark to me is "Why is there no libraries? What is up with that? Is this really a serious programming language?" Given rebol.org as a starting point, there should be libraries. Libraries that are reviewed vetted and blessed by RT. In my opinion, rebol is crippled without that, because fellow programmers are telling me that is one thing that rebol is missing.. I know, I've said this before, many times on this ML. I'll probably say it again. tim

 [12/15] from: Izkata:Comcast at: 21-Nov-2007 12:09


On Wed, 2007-11-21 at 21:54 +1300, Carl Read wrote:
> On Wednesday, 21-Novenber-2007 at 9:00:33 Petr Krenzelok wrote, > >
<<quoted lines omitted: 18>>
> An online desktop then, but with no need of a central server owned by others? > A Google for "online desktop" turns up plenty of attempts, but I suspect all of them are based on central-servers. In other words, designed for lock-in. (No time to test them. I looked at the offerings a year or so back, and some looked promising in that they were relatively responsive, while others were horribly slow.)
I've tried 3 or 4 of them out of curiosity, and all the ones I tried extremely laggy. I don't see how it's possible to get anything done on them.

 [13/15] from: btiffin::rogers::com at: 21-Nov-2007 23:18


Tim; Discussions on this very issue are in progress. The user.r topic of interest right now is Programming in the Large. That for me includes libraries; trusted libraries. I hope to have my head around a secure Web of Trust sequence soon, (the whole OpenPGP thing) and getting it started if it's not too much grief. That will give us rebols a digital signature and a bank of keys to verify such. It is a little bit of a catch-22. So many features that are visible libraries for most scripters are a one or two-liner built-in for REBOL. But there are libraries we do need and those should be built and then propagated in a well defined and well advertised way. All planned...now action? Hmmm, action. :) I was trying not to mention REBOL/3 in this, but even R3 will not be the panacea for library management. That will take the community and some "follow the leader" imho. Cheers, Brian On Wednesday 21 November 2007 17:30, Tim Johnson wrote:

 [14/15] from: moliad::gmail::com at: 22-Nov-2007 1:07


On Nov 21, 2007 3:53 PM, Ed O'Connor <edoconnor-gmail.com> wrote:
> Interesting discussion. I like the notion of PHP finding its niche > with serving web pages.
<<quoted lines omitted: 3>>
> Or, likewise, "Where can I find a dynamic, highly-reflective > metaprogramming language when I need one." :^)
REBOL is the most productive programming environment I have used for quick and dirty stuff. yet for all its qualities, its the least documented framework I've ever used. sometimes you realise that its as huge as .net and you never knew! we all know R3 will address a lot of this. and its not just talk, the guys handling the task, really are writting down a lot more than I can remember in prior iterations.
> I think that REBOL's strong point is it's convenience.
yep. no other language allows you to define DSL, parse strings, create guis, define stylesheets, embed a rich client all using ONE single datatype rich language. I wonder why many of the serious REBOLers are not using REBOL more. So far I have used REBOL in all environments I can think of, from async concurrent multi -port tcp enterprise servers, XML db use, web-service clients, web-service servers, advanced node-based graphical pipelines, neural nets (one done entirely in REBOL :-), http clients accessing servers providing non browser guis, I've even made a crawler robot for a site built which does nasty anti-robot stuff (using cookies and timer + counter based redirected urls). I've basically built an asp contender with remark ( but much leaner and vastly less sprawled, one very simple object model handles everything, from resources to master templates, to db, styles, etc). I've programmed one of the most advanced procedural node engines I've used so far, in any platform and a lot of other things, and well, its always easier *overall* with rebol. its not always faster in execution, but there is soooo much less clutter in the way of having to program against the language or its framework. I really find that its always simpler, even when you must roll up your sleeves to solve a little issue which REBOL doesn't support natively.
> REBOL needs to enable the type of programming experience and end-user > apps that people are not getting from current scripting languages and > tool-sets.
I agree, but I find it already does, to a large extent. much more than many other systems without needing to understand much, I find. just the use of something like save and load is a god send you quickly long for in all other environments. for many, rebol goes against the long entrenched idea that complex things are more capable. some things are much less necessary in REBOL. so its hard to accept to release some coding habits in order to adopt another coding style. Having done REBOLing almost exclusively for so long now, I'm finding it hard to adapt to other languages now. simply cause everything just seems bloated and over-engineered, when in the end, it adds nothing to the actual delivered application. the issue is that simple things like an open field of grass, are harder to use in order to arrive somewhere, cause there is no obvious destination, there is more burden on the capacity of the architect. in complex systems, the architect is so tethered, that in fact, his role is reduced to implementing a predefinied path. so it is easier, but in the end, you are just as equal as every other person using a specific system. less capable engineers/architects cannot fathom using REBOL (I am talking experience here, hehe), cause its too open, not structured enough...and they are actually reminded that they lack something in what should be their primary qualities. just like bad managers often lack the qualities of being able to trust their own gut feelings, changing stuff, meddling and many other project/team destructing habits. I'm not saying R2 is perfect. some things are lacking, only that many people downsize it, when I have found that with minimal actual investement... its actually already capable of just about everything people keep saying it isn't. (this is a general reply... and not specific to your own comments... but its a recurring thread which I just wanted to address after having done REBOL professionaly for about 1 1/2 years almost full-time). there are big servers running mission critical stuff, for surprising companies... using REBOL... its just not something people advertise. they really don't care... as long as it works. the only issue I personnaly have is that the view engine (not vid which is built over it and is very flexible) is a bit too closed up, because eons ago, it was limited so that it would be the same on about 15 different platforms. that vision has changed a bit now, so R3 will be much more open to being adapted to the host, in order to benefit from each host's advantages... just like it should be. end users don't care how things are coded... but they really care when you change the way they are used to using software on their platform.... a common recurring comment... "what, no icon dropping? wtf?" -MAx

 [15/15] from: tim-johnsons:web at: 22-Nov-2007 11:08


On Wednesday 21 November 2007, Brian Tiffin wrote: Hi Brian: :-) I'm deleting all the '=20's - don't know where they come from but very likely, the list-serv
> It is a little bit of a catch-22. So many features that are visible > libraries for most scripters are a one or two-liner built-in for REBOL
Even the one-liners can extend the basic functionality of the mezzanine and be very enlightening to new and( in my case anyway) old programmers.
> But there are libraries we do need and those should be built and then
Much thought to give about how to organize them, for sure.
> propagated in a well defined and well advertised way. All planned...now > > > action? Hmmm, action. :)
You mean, like follow-up and follow-thru? Hahaha! One step at a time and you get there. tim

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted