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

ubf for Rebol?

 [1/6] from: bry::itnisk::com at: 8-Nov-2002 15:41


I recently switched over from learning Erlang to Rebol, as I thought Rebol had some uses in the product I'm working on right now, but it's stuff like UBF http://www.sics.se/~joe/ubf/site/home.html (UBF is a language for transporting and describing complex data structures across a network) that shows what I liked about Erlang to begin with. They've already got UBF drivers for Erlang, OZ, Tcl and Java, how about Rebol!?

 [2/6] from: greggirwin:mindspring at: 8-Nov-2002 10:20


Hi Bryan, << They've already got UBF drivers for Erlang, OZ, Tcl and Java, how about Rebol!? >> I haven't seen any REBOL implemenations. Looks like it could be a fun project, but I already have too many fun projects in progress myself. :) --Gregg

 [3/6] from: jan:skibinski:sympatico:ca at: 8-Nov-2002 11:20


Thanks for posting it Bryan. I took cursory look at the documentation but have not formed any strong opinion about it yet. It seems to me that it is in similar spirit as XML-RPC is (as opposed to Soap), but at the binary level. I know very little about Erlang, except some buzz around it. Its position among functional languages is somehow curious. On one hand it is an untyped language, on another - it is quite a successful practical language. As a result FPL community likes to point it out as an example of FP success - notwithstanding its lack of types. At the bottom of his whitepaper Joe Armstrong writes: << UBF was inspired from a number of different sources: [cut] The type notation in UBF(B) is similar to that suggested by Phil Wadler and Simon Marlow for work on an Erlang type checker. [cut] The protocol definition language in UBF(B) is similar to a suggestion of Wadler for typing Erlang processes. [cut]
>>
Do you see what I mean? FPL gurus were quick to add type checking to Erlang to suit their needs. And as I recall, they did it very early - in a year or so after Erlang was announced. Phil Wadler was instrumental in Haskell development. He wrote many good articles, many of those about monads. He is also a co-inventor of java extensions: Pizza and Generic Java. Simon Marlow works for Microsoft Research and is highly involved in several Haskell projects: hierarchical libraries and GHC.
> They've already got UBF drivers for Erlang, OZ, Tcl and Java, > how about Rebol!?
It certainly would not be a very big deal to implement it. But who would pay for the development? Another words, is there any strong motivation for doing that? Best regards, Jan bryan wrote:

 [4/6] from: bry:itnisk at: 11-Nov-2002 11:37


Jan Skibinski wrote:
>It seems to >me that it is in similar spirit as XML-RPC is (as opposed to Soap), >but at the binary level.
My opinion is basically that is presents a simple and extensible language for describing binary information. The comparison to Soap or XML-RPC is appropriate to UBF(B) which has a protocol description language. There are three modules I guess I would call them, UBF(A) , UBF(B), and UBF(C).
>I know very little about Erlang, except some buzz around it. Its >position among functional languages is somehow curious.
I found Erlang to be a nice cross between Haskell and Rebol, feelwise (Haskell in that it was functional Rebol that it was quite a bit easier than Haskell and also more focused on the practical IMHO), I was going with it instead of Rebol for a while because it was dead easy to pick up whereas Rebol's syntax can still sometimes throw me for a loop(hope there's no pun there). If I were to be working on any heavy telephony apps erlang would probably be my choice. Also has very nice libraries for working with ASN.1
>Phil Wadler was instrumental in Haskell development. He wrote >many good articles, many of those about monads. He is also >a co-inventor of java extensions: Pizza and Generic Java.
Yeah Wadler is also instrumental in building Xml Query so he's got his misses as well. :)
>It certainly would not be a very big deal to implement it. >But who would pay for the development? Another words, >is there any strong motivation for doing that?
Probably not, I am often hit by these wild enthusiasms when I come across something new and cool, until the cold light of the next workday reminds me I still have my own stuff to implement.

 [5/6] from: joel:neely:fedex at: 12-Nov-2002 14:04


Hi, Bryan, Since you mention it... ;-) bryan wrote:
> My opinion is basically that is presents a simple and extensible > language for describing binary information. The comparison to
<<quoted lines omitted: 3>>
> apps erlang would probably be my choice. Also has very nice > libraries for working with ASN.1
OK, we've got XML for human-readable structure/content, and ASN-1 for binary structure/content. Why do we need YAML? (Just curious!) -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446

 [6/6] from: bry:itnisk at: 13-Nov-2002 10:56


Joel Neely wrote:
>OK, we've got XML for human-readable structure/content, and ASN-1 for >binary structure/content. Why do we need YAML? (Just curious!)
why does anyone ever need another programming language than their first Turing complete one? I don't want to get into my philosophy of the necessities of change in any field of human endeavor, even if that change should lead to worse results - the indicator of which would be the switch from Keynesian economics over the last couple of decades as popular fields of economic studies, often replaced with economic theories that do a worse job of prediction. This is not to indicate that I think UBF would be worse, it seems very comprehensible such as for example the irc example at http://www.sics.se/~joe/ubf/site/ubfb.html ASN-1 can be difficult to work with? Although a propos that difficulty, for quick ASN-1 try http://www.oss.com/products/visual.html A visual ASN-1 tool! It's pretty cool I think.

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