Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Carl Sassenrath Talks About REBOL 246

Rebelos writes: "REBOL is a powerful software technology (ever thought that you could write a full blown GUI Instant Messenger in only 7 KB of source code?) optimized specifically for Internet usage. Rebol Tech, the company behind REBOL, consists of only 10 people and they claim they can compete and go against .NET and Microsoft's dubious plans. Their platform has been ported to 44 operating systems so far! Take a look as to what Carl Sassenrath, ex-AmigaOS/Commodore engineer and founder of Rebol, says at OSNews about the Rebol platform, its deployment, other programming languagees, Microsoft etc." The buzzwords are pretty thick in here, and the ideas are interesting, if a little vague. If the interview makes you curious, check out the previous stories touching on Rebol as well.
This discussion has been archived. No new comments can be posted.

Carl Sassenrath Talks About REBOL

Comments Filter:
  • Aha! (Score:1, Insightful)

    by ajuda ( 124386 )
    I can code a full blown GUI Instant Messenger in less than 100 bytes! apt-get install gaim. But seriously, if you can fit that much information in 7kb, hasn't someone already had to basially write the messenger first?

    They seem to be able to write such a small executable by building libraries especially for this project. Is anyone else thinking that a similar projet in C by them would have the following line: #include <guiMessenger.h>

    • Re:Aha! (Score:3, Informative)

      by Anonymous Coward
      But that is the whole point!
      REBOL is an *internet language*. For example, you can't write a graphics application with it (until now...). But if you want to write a fully featured GUI NewsReader, an Email Client, an IM or anything related to Internet or other simpler stuff (like a calculator, a simple word processor etc), then you can do it easily, because REBOL supports all these protocols internally!
      So, as C has a printf() and a uint32 for example, REBOL has an email DataType! It has a NewsReader DataType etc!
      Each language is good for some things and not so good for others. REBOL is the absolute Internet language.
    • Most of the networking libraries and stuff are already built in to the core. It's pretty damn small - something like 300k, with GUI support (widgets, etc). The biggest thing holding us back from having deployed this for a client is that there was no Mac GUi support when we checked (6 months ago or so). I think it's there now.

      That's what's a bit misleading about this - 44 platforms, but not all have GUI support, which is where I'd think the big win would be. If I want to simply script stuff on multiple platforms and one set of code I can use Perl (although it's not 300k!)
      • by znu ( 31198 )
        There's a Mac OS version now, but the OS X version is "Pending". That's a little annoying. Still, maybe I'll plat around with the core stuff.
  • Bold claims (Score:1, Flamebait)

    by LowneWulf ( 210110 )
    Hmmmm, that's some pretty bold claims they make... considering I've never heard of them or their products before...

    Has anyone actually USED this that can elaborate on its effectiveness?
    • Re:Bold claims (Score:4, Insightful)

      by PlaysWithMatches ( 531546 ) on Sunday October 28, 2001 @05:03PM (#2490484) Homepage
      I've used REBOL quite a bit, and I'll say one thing up front: this is not going to be a Microsoft killer, or a .Net killer, or whatever. But REBOL is very good at what it does, which is offer a high-level interface to web, e-mail, etc. scripting. The language is pretty nice once you get into it. But for 99% of my scripting, I still use Perl. Will that change because of REBOL? I doubt it.

      Nice toy anyway, though.
      • I thought about this as well. In my perception, the success of the Rebol concept depends on two basic developments:

        1. Open availability, through independance of the software maker

        2. Structure and discipline concepts in order to avoid a mess.


        Although (point 1), there is a group developing Rebol as open source (OSCAR), the last time I checked, there was still no source code available. So I started my own implementation, btw absolutely not available yet because I don't have that much to offer right now.


        Rebol's best idea is the distributed computing model. They actually state that the good ol' webbrowser is a load of crap, and basically unsuitable for the things we want to do. They have a point there, because as a prof web developer, I can't believe the efforts I have to make, just to create something simple. IMHO a web browser is only suitable for text and images. I see the plugins merely as patches, fixing the shortcomings of the browser.


        So Rebol says - the browser 's gotta go, and we'll introduce a new internet application environment; a successor to the webbrowser.


        Besides that, Rebol is a very good language for scientific research in the investigation of polymorphical algorithms; ie an algorithm is an idea, and code is an implementation of this idea. The keyword reprogramming feature of Rebol gives flexible tools to understand the idea of an algortihm better, perhaps that one implementation could serve multiple uses. This is ofcourse not the same as a reusable object, I'm talking about a reusable algorithm.


        Still, I think Rebol is kinda cool!

    • Re:Bold claims (Score:2, Informative)

      Well,

      Rebol is in the news for about two years now ...

      It was mentined in BYTE magazine adn Dr. Jobbs, years ago.

      Its your fault if you have not heared ybout it not theirs ...

      I only did not use it because the language is YANS language. (Yet Another New Syntax).

      The same results would have been possible with calling the object creation operator: new, like in C++/JAVA/Smaltalk and other languages. They name it "make".

      And that goes on ....

      OTOH nice inventions (but also not realy necessary) like variabel access of objects via the slash (like in ordinary unix path/file names).

      Instead the C++/JAVA style for accessing account.balance they use account/balance.

      Rebol gives you first class citizens for all kinds of web and natural datatypes, like times (10:55 is just a time object), dates (2001-10-28 is a literal for a date object). Basicly all net protocolls are supported like in curl.

      Well, as I said: unfortunatly they invented yet another damn syntax ... I would have loved to have this either in C++ or in JAVA integrated :-)

      Regards,
      angel'o'sphere
  • From the system side, we will add several new "dialect" engines for 3D graphics, inferencing ("AI"), additional network protocols, advanced sound synthesis, and more.

    Call me cynical but IMHO claiming to make a 44 platform language and then creating "dialects" is shooting yourself in the foot while running a marathon with microsoft, the 1 thing they could really win on is FULL platform independece, this is NOT platform independence

    he, next thing we'll see is that you'll have to run the windows version of the client to play online directX games in WINE(X) ;-)
  • big deal (Score:5, Interesting)

    by mj6798 ( 514047 ) on Sunday October 28, 2001 @04:52PM (#2490447)
    High level scripting languages are a dime a dozen. Systems like expectk and wxPython give you similar ease of programming. If you like something more Lisp-ish, there are various Scheme systems with built-in GUIs. The main thing that distinguishes Rebol is that you can't get an open source implementation of it and that it has a much smaller user community.

    As for "going against .NET", big efforts like that are not about technology, they are about marketing and people. And they are also about the long-term availability and tools support that a large company like Microsoft (or Sun, in the case of Java) brings to the table.

    But even technologically, it is an error to confuse a scripting language with a system like .NET or Java. Yes, Rebol, Python, and Perl are much simpler to program than .NET or Java. Yes, they run a few important things somewhat faster. But .NET and Java are natively compiled, fast, general-purpose programming environments with static type checking and large libraries (written in Java itself in the case of Java), and that just makes them much more useful for large-real world problems. You see, another misconception is that the easier you make programming in a language, the more useful it is in real-world applications.

    • Re:big deal (Score:3, Informative)

      by majcher ( 26219 )
      Yes, Rebol, Python, and Perl are much simpler to program than .NET or Java. Yes, they run a few important things somewhat faster. But .NET and Java are natively compiled, fast,...

      I don't know about .NET, but Java is compiled into bytecode, which is run on a natively compiled byetcode interpreter. Just like Perl, Python, Ruby, etc. are. This has been a major piece of Java FUD for the longest time - it pretends to be a compiled language, because it doesn't want to be seen as "just another scripting language". As for the libraries and penetration available for Java, do you not think that if Sun had developed and spend untold millions marketing Perl or Python that they would not be in the same position? As a language, Java lacks in many areas - it's just the most popular kid on the block because it's dad happens to be rich.
      • It can be distrubuted in bytecode, but it can also be compiled just-in-time into an executable that runs natively, without a JVM. This requires a more complete environment on the target machine to support this bootstrap, but then, you could also just distribute the resulting binaries. As an example, there's the Java target for GCC (gcj) which creates actual executables from java source code.

        And compiled java is almost as good as compiled C (it won't win most speed tests, but the resulting code is pretty much insulated from the system, protected from buffer overflows, etc.)
      • I don't know about .NET, but Java is compiled into bytecode, which is run on a natively compiled byetcode interpreter. Just like Perl, Python, Ruby, etc. are. This has been a major piece of Java FUD for the longest time - it pretends to be a compiled language, because it doesn't want to be seen as "just another scripting language".

        Sorry, but you don't understand how Java implementations work. When you run "javac", you produce byte code. That byte code gets turned into native code before being executed when it is part of a performance critical section--the native code compiler is part of the Java runtime.

        Python, Perl, or Ruby do not have anything comparable: they are implemented as strict byte code interpreters (except for Jython, which piggy-backs on the Java runtime). In fact, the Java approach is better than the kind of batch compilation found in C/C++ because it allows for a lot more optimizations. For example, the JDK inlines code among dynamically loaded components.

        As for the libraries and penetration available for Java, do you not think that if Sun had developed and spend untold millions marketing Perl or Python that they would not be in the same position?

        Python or Perl are no replacement for Java. With a few exceptions, Java code runs at speeds pretty close to C/C++ under the JDK. Python and Perl implementations are orders of magnitude slower and nobody has figured out how to compile them into efficient code.

        • In fact, the Java approach is better than the kind of batch compilation found in C/C++ because it allows for a lot more optimizations.
          I wouldn't go that far. There are several things impeding Java optimization:
          1. It occurs at runtime. With C/C++, you have unlimited time to optimize the code. With Java, time spent optimizing counts against program execution time.
          2. Java bytecodes use a stack-based paradigm, which is notoriously hard to optimize. Most C compilers have a register-based paradigm, whose optimization is well-understood (if perhaps not yet perfected).
          3. Java programs load classes dynamically. Every new class has the potential to clobber any assumptions you made in order to achieve any agressive dynamic optimizations. In the worst case, a Java runtime has to have all the functionality of "make" so it can compute what has changed and re-compile it as necessary.
          Dynamic optimization has a lot of promise, but with the state of technology today, it's hard to argue that C isn't faster than Java.
          • I wouldn't go that far. There are several things impeding Java optimization: 1. It occurs at runtime. With C/C++, you have unlimited time to optimize the code. With Java, time spent optimizing counts against program execution time.

            For any reasonably compute intensive task, compilation and optimization time is negligible. You can see that either by instrumenting a Java runtime. Or you can just look at where C/C++ compilers spend their time (a lot of reparsing of header files, as well as semantic checking and linking, none of which are incurred by Java compilers) and what fraction of the code of any real program really needs to be optimized.

            2. Java bytecodes use a stack-based paradigm, which is notoriously hard to optimize. Most C compilers have a register-based paradigm, whose optimization is well-understood (if perhaps not yet perfected).

            If the JVM supported general stack-based computations that would be true. However, the JVM prohibits general stack-based computations: it requires that the stack is in a "defined state" (in a certain sense) at each byte code. The upshot is that Java byte code is essentially just a binary postfix representation of the source code. Turning that into native code is no different from what the C compiler does. (In fact, the claims in the introduction to your JHP paper are wrong, precisely because Java does not use a general stack-based architecture.)

            3. Java programs load classes dynamically. Every new class has the potential to clobber any assumptions you made in order to achieve any agressive dynamic optimizations. In the worst case, a Java runtime has to have all the functionality of "make" so it can compute what has changed and re-compile it as necessary.

            Well, so what? The necessary dependency tracking is both trivial and fast. Furthermore, because of the way Java is designed (and unlike C), there are only very few important dynamic optimizations that dynamic loading can invalidate. Note that Java does not support class reloading in high performance code (it's supported only for debugging).

            Dynamic optimization has a lot of promise, but with the state of technology today, it's hard to argue that C isn't faster than Java.

            Dynamic optimization is completely up to the task of compiling Java as well as any C compiler compiles C code. Java pays a little bit of overhead for runtime safety (less than 20% by most estimates) and there are a few areas of Java where the language definition unnecessarily prohibits optimizations (this is being addressed). Except for those areas, Java as a language is pretty much as easy and efficiently compilable as C or C++. In fact, if anything, Java has additional opportunities for optimization because of its more limited pointer model. Dynamic optimization and (closely related) partial evaluation also have been understood for more than a decade, so this isn't exactly cutting edge.

            Of course, Java libraries are often pretty slow. But that's because many Java libraries are written with a lot (too much in many cases) generality and abstraction.

            Note, of course, that batch compilers for Java exist, but they generally perform no better than a good JIT these days.

        • The other scripting languages do something Java does not do well -- they integrate with compiled C modules and libraries. If you want speed in those languages, you write critical inner loops in C. It's not incredibly easy, but with OSS someone else will often do it, and that speed-critical piece of code will be written in reusable fashion.

          AFAIK, this is simply not possible with Java. You can potential create some sort of network service written in a fast language, and access that through Java (as with a COM/CORBA object), but that doesn't offer the level of integration and speed that the other scripting languages have with their more modest integration.

          • Java has a standardized C interface. Something like SWIG (swig.org) makes accessing it pretty trivial. Several vendors also make compilers that expose C++ classes directly as Java classes.

            The problem with mixed language programming like that is that C/C++ code is unsafe, and that the semantics of C/C++ code often differ wildly from the semantics of the HLL. For example, how do you extend a C++ class with Python code and pass an instance of that back to a C++ class?

            The point about Java is that it is a pretty "fast language" (i.e., its common implementations are fast). You can write reasonably efficient image processing or string handling code in Java if you put your mind to it. So there is generally no need to use C/C++ other than for interfacing to system services. As a result, you get more portability and more runtime safety.

        • Sorry, but you don't understand how Java implementations work. When you run "javac", you produce byte code. That byte code gets turned into native code before being executed when it is part of a performance critical section--the native code compiler is part of the Java runtime.

          Are you sure you know how Java works? What you are describing is Just-In-Time Compilation and Hotspot'ing and it's not mandatory. Your better Java interpreters support this, not all of them do however and this isn't required by the spec (unless times have changed). Java is, in fact, compiled to byte code and may be further compiled into native code, pending your JRE choice.

          As far as performance goes; you must be the only one in the world seeing close to C/C++ performance. Even Sun has admitted that Java will probably never live up the hype of replacing C/C++ for speed intensive applications. If you can get that kind of performance on most of your code, I've got a seven figure a year job waiting for you as a lead Java engineer.

    • But even technologically, it is an error to confuse a scripting language with a system like .NET or Java.

      .NET and Java are not even in the same class. One is a language. The other is a marketing buzzword that covers a variety of technologies. Be more precise. What part of .NET are you talking about?

      Yes, Rebol, Python, and Perl are much simpler to program than .NET or Java. Yes, they run a few important things somewhat faster. But .NET and Java are natively compiled, fast,

      In general, Java is bytecompiled, just as most scripting languages are. Sometimes Java can be JIT-ted to native code. Sometimes scripting languages can be JIT-ted to native code.

      general-purpose programming environments with static type checking and large libraries (written in Java itself in the case of Java)

      Java's library is not larger than CPAN and certainly is not larger than Jython's. The scripting languages originated the idea of large standard libraries. Python is known as the "batteries included" language. Java and C# (.NET is not a language) are relative johnny-come-latelies.

      and that just makes them much more useful for large-real world problems. You see, another misconception is that the easier you make programming in a language, the more useful it is in real-world applications.

      It isn't just about ease. Dynamically typed programming languages allow you to radically decrease your line count and all else being equal that reduces your original development cost and your maintenance costs. We could argue whether "all else is equal" but I think rather that I'll point you to some evidence that significant systems can be created in dynamically typed programming languages. Python case study [lyra.org], Using Lisp to Beat your Competition [slashdot.org], Smalltalk in the Large [bytesmiths.com]

      • It isn't just about ease. Dynamically typed programming languages allow you to radically decrease your line count and all else being equal that reduces your original development cost and your maintenance costs. We could argue whether "all else is equal" but I think rather that I'll point you to some evidence that significant systems can be created in dynamically typed programming languages. Python case study [lyra.org], Using Lisp to Beat your Competition [slashdot.org], Smalltalk in the Large [bytesmiths.com]

        I have nearly 20 years of experience with Lisp and I can tell you that it doesn't live up to the hype. For large, multi-programmer projects, the mix of static and dynamic features Java offers works much better.

        You don't have to look much further than the few open source projects based on Lisp and Smalltalk. GNU Emacs is very slow at releasing new versions and elisp packages are a mess; jedit is getting close to similar functionality after only a few years in existence. The Squeak implementation of Smalltalk is great, but it, too, has turned into a complex and largely undocumented mess. Languages like Smalltalk, Python, and Lisp are great for smaller projects and for single programmer projects.

        In general, Java is bytecompiled, just as most scripting languages are. Sometimes Java can be JIT-ted to native code. Sometimes scripting languages can be JIT-ted to native code.

        That's a mischaracterization. With the major Java implementations (Sun, IBM, Intel), Java is always JITted into efficient native code, and the Java byte-code is well-suited to that. None of the major scripting languages (Perl, Python, Tcl, Ruby) have a widely-used JIT, and nobody has ever demonstrated a native code compiler for those languages that results in performance anywhere near native code. CMU CommonLisp, arguably one of the best compilers for dynamic languages, does very poorly without type declarations.

        • what's the big deal with these compiled/interpreted arguments? Can't you compile [bearcave.com] java source if you want, no JVM required? Isn't it also true that most performance problems are located in a very small portion of the code, but it's extremely difficult to figure out where (ahead of time)? So why not just write it all in java and then mix 'n' match interpreted java, compiled java, FORTRAN, Guile, or whatever?
          • Yes, you can compile Java reasonably well both with a batch compiler (like gcj or Jove) and with a JIT (like the Sun, IBM, and Intel runtimes). And you actually get good performance out of it.

            The nice thing about JITs is that you don't have to worry about figuring out what to optimize: the runtime does it for you, and it is doing a better and better job at it.

            Nobody has ever produced a compiler for Python or Perl that gave performance close to a good Java compiler. The situation with Lisp and Smalltalk is a bit more complex; there are good compilers for them, but getting good performance out of those usually ends up being more work than getting good performance out of Java.

      • Re:big deal (Score:3, Insightful)

        by Jay Carlson ( 28733 )
        NET and Java are not even in the same class. One is a language. The other is a marketing buzzword that covers a variety of technologies. Be more precise. What part of .NET are you talking about?

        Java is a marketing buzzword that covers a variety of technologies. Quoting http://java.sun.com/java2/whatis/ [sun.com]:

        The JavaTM platform is based on the power of networks and the idea that the same software should run on many different kinds of computers, consumer gadgets, and other devices. Since its initial commercial release in 1995, Java technology has grown in popularity and usage because of its true portability. The Java platform allows you to run the same Java application on lots of different kinds of computers.

        [...]The idea is simple: Java technology-based software can work just about everywhere. Java technology components don't care what kind of computer, phone, TV, or operating system they run on. They just work, on any kind of compatible device that supports the Java platform.

        Notice how they don't say "Java is a language..."?

        In the Java 1.0 days there were essentially three things referred to as Java: the JVM, the language, and the standard library. Oh, and maybe something about delivery of applets through sandboxed bytecode. Four things Sun wanted you to think of for the term "Java". Now there are a zillion [sun.com]. Soon [jcp.org], there will be a zillion and fifty [jcp.org].

        OK, OK, those aren't at the same architectural level as the big three components. But "Java" has become increasingly vague, and don't think Sun isn't encouraging this. They want non-directed feelings of goodness associated with whatever's in their (proprietary) platform this week.

        If what people wanted from Java was just a language, in the traditional view of what a language is, gcj [gnu.org] would have taken over the world by now.

      • .NET and Java are not even in the same class. One is a language. The other is a marketing buzzword that covers a variety of technologies. Be more precise. What part of .NET are you talking about?
        Java is as vague as .NET [jwz.org]
    • The main thing that distinguishes Rebol is a tiny footprint, and ground-up design for interaction in a networked environment.

      Technologically, you have no clue what .NET or Java are about. Java by virtue of syntax and documentation is probably the simplest of languages around, and both .NET and Java run as bytecode on interpretters.

      But most important, Java (and to some extent .NET) is significant for real-world enterprise applications because it defines specifications for interoperability. J2EE is not about providing programming libraries; it is about providing standards.

      Rebol falls flat on this count in the same way as every other programming language: you have to lock yourself into a vendor at API level, not at language level.

  • Licensing (Score:5, Informative)

    by Eloquence ( 144160 ) on Sunday October 28, 2001 @04:52PM (#2490449)
    The problem with REBOL, IIRC, is its license. The professional interpreter is commercially sold, which means that you have to license it even for distributing your apps, since REBOL does not generate executables. At least the standard version is free beer. But this probably makes it more expensive than VB, where you only pay for the platform once. So it can't compete on Win32, and without being OSS, it will hardly be able to compete on non-mainstream platforms.

    That's a real shame, because other than that, it is really quite impressive. They should think about a Transgaming-like business model, where users subscribe and the code becomes free when there are enough subscribers.

    • thats not the only problem. its also a scripting language and has crude hacks like assigning EmailAddress as a datatype instead of a string. its more like a bash shell for the web rather than a full featured language.
      lack of a free run time interpreter kills it right off the bat tho.
  • All these friggin ['s and ]'s.... Everybodies got to be original.

    How is this any different from perl & tcl/tk? Couldn't the same be accomplished?

    Don't think it will ever take off if you ask me...
  • by Waffle Iron ( 339739 ) on Sunday October 28, 2001 @04:57PM (#2490467)
    There have been quite a few self-contained systems architecture solutions put out over the years (Java and Smalltalk come to mind), and this looks like another one. All of them meet a lot of resistance because they make you use a language that is not the favorite language of the 90% of developers out there who have a different favorite language.

    No matter what you think about Microsoft and its practices, the .NET strategy is more likely to attract a wide variety of developers because it allows them to use most any language they want. (.NET has an OS lockin problem, but the 90%/10% ratio is in MS's favor in that case).

    REBOL may be extremely cool; I'm going to have to take a look at the language spec. However, I don't think that any single language will ever take over the whole world.

  • rebol kicks bootie (Score:4, Interesting)

    by LazyDawg ( 519783 ) <lazydawg@ h o t m a i l . com> on Sunday October 28, 2001 @04:57PM (#2490469) Homepage
    If it weren't for rebol I wouldn't have a 25 line script to grab the stock market closes every day from yahoo.com. If you want to get batches of web pages and parse them for useful information, use rebol. It rocks.

    If it were more widely accepted, rebol would make a really sweet web language, too, allowing more control over the interface, with less garbage in the page's source code.
    • by Anonymous Coward
      Oh yeah - it does not exist. Rebol is proprietary, so why would anyone want to use it?
      • by Anonymous Coward
        Actually, there's the OSCAR project [yahoo.com] which wants to create an open REBOL interpreter. Don't think they will ever come anywhere near it though.
    • This could be accomplished in Perl with about the same number of lines. Any language can do this as long as proper libraries exist. The fact that it is built into the language is not an advantage, in fact it is a disadvantage because you have less flexibility and options.

      I'm sure rebol is nice and you can be productive in it, but it won't have anything that you can't do in another language.

      • Great, but without libraries, using a ~900k executable, I can do an http interface, download a web page, parse it for content, then save that content to a file. Perl without libraries can't do that without worrying about the actual http protocol, meaning rebol saves people from having to reuse big blocks of code.

        For beginning users, this ease of use is important because it frees them to do more creative things, faster, and easier.

        Having an OpenRebol, however, would be very very nice, just for more advanced users who want to roll their own rebol or rebol like substance, with better features.
        • by ikekrull ( 59661 ) on Sunday October 28, 2001 @07:47PM (#2490919) Homepage
          well, theres at least 800k of statically linked libraries right there.

          Without libraries, if you wanted to change or upgrade your HTTP component, you'd have to d/l another 900k executable, instead of using something nifty like the CPAN module.

          There really is nothing stopping somebody from compiling Perl, Python, Tcl or any other language and a bunch of it's essential libraries into a single 'executable' you could use to do exactly what the REBOL environment does.

          Its just not usually done, because most people using these tools recognize the benefits of being able to dynamically load libraries as needed, and add/upgrade/modify/swap them individually.

          This is not to say that REBOL doesn't do the job, since it obviously does for your purposes.

          However, I, like many others, would have to take issue with the idea that YAHASL (Yet Another Half Assed Scripting Language) is going to 'revolutionize the internet' in the same way that Java has completely failed to do.

    • Ok, here's an example of someone who doesn't really understand what "really sweet" means.

      I found this off the internet, it's a way to use a .Net web service to grab the stock market closes from yahoo.com.

      http://www.dotnet101.com/articles/art031_StockQu ot esWebSvc.asp

      It's kind of an interesting kludge. You place a .Net webservice in between the client and the yahoo stock pages.

      Better yet would simply be if Yahoo(or whoever) provided a web service you could instantiate, pass it the stock you want a quote on and it would return a value. Makes life tremendously simpler and no need for about half the code that was written in the above article.

      Enjoy
    • http://finance.yahoo.com/d/quotes.csv?s=MSFT+ORCL+ INTC&f=sl1d1t1c1ohgv&e=.csv

      ...will give you a nice comma-sepped response:

      "MSFT",62.20,"10/26/2001","3:00PM",-0.36,62.32,6 3. 63,62.08,32257100
      "ORCL",13.58,"10/26/2001","3:00PM",-0.37,13.71,1 4. 08,13.40,46623900
      "INTC",25.86,"10/26/2001","3:00PM",-0.24,26.01,2 6. 50,25.55,45507200

      Why would you endure HTML-parsing hell when Yahoo provides this interface?

      Happy Halloween,

      G. Sherman
    • Comment removed based on user account deletion
  • ...then REBOL is likely to give you nightmares! Good God, people, I have not seen any other language as bloated as this one! Not even Java can come close in the terms of the sheer amount of crap already included in this language!

    I mean, what happens if you don't happen to like the way that this thing handles TCP connections on your particular platform? You are basically screwed, as not only are underlying routines written in another language, but you don't even get to see the source! I'm shocked that Slashdot would even post such a thing here, considering that the closest analog that I can find to this is VB, and, honestly folks, we do not need more idiots of the using class writing their own AOL Instant Messanger or other crap like that that will probably kill the network I admin.

  • oh, no (Score:1, Troll)

    by krokodil ( 110356 )
    oh no! not another Perl!

    Seriously, people should be more careful advertizing such toy scripting languages. Some managers take their words for real and then force us, developers write serious systems using them. What about concurrency/synchronization? memory management? OO constructs? how efficient are byte manipulations? Does tail recusion eats up stack? It is nice to have 'ftp' as language construct but that does not make it 'Internet' developement language.

    • You're right, it's _not_ another Perl. REBOL code is actually _readable_ by human beings, and consistent in syntax. Too bad about the license, though. *shrug*
  • Especially considering I've just downloaded the new version of messenger and it weighted 1.6 megs... MSN is going the same path that ICQ went to... small efficient, does the job, to getting bloated, bigger downloads and 3/4 of the stuff you'll NEVER use, all this without giving you the option to have a simple light-memory-usage solution still available (forcing you to go to alternatives or archives sites to download older clients, which eventually will become incompatible with a newer build that will change the protocol.

    I'll support anything that is not following that path. Things don't have to be BIG to be good, (of course I am talking only software here :) ).

    On another note, the new .NET version of messenger has UGLY icons, man, the :) is scary, and you even have one smiley guy on crack (try :-| )
  • REBOL has done some real innovation here. Great work! To me, it seems like it is easier to create cool apps (applets) for the web in no-time.

    Just too bad I have to learn "yet another programming language" ...
  • Another fucking messenger. I have
    - icq
    - aim
    - msn
    - ym
    on my box right now.
    Though I see the point. There should be no reason an instant messaging system be over one meg. Lets be honest, you're sending small bits of data between two boxes across the net.

    • This is waaaaay off topic, but if you weren't just exagerating, you need to download the trillian IM client. I use it now for my accounts on all those above plus IRC. I'm really happy with it (it's not as flaky as Jabber).

      http://www.trillian.cc

      -Russ
  • by Anonymous Coward
    (our product) is a powerful new software technology by (our company) that is proprietary, commercial, and not Open Source, but will compete with Microsoft.

    We only have 10 employees, and no advertising budget, so with the collapse of the dot-com hype machine I need a new way to generate press to show to venture capital companies.
  • ...about small development cycles and source files. If that was all it took, there a dozen much more established laguages and tools which should have ousted them long, long ago. It'll take more than YAP to beat the beast....

  • (ever thought that you could write a full blown GUI Instant Messenger in only 7 KB of source code?)


    Ever use Delphi? Anyways, I would hardly call that "full blown".

  • by mickwd ( 196449 ) on Sunday October 28, 2001 @05:43PM (#2490579)
    REBOL might be fantastic for all I know. But when I hear some-one say that something "was designed from a meta-circular view of language semantics" that sounds like the perfect description of bullshit to me.
    • by alienmole ( 15522 ) on Sunday October 28, 2001 @06:55PM (#2490775)
      was designed from a meta-circular view of language semantics

      He didn't just make that term up, if that's what you're thinking. A "metacircular" language is a language which is implemented in itself. The most common example of this is Lisp - in fact, the very first computer language interpreter ever was a Lisp interpreter, written in a Lisp-like language as something of a mathematical exercise, by John McCarthy around 1958. This approach has proved very powerful, and some good language implementations have been written this way.

      The term is probably most famously used in SICP [mit.edu], in a section entitled The Metacircular Evaluator [mit.edu].

      Of course, none of this implies that REBOL is any good, but the fact that Sassenrath is aware of such things is probably a good sign. If you read the rest of the paragraph after the term "meta-circular", you'll see that he is actually referring to a relevant aspect of REBOL, namely that the GUI system is implemented in a dialect of REBOL. So it isn't quite as bad as if he'd said that the language runs on free tachyon energy...

      • A "metacircular" language is a language which is implemented in itself.

        Huh. In the compiler world, that's called bootstraping. Face it, they really just want you to ooh and ahh over the complex sounds of "meta-circular view of language semantics" without really understanding it. If the fact that the language is bootstraped is such a selling point, they could have simply said "implemented in REBOL".

        I guess someone had to take Scriptics's place as the peddler of hype over technical merit.
        • I don't think I did a good job of explaining what "metacircular" usually implies. There's a little more to it than simply bootstrapping. Certainly any metacircular language has to be bootstrapped at some level, but that's an implementation detail that has little to do with the nature of the language being implemented.

          In interpreted languages that allow procedures to be treated as data values, it is very easy to write an interpreter for those languages in the language itself, because the language has features that make it easy to write code that manipulates other code, evaluate expressions, and so on. The same is not true for writing a language like, say, C, since C itself doesn't contain any particular features oriented towards such tasks. Writing a C compiler in C has to be done "the hard way". Writing a Lisp interpreter in Lisp is trivial by comparison.

          Saying that a language is capable of implementing itself in a metacircular fashion implies that the language has capabilities which go beyond those in traditional languages like C, Basic, or Java, none of which can really be said to be metacircular. An important implication is the ability of a language to operate on its own code at runtime, which is why metacircular languages usually support higher order functions. Metacircular languages are also good at implementing other languages with minimum effort.

          Smalltalk is another language with metacircular features. For something more unusual, here's a brief mention of an implementation of Postscript in Postscript [catalog.com]. I picked this link because it contains some clues to some of what a metacircular interpreter can buy you; I'm not sure I can explain it any better without getting into code samples in Scheme, and SICP does that better than I could.

          Based on Sassenrath's description, it sounds as though REBOL has some features which can validly be described as metacircular. If he's trying to dazzle people with his language, he's at least doing so in a way which communicates something meaningful to those familiar with the terminology, as opposed to making completely gratuitous claims.

    • Say what you want, but a language with "forever" as a keyword seems pretty darn circular to me.
  • Any guesses? (Score:2, Insightful)

    by teyu ( 170456 )

    "...we have a partnership that will be putting REBOL onto 30 million desktops within the next few months."

    I just had images of millions of AOL cd's dance through my head. With the types of services this provides and their claims to be a .NET alternative, who else could they be partnering up with?

  • Looks like JNLP.. (Score:2, Insightful)

    by mergatoriod ( 149240 )
    Okay, so I downloaded the viewer 362K (so far so good..)

    Run the installer, took a few seconds (great!)

    Took a look at the demos, only a few seconds to download and view (quick!), and then I quickly lost interest. The demos are rubbish!

    Visited some of the other Rebol enabled sites, the demos did not get any better!

    I just don't see anybody wanting to write any serious applications for this platform. JNLP the Java web application launching protocol has much better demo applications available. http://java.sun.com/products/javawebstart

    Show me a serious application such as a paint program or a game and i'll take this seriously otherwise forget it!

    • Java and Java Web Start are a long way from this thing. I mean Rebol's a 300k download for starters - even with all the bells and whistles it's less than a meg. Compare that with the 20meg download for Jdk1.3. And Rebol seems to work well over a slow connection. I was just playing with the demo apps and they download really quickly and run fast with little delay... unlike applets.

      But along the Java line of thought, does this remind you of the Marimba stuff from circa 1996? Remember Bongo and Castanet and how you were able to write your own custom Java-ish apps that would be internet updateable? Rebol is obviously a much better implementation, but it's very similar in idea. The control panels are similar, the demo apps are similar...

      I'm not ready to give up Java yet, especially for this wacky language that has little to no support (30 million upcoming clients or no), but after playing with it, I can see why Rebol's pretty cool.

      -Russ

      • To run java apps, you don't need the (rather large) JDK, just the JRE, which is smaller.

        Java Web Start does appear to be a new (and nicely implementated) instance of the same idea that Marimba had working in 1996, though.
    • You obviously didn't run any of the demos - I could send you a snapshot of my windows machine running the stock rebol view with the demos - there's at least 4~5 games on there.

      instant messager looked pretty cool - maybe serious, the skin selector looked pretty cool. There were also some image manipulation demos I saw that looked pretty cool. And the desktop itself looked relatively serious - I've never seen a Java desktop.
  • Who cares. (Score:1, Flamebait)

    by Ogerman ( 136333 )
    Why would any Slashdotter care about a proprietary language and its proprietary compiler that is far inferior to Perl? Point us to an informative guide to educating newbies on a real scripting language at least. Or if there's no news to post, don't post it.
    • by FFFish ( 7567 )
      "Why would any Slashdotter care about a proprietary language and its proprietary compiler that is far inferior to Perl?"

      Hey, you misspelt "Python."
  • A sort of basic clone for the good old Amiga. It seems like a cryptic language to me who are used to the C++/java style. The functions reminds me of AMOS, ie there are prebuilt functions for most simple stuff, however writing a simple Instant Messager in Java doesn't require extreme amounts of code either. I wrote an GUI Instant Messager in Java with the most common functions, incl. https connections, udpconnections, tunneling, etc and if I remember correctly it was just around 7000 lines of code in 8 sourcefiles (about 12 classes).
  • Love or hate Perl, Larry Wall has some interesting thoughts and comments [google.com] on REBOL.
    • by Anonymous Coward

      I read that article three years ago. Most of the concerns that Mr. Wall mentioned back then have been fixed already, particularly the speed issues.

      The version of REBOL that he was reviewing was based on a Scheme-like engine, and thus was comparable in speed to interpreted Scheme. More recent versions of REBOL, even a couple months more recent, have been based on a Forth-like engine. This allowed a sometimes ten-fold increase in speed with almost no language changes.

      REBOL is now comparable in speed to Perl (often as fast, but with some differences, particularly math). No regular expressions though - you'll have to make due with the much more powerful recursive-decent parser dialect, with backtracking even. Oh well :)

      Perl people might find the lack of operator precedence annoying, though (and probably the readable code as well). You get used to it.

  • Okay, I see absolutely nothing useful here. It is a fat, disturbingly bloated high level language, with no perticular improvment in theory or concept over something such as java, but with even -more- built in functions. Is there anyone else here who would rather see something more interesting than a CEO trying to get his name out?
  • check out the Rebol page of existing apps [rebol.com] - all pretty small.

    They have a desktop/OS app that looks cool but doesnt make much monetary sense to me on a desktop unless you custom design a cheap thin client to run it and only it on.

    What does make sense though - is running these little apps on a wireless handheld. Build the Rebol assembler into an ASIC so it runs native code quickly - and let the application server do all the work.

    Rebol looks cool but just like most java apps on the desktop are passed over for native code, I dont see this flying. Perhaps if they sought to fill the niche market of weak wireless devices theyd have more success. In either case good luck to them - I havent had the chance to do any cool machine level programming like this since I lost my TI and its various shells.
  • Looking at some of the text-parsing examples made me cringe...this was not made with Huffman optimization in mind...use "any" "all" "some" instead of "* . ?"!!! Even minor text parsing examples seemed to require way too much code.

    Can anyone confirm this? Is text parsing in REBOL best done with regular expressions or some other means?
  • Astroturfing? (Score:1, Flamebait)

    by brendano ( 457446 )
    Take a look at the comments to the osnews.com article. Every frickin' one is incredibly positive and written in the same buzzword-rich, press-release style as the interview itself, extolling the virtues of REBOL. The only non-exuberantly-positive posts are ones asking about negative aspects to which there's no answer.. Is a response like that possible on a fairly moderated messageboard? It looks like the posters are selling the product instead of commenting on their experiences with it...
    • Yeah I noticed this too. They all have similar "testimonial" titles, and then great lines about the app. As a poster notes, it's like an infomercial for a fitness product. Some investigation into the IP's would be good, for some reason OSNEW's hides a random part of the IP...
  • Rebol Tech, the company behind REBOL, consists of only 10 people and they claim they can compete and go against .NET and Microsoft's dubious plans.


    So in other words, they are a company of 10 employees, but they have about $147 billion in capital?
  • Instant messaging in just 7K? Yeah. I just did it in Perl. Client and server each in under 1000 bytes, basic messaging.

    I betcha if I throw in a GUI via Perl/Tk it'll bloat to 7k. Maybe.
    • Oh, here's a short listing to prove it:

      tygris@tygris:~/perlIM$ ls -l
      total 24
      -rw-r--r-- 1 tygris users 152 Oct 28 21:44 pim
      -rw-r--r-- 1 tygris users 994 Oct 28 21:54 pim.pl
      -rw-r--r-- 1 tygris users 675 Oct 28 21:25 pim.pl~
      -rw-r--r-- 1 tygris users 870 Oct 28 22:18 pimd.pl
      -rw-r--r-- 1 tygris users 994 Oct 28 21:55 pimd.pl~
      -rw-r--r-- 1 tygris users 142 Oct 28 21:25 pim~

    • Interesting point - why not just do this with Perl/Tk (for the interface) and Perl on the server?
  • Why this stuff sucks (Score:3, Interesting)

    by MSBob ( 307239 ) on Sunday October 28, 2001 @11:05PM (#2491451)
    I'm running eight different rebol apps on my system all at the same time. Each weighs in at between 6 and 12 MBytes. That's waay too much for such primitive apps (like that calculator using up 6,804K ). With such memory consumption this thing just eats memory like peanuts more so than Java. That's why I find Java unacceptable and that's why I think this stuff is crap too.
  • Thats odd, I was able to write a full-blown chat server in python, multithreaded non-blocking, with various commands and such, in less then half a KB of source (191 lines of code, to be exact)...
    Languages such as python and perl are designed for this sort of thing - they have amazing libraries that let you concentrate on your app and its problems.
    Rebol is not open sourced, yes?
    Alternatives that are amazingly powerful exist, yes? And these alternatives are open source... and have huge communities behind them...
    I'm all for Yet-Another-New-Language attempts, but please, make it open! Otherwise its just as bad as C#...
  • My main problem with REBOL is pretty stupid, but annoying enough to stop me using it - it's Linux font support sucks!

    They hadn't updated it to use the XRENDER/Xft framework for anti-aliased fonts when I last used it, and it completely ignores that fact that my X Server is running a 120dpi resolution, so all the GUI elements are nearly unreadable.

    It also seems to use the first font it comes across - seeing as I have a lot of odd special-effect fonts installed, the GUI ends up looking even stupider...
  • While Rebol isn't exactly the most desirable programming language, the Rebol desktop has a well designed UI that is seamless and not half as clunky as your typical web browser. We keep hearing about all these people trying to market services and internet applications, and we hear about all these open source application servers, but when you get down to it, it's just substituting one backend with another. They all boil down to the same front end with the same impoverished user interaction capabilities we've had for the past 7 years.

    If you can't help considering the Rebol Desktop's merits apart from Rebol's shortcomings as a "power-programmer" language, consider that a population of non-programmer internet users whose tastes and browsing activities are expanding might find a very simple scripting language that enables them to easily do a lot of useful stuff with web pages and e-mail quite useful.
  • All this angst! (Score:4, Interesting)

    by Junks Jerzey ( 54586 ) on Wednesday October 31, 2001 @11:07AM (#2502730)
    Bashing languages with the usual "But you can also do that in language X!" comments and general defensive put-downs is misguided. Of course you can do the same thing in any language; that's a fundamental principle of computer science. The reason we have a variety of languages is because some languages make things easier than others.

    In Perl, munging through text files is a snap. The syntax is succint, and regular expressions are supported at the language level. But that doesn't mean Perl is good for everything, though. Regular expressions don't scale up to what you'd need to write a full BNF parser in Perl. And, sure, you can hook to http and ftp libraries, but they aren't integrated into the language in the same way that the "file exists?" operator is.

    REBOL has several strengths. One is that its parsing features effectively *are* BNF, so you can write complex parsers for mini-languages with great ease, and without resorting to lex, yacc, and such. The other advantage is that having language-level support for internet protocols is very convenient. Sure, you can get at them through a Perl module, but if you argue that then you have to ask why regular expressions shouldn't be a separate module as well.

    All this blind bashing of languages is tiring. It's exactly like the kiddies who bash whatever game console they didn't get for Christmas.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...