Is REBOL all it's cracked up to be?
Hi
I have been searching for a tool that will allow me to code quickly and elegantly to create useable applications. My time is in short supply and I want to avoid going down a dead-end as much as possible.
About a week ago I discovered REBOL and I am about to embark on the road to learning REBOL.
Before I do that, however, I would like to confirm that REBOL will meet most of my expectations. I have done some preliminary reading about REBOL and it has left me with a nagging suspicion that it might not be all it’s cracked up to be.
For reference, I have been developing software professionally for the last 13 years. I started out with Turbo Pascal, moved into VB for Applications, then Delphi through to Visual C#.NET and Visual Basic.NET.
I have avoid web development for as long as possible as the technologies have never felt cohesive or mature to me. Every website I’ve worked on has been a hodge-podge of frameworks which you constantly fight with to get them to play nicely together. Application development is not much better, with DI frameworks and IoC containers and ORM mappers and UI frameworks making things way more complicated than my gut tells me they need to be.
So I’ve been looking for something different for a while now. I’ve played with Smalltalk (Pharo) but my experience with that was not great. It seemed like an overblown way to develop software, even if some of the concepts were interesting.
Enter REBOL.
It seems to address most of my issues with modern software development. Or does it?
I would like to ask the following:
1. I see that REBOL solutions can be packaged up as Windows .exe files using a tool. This seems like a kludge to get a scripting language to pretend it is an executable file. Is this an actively supported method for releasing REBOL applications?
2. REBOL promises to allow me to build websites easily. Coming only from ASP.NET in terms of web development experience, have other users made a similar switch and found it easy, and indeed, preferable to the ASP.NET approach?
3. Most of the UI examples I’ve come across have a distinct Windows 95 feel to their controls. Is this a short falling of the platform or have I missed the fancier GUI examples? The UI has to become simpler and more intuitive as the potential reach of your application broadens. Part of that is glossier controls with bells and whistles. It’s what the modern customer expects!
4. I see that REBOL has its own binary file format for saving data, and there are one or more database-like solutions for storing data. Will REBOL be able to handle the quantities of data that a site like codeproject or stackoverflow would need to store?
Those are the main concerns that I have with my initial investigation at this stage. I am reading through tutorials and the language is most intriguing so far.
Thanks for your time.
Rupert
posted by: Rupert Smith 8-Apr-2014/18:44:59-7:00
As a beginner myself, I can't help you very much. I can offer some comments on point number 4.
I am not aware of any binary file format that is specific to REBOL. As far as I know myself, the lack of its own file format (like COBOL ISAM, as an example) is a deficiency of REBOL. Usually, to work with files, REBOL programs read them all into memory, work on them, and then write them all back to disk.
However, REBOL CAN work with databases through an ODBC connection. I have used that myself, only a little, and it does seem to work. One builds up an SQL command in memory and then passes it to the ODBC connection. There is documentation on the REBOL web site that explains. The result of that command is one or more blocks of data, each block being a row of the set of records that came out of the SQL query. I have not explored very heavily the updating of databases in this manner, but I have no reason to believe it would not work, since one is just sending an SQL command and the database software is doing the work. If you were going to work with Oracle or SQL Server, you would have all that database management power at your service, more than you would be likely to need.
As for other points, if you look around the REBOL web site you probably will run into an explanation from Carl that one of the original design goals of REBOL was for "programming in the small," which means, I would imagine, smaller applications. I am not able to say of my own knowledge how much big stuff there is out there in REBOL.
That's all I can offer without getting outside of areas where I know something from my personal experience.
I suspect you will get some comments from the guy who runs this forum. He has written some heavily-used business applications in REBOL. He has some experience in using the built-in REBOL GUI to make things with the more "modern" interface.
posted by: Steven White 9-Apr-2014/10:15:14-7:00
By the way, I do have a thought on point number 2.
I have not used ASP, but I get the impression is is something like PHP, where you embed ASP code in a web page. REBOL has a really slick function called build-markup. What you do with it is, write an html page, and then, where needed, embed some REBOL code in <% and %> delimiters. (that is the less-than symbol and a percent, and a percent and greater-than symbol if they don't come though this posting) Then you pass that html page through the build-markup function and it locates that embedded REBOL code and executes it, and replaces that REBOL code with the results of executing it.
That build-markup function does not have to be used only for modifying html. An html page is just a big string of text. You also could use build-markup for making a skeleton SQL query and then tailor that query with the results of some REBOL code.
Regarding point 1, I don't know if that "encapsulating" feature is supported beyond REBOL 2. I have used it with REBOL 2 up through Windows 7. I don't know of my own knowledge if it works for REBOL 3 or for Windows 8. I had to fuss a bit with Windows 7, but I did get it to work.
HOWEVER, I do have some thoughts on deploying a REBOL application, since I have written programs in other languages and deployed them. I do this for my employer. In-house application deployment is a bit different than writing something for a wider audience and selling it. What we do is use the free (as in beer) version of REBOL 2 and put it on a network drive. Then, an application consists of a REBOL script and a Windows batch file. The batch file runs the REBOL interpreter from the network drive, with a switch to prevent installation on the local computer, and another switch to point to the script. In other words, deploying an application is just giving someone the script and the batch file. If the script is general enough, the script and batch file can be stored on a network drive also and any user can be given a link to the batch file by another launcher window we use (ZENworks from Novell). In other words again, deployment is really trivial because of the nature of REBOL, namely, that it is just one executable file that contains everything you need to run programs.
As an interesting variation of that, here is another way to deploy an application, if you want it to be sort of "open source." Because the REBOL interpreter is so small, and you are allowed to copy it, you can package up your application as your scripts, some appropriate batch files, and the REBOL interpreter itself, all in one folder with sub-folders. Then, "installing" that application means to copy the folder to anywhere you want it, and running a starting batch file in that folder. In other words, there really is NO installation. You "install" the application by copying the folder to any location on your computer, and you "uninstall" it by deleting the folder. I have done that a couple times and it is really nice. This can be done because the interpreter is one file, small, and complete. And you never will have any version mismatch problems, because your application includes the interpreter.
The above deployment schemes do depend on some assumption that are valid for my personal circumstances as an in-house programmer with a limited "customer base." I don't care if people see the code, I can trust them not to mess up the code, we have a well-defined computer network so that I can make certain configuration assumptions. But within that environment, REBOL is very nice.
posted by: Steven White 9-Apr-2014/12:25:16-7:00
Hi Rupert,
1) If you need to distribute executables which don't expose the source to users, the commercial SDK is the official solution. Be aware that even in the SDK, Rebol is interpreted, so the SDK still simply provides a packaging method - the results are just securely encrypted and wrapped into a platform specific binary executable. For the sort of work that most users do with Rebol, I think script files and things like SFX .exe packages seem to be the most common delivery mechanisms. Although I own the SDK, I typically use bare scripts, or use iexpress to package exe's for Windows users who don't want to install Rebol. There's no pretending about it, Rebol isn't a compiler :)
2) Developing with Rebol on a web server shares all the same advantages of developing desktop apps with Rebol. If you're planning on using Rebol elsewhere, then it's simple to extend your skills to the web server. We also have Cheyenne with RSP (inline Rebol, like PHP). So you can use one uniform language for everything, like everyone's trying to do with Javascript right now. But you'll still have to output HTML, CSS, Javascript for the browser. If you're *only* planning on doing web develoment, especially if you're working with big data, then it may pay to stick with some mainstream stack, including maybe Java, PHP, etc., which supports all the big messy mainstream tools, libraries, etc. If we can get the Javascript port done, then it would make sense to do web client and server development entirely in Rebol (I think that port should be the main priority right now).
3) Rebol won't give you native look and feel out of the box. You can certainly create a convincing skin, like Java does with Swing, but no one has done that in a long time (Doc did a win98 skin many years ago). You can get an inch further by default with RebGUI, but it's still plain and utilitarian. More likely the better approach is to think about building apps the way web developers build web pages, with good graphic design and sensible, tasteful layout, not necessarily tied to platform specific UI standards.
4) As Steve said, out of the box, Rebol was meant for "programming in the small". It's similarly performant to tools like Python, Ruby, and other interpreted languages. You could perhaps push Doc's postgre binding to do some heavy data lifting, and Maxim is working on a database system that will handle massive volumes of data (C based, and integrated with Rebol), but building a site which handles a load as heavy as Stackoverflow is an engineering challenge which would likely result in 10's of thousands of man hours over a period of years, and you'd certainly need to build a strong infrastructure, all the way down to the hardware. Some companies (like Facebook) have pushed even PHP to handle some ridiculously heavy loads, and I'm sure if the desire/money was there, Rebol could be engineered to handle some big work too, but that's not it's original intent. It's goal was to be productive on the small scale, and in that domain, nothing else holds a candle to it.
posted by: Nick 9-Apr-2014/22:19-7:00
Just to be clear, Stackoverflow currently receives an *average* of approximately 600000 page views per hour (averaged for every single hour of the month). No matter what language tools you use, there's some extended engineering which goes into supporting that load.
posted by: Nick 9-Apr-2014/22:39:42-7:00
Usually, to work with files, REBOL programs read them all into memory, work on them, and then write them all back to disk. --> True, but also can work with large files, http://www.rebol.com/docs/core23/rebolcore-14.html I've not read anything about Rebol working in a distributed system - if that might be an idea for processing large data in less time?
posted by: Matt K.L. 10-Apr-2014/2:07:53-7:00
I've have a little unpublished article about how to write Rebol code which handles multiple simultaneously connected clients, as well as multiple servers, all operating on a single series in parallel. I've implemented some really useful server systems with just a few dozen lines of code. That helps me keep everything in pure Rebol, avoid needing third party tools (avoid third party version, install, and support issues), and create any unique data management feature I need, from scratch, all very simply. It's really not that complicated, once you get the basic structure of how to send data back and forth between the clients and servers. I'll brush it up and publish as soon as I get a chance.
posted by: Nick 10-Apr-2014/9:12:55-7:00
Matt, thank you for that link. I have seen that chapter on ports, but I have a bad mental habit of ignoring things I don't understand. To me, the term "port" meant something different, something I had no use for at the time, so I ignored it.
Nick, that article would be welcome to me at least. I have thought that there are some "networky" things about REBOL that I don't understand. I have thought that it could be useful to write some primitive file "server" that passes data to a "client" in a REBOL-code format, so that the client could use the "load" function on the passed data; the "code is data and data is code" concept in action. It seems like that should work, but I don't quite know how to get started.
posted by: Steven White 10-Apr-2014/9:53:57-7:00
Might as well point out the downsides, to get a more balanced view:
The community is small, about 2-3 dozen active developers, so there are many things, which might be norm in other languages, which simply don't exist in REBOL. For example, there is little proxy support for networking and most GUI systems (there are quite a few now) are incomplete and/or a bit ugly and old-fashioned.
REBOL 2 is the most complete version, but it is also the version with the oldest tool-set, a dated GUI appearance, in many cases the slowest performance and with known but unfixable bugs. It's also closed source and officially no longer in development.
Newer versions are less complete, and still under development, but these are open source, and offer a good chance to get things right.
The community is a bunch of talented and experienced people, but the workload is huge with the queue of things already needed.
Cross-platform features: REBOL was originally touted to work on 40 different platforms. Today, this has basically been reduced to x86 Windows and low-to-mid-level support of Linux and MacOSX, again, because of the required workforce to support more OSes.
Still, it is possible to build fully commercial enterprise apps with it, and I've been working full-time on one (http://nlpp.ch) for the past 4 years.
Generally, REBOL is a really good idea that this community feels must survive, so REBOL 3 was open sourced and Red was created as a different implementation.
posted by: Henrik 12-Apr-2014/15:17:23-7:00
Hi All
Firstly let me say a big thank you to everyone that has taken the time to type up a reply to my questions. The fact that quite a few people replied to what is, essentially, a non-technical question is a good sign of an active community.
@Steven: Thanks for those pointers on how you’ve achieved deployment of REBOL applications - Some good ideas there. To be honest, I am much more likely to create web applications with REBOL rather than Desktop applications, so the desktop considerations have evaporated.
Any desktop apps I create are likely to be for my own use and thus will not require much in the way of fancy GUIs – functional GUIs will suffice.
@Rick: Thanks for further clarifying my questions, I now have a much clearer view of what can/cannot be achieved with REBOL.
Q: As I mentioned above, my main focus would be on creating web applications with REBOL. To this end, I wonder if there is much difference between learning PHP or REBOL, since they appear to be comparable as far as web development is concerned?
I see that you have made, what appears to be the source code for this website, available as a link on this site. I plan to peruse it and see how you’ve achieved the functionality. As has been said elsewhere, 90% of line-of-business applications are about capturing data and retrieving it, essentially CRUD behind an interface.
The websites I have in mind would probably average 2 or 3 page hits per hour, so I certainly don’t need the kind of infrastructure that stackoverflow needs to operate! :-)
Q: Might I enquire as to how you are saving these posts? Are you using a database or files?
The current thinking in the .NET community is that you need a domain (data) model and a business logic model and then you need to map between these two objects. You also need to abstract your data, Business Logic and Interface logic, adding needless layers of complexity to what should simply be forms that either save or show data.
Q: Will REBOL simply the saving and retrieving of data over a platform like PHP, for example?
@Matt & @Henrik: Thanks for your input too. I will refer to the docs a lot in the coming weeks I’m sure Matt. And Henrik, that app you worked on looks to be more advanced than anything I plan to create, so it’s good to know that REBOL ticks that box for me.
posted by: Rupert Smith 13-Apr-2014/20:45:37-7:00
Rupert,
As Henrik mentioned, the Rebol community is small, so you won't see support for libraries. PHP is the opposite, and there's ubiquitous support for it everywhere. If your focus is mostly web development, PHP, Java, Python, Ruby, and any popular frameworks/libraries are hard to get away from. When I wanted OAuth support last year, it took a while and some personal work with ChrisRG to get what I needed. With PHP and other popular tools, support for things like that is seamless. That's a really important consideration.
Last month this little rebolforum script handled 126894 page views, which is approximately 3 pages per minute averaged over ever single minute in the month, so you should be safe. (it's using a really simple flat file system, with no other dependencies but the Rebol interpreter on the Web server)
posted by: Nick 15-Apr-2014/1:15:31-7:00
Nick
Thanks again for taking the time to answer my questions. You have helped solidy some vague thoughts in my head.
What appeals to me is that the scipt you use for this forum is small compared to the equivalent code I would need to write to get something like this working in ASP.NET, the only web platform I currenly know.
It's that kind of "unnecessary" overhead that I am hoping to get away from and I think that I will give REBOL a decent trial before deciding whether it suits my needs or not.
I have this gut feeling that contemporary coding is unecessarily complicated - perhaps this is more true of the Microsoft stack than other vendors.
I expect to use this forum a fair bit over the coming months as I give REBOL a twirl - thanks for providiing this resource.
Cheers.
posted by: Rupert Smith 15-Apr-2014/6:36:48-7:00
Rebol will certainly clarify that other tools and languages are unnecessarily complicated in many ways. It is truly a shame that Rebol's marketing history unraveled as it did, and that its community dwindled during an unfortunate period several few yours ago, because there are many valuable lessons to learn from its design and ethos.
posted by: Nick 15-Apr-2014/8:18:47-7:00
Hi Nick
Sorry, one last question (or two) - which web server are you using to host this forum and would you recommend Cheyenne over Apache?
Thanks
Rupert
posted by: Rupert Smith 15-Apr-2014/23:57:44-7:00
I use Lunarpages shared hosting. I've had clients who use Hostgator and Hostmonster (plus a few others over the years which I can't recall). So, in those cases, I've always been stuck with CGI on Apache, and it's been fine for my needs. In one of the tutorials, I covered a bit about the differences between using CGI on Cheyenne and Apache (just a few important details). If you're using Cheyenne you can do a lot more, such as using inline Rebol code (similar to the way PHP is included in HTML code), and web sockets:
http://web.syllable.org/news/2010-01-02-22-16-WebSockets-for-Cheyenne-web-server.html
I haven't had the pleasure of being in an environment in which a dedicated web server was available to run Cheyenne. In most cases my web development work is limited to providing forms which allow users to access some shared data on a server, typically with some computations (such as reports on lists of data).
posted by: Nick 16-Apr-2014/8:13:29-7:00
Rupert,
I'm putting together a little tutorial about using Rebol on the server with Webix on the front end. I'll put the link on the forum when it's done (When a javascript port of R3-GUI gets done, we won't need anything like Webix).
posted by: Nick 17-Apr-2014/12:06:13-7:00
|