http://www.rebol.com/cgi-bin/blog.r A few words from Carl Sassenrath, REBOL's inventor and leader of the X-Internet revolution. en-us Carl Sassenrath 2012 REBOL Language http://www.rebol.com/article/0509.html http://www.rebol.com/article/0509.html no-spam@rebol.com (Carl Sassenrath) Mon, 28 Mar 2011 02:45:02 -0700 For more than a decade I've loosely used the word simple... but, what is simple? I've avoided defining the word. Why? Because I thought the definition itself might be overly complex.<br /> <br /> Well, I know now. This experiment called REBOL has taught me quite a lot, and more recently in some of the work I've been doing, I've had the chance to contrast my ideas (yet again) to the quite different world of modern computing (pick Linux, Windows, XML). But, it goes beyond that, doesn't it? Couldn't I just as well say modern government, modern management, modern medicine, modern investing, or modern education?<br /> <br /> Simple is:<br /> <br /> #Clear abstraction: smart, well-drawn layers of "knowledge focus" that allow hiding of details.<br /> <br /> #Clean expression: meaningful, concise but not cryptic, representation and communication of concepts.<br /> <br /> If you're a computer scientist, engineer, or programmer, or even if your inclined in that general direction, then you already know the first requirement because it's stressed heavily these days. You hide the complexities of code in layers.<br /> <br /> For example, if in REBOL I write:<br /> <br /> image: load %photo.jpg<br /> <br /> This loads a JPEG image into memory and defines the word image to represent it. Now JPEG itself is a complex multi-layered image compression process. But we don't need to care about that. All we need to know is load. That's the power of abstraction.<br /> <br /> Unfortunately, the second requirement of simple is not stressed at all and therein lies the rub. In fact, I could claim that cleanliness of expression is completely ignored in most modern anything, whether that be a core OS subsystem or bill of law placed before congress.<br /> <br /> Let me make my point concrete with an example. In REBOL one can write:<br /> <br /> button "Click Here" green [browse the-website]<br /> <br /> Within a GUI dialect of REBOL (e.g. VID) this line defines a button to be shown in a window and specifies its color, text, and what happens when it's clicked.<br /> <br /> Now, compare that expression with what you might write in C++, Java, or most other "modern" languages. Really... if you know those languages, you immediately recognize my point here. And, please don't tell me that that problem is solved by XML, DHTLM, XHTML, XSL, XSD, XSLT, blah blah blah. It isn't, and if you listen to that little voice deep inside, you know that SGML-isms aren't the answer to most problems. Sure, you wish they were; but sorry, they aren't.<br /> <br /> In recent months I've had to dive deeply into very large piles of "modern code"... not only specialized programs (like ffmpeg and gstreamer) but major libraries of huge GNU code-bases that provide core functionality (Linux, pick any lib.) And, I'm not a newbie here. My history is well documented.<br /> <br /> Yet, when I browse these massive code-bases what I clearly see is a complete naivety of the engineers and/or programmers who wrote it. I'm not talking about their understanding of the knowledge domain, I'm talking about how they've mostly ignored tapping into the realm of expression as part of their solution.<br /> <br /> Some designers recognize deep down that something is wrong, and to help solve their problems, they often invent yet another language as a layer within their system. Modern Linux is completely littered with such languages, and it's a huge mess that spans everything from how you configure and build the kernel down to how you write little script jobs.<br /> <br /> The problem here is that there's no unity of language design, and in fact since most domain-smart programmers don't know much about language construction, you get something really quite ugly and nasty. Sure, people will force themselves to learn it, but only because they want the final solution... the circuit design, chip layout, kernel build, highway structure, nuclear reactor simulation, ...<br /> <br /> But something important is lost in that approach. Simplicity is sacrificed.<br /> <br /> Many designers strive for simplicity, but they don't truly understand the definition of the concept. They often point to an API that is well designed, but in actual usage it is by no means simple. When I look over such programs, all I see are the main expressions trying to break free of the code itself!<br /> <br /> In my opinion this problem can be solved. And yes, you know that as the designer of REBOL I offer its main principles as a good first draft of such a solution.<br /> <br /> For many engineers and programmers it is just a matter of waking up and understanding that they need to take a more unified view of the entire problem space, not just focus on solving a specific problem and perhaps providing good abstraction but horrible expression.<br /> <br /> Ok, so there you are. Simplicity defined. You no longer have any excuse. The world needs simplicity... and frankly in many more domains than just computing.<br /> <br /> I wasn't sure that I could ever write this. But now, with the experience of the last six months, it has become clear to me.<br /> http://www.rebol.com/article/0508.html http://www.rebol.com/article/0508.html no-spam@rebol.com (Carl Sassenrath) Mon, 21 Feb 2011 22:16:16 -0800 Do we have a library of common patterns for parse? If not, I think it would be a useful page to publish.<br /> <br /> For example, in R3 here's a parse line that removes all extra lines from a text file (that is, allow only one empty line between paragraphs.)<br /> <br /> parse text [some [thru lf [lf some remove lf | none]]]<br /> <br /> Here's an a paragraph "unwrap" example. It makes a sequence of adjacent lines into a single long line.<br /> <br /> parse doc [<br /> some [<br /> not lf thru lf<br /> some [s: not lf (change back s space) thru lf]<br /> |<br /> thru lf<br /> ]<br /> ]<br /> <br /> Perhaps you see a slightly better way to write that?<br /> <br /> These little parse expressions are really useful, and it'd be great to gather them together onto a single web page so that we don't have to re-invent them each time.<br /> <br /> Here's a page where you can post them: Common Parse Patterns. http://www.rebol.com/article/0507.html http://www.rebol.com/article/0507.html no-spam@rebol.com (Carl Sassenrath) Sat, 12 Feb 2011 17:51:07 -0800 Up until recently REBOL files used the ".r" suffix and it wasn't really a problem. However, that suffix is used for other purposes, such as resource files on MacOS/OSX and statistics scripts in the R language. And, I've heard of a few others, like rendering scripts at Dreamworks.<br /> <br /> For R3 I thought we'd move to .reb, but most users seem to already be using .r3 for scripts. Of course the advantage is that .r3 clearly distinguishes the script for R3.<br /> <br /> It's been suggested that we use:<br /> <br /> :.r2 - for REBOL 2 files<br /> <br /> :.r3 - for REBOL 3 files<br /> <br /> :.r - for files that run on both<br /> <br /> That seems close, but it does not solve the basic .r conflict with other systems. Perhaps it would be better to use .reb instead.<br /> <br /> A good example of the problem can be seen if you edit a .r script on recent Linux distributions. Most editors do not associate .r with REBOL, and you end up with the wrong syntax coloring. The more unique suffixes of .r2, .r3, and .reb would avoid that problem.<br /> <br /> Let me know your thoughts. It's a good time to decide.<br /> http://www.rebol.com/article/0506.html http://www.rebol.com/article/0506.html no-spam@rebol.com (Carl Sassenrath) Sun, 16 Jan 2011 12:18:24 -0800 Some of you know that there's a handy script on the REBOL website called speed.r. I use it quite often to get a general idea of the performance of various systems I work on.<br /> <br /> For example, I'm writing this article from cheap Linux box that's not that fast. I can find out how well it runs REBOL with:<br /> <br /> >> do http://www.rebol.com/speed.r<br /> connecting to: www.rebol.com<br /> Script: "REBOL Quick and Dirty Speed Test" (none)<br /> Running...<br /> ........................................................................<br /> <br /> Console: 0:00:00.319016 - 1586 KC/S<br /> Processor: 0:00:00.392543 - 2201 RHz (REBOL-Hertz)<br /> Memory: 0:00:02.547215 - 18 MB/S<br /> Disk/File: 0:00:00.762555 - 40 MB/S<br /> <br /> BTW, an RHz ~= MHz. The scale difference in intentional. You know, "planning for future expansion."<br /> <br /> So... this speed check isn't an advanced benchmark, but I've found it to be quite useful. Last summer I was working with someone on firing up a hosted virtual server. When I ran the speed.r test, I discovered that the disk/file test was only about 8 MB/S! (I've got 12 year-old 400 MHz PC's that run that fast.)<br /> <br /> I contacted the ISP and after quite a lot of arm twisting I got them to measure the disk speed (using an independent method.) They were quite surprised how bad it was! We moved the server twice before landing on one that ran about 10 times faster... and, for the same price.<br /> <br /> After that experience I decided to write speed? and make the speed test resident to all future R2 and R3 releases.<br /> <br /> >> ? speed?<br /> USAGE:<br /> SPEED? /no-io /times <br /> <br /> DESCRIPTION:<br /> Returns approximate speed benchmarks [eval cpu memory file-io].<br /> SPEED? is a function value.<br /> <br /> REFINEMENTS:<br /> /no-io -- Skip the I/O test<br /> /times -- Show time for each test<br /> <br /> The /no-io option is for when you're running from a mem-card (SD flash) or other device that you don't want to wear out.<br /> <br /> The result is a block of numbers that you can easily format:<br /> <br /> b: speed?<br /> print [<br /> "evaluation:" b/1 lf<br /> "cpu:" b/2 lf<br /> "memory:" b/3 lf<br /> "file:" b/4<br /> ]<br /> <br /> If you want to peek at the source (and it's pretty small), type:<br /> <br /> source speed?<br /> <br /> Note that it's not exactly the same as speed.r. I wanted to measure the interpreter's evaluation speed and CPU speed more independently. My goal was for those first two numbers to fall close to the MHz for your system, given adequate CPU caching with good DDR clocking (and of course, minimal task loading.)<br /> <br /> Also note that this is just a preliminary version. If you have some improvements, let me know. But, also keep in mind, this is just a simple built-in test not used by most scripts, so it needs to stay quite small.<br /> http://www.rebol.com/article/0505.html http://www.rebol.com/article/0505.html no-spam@rebol.com (Carl Sassenrath) Sun, 16 Jan 2011 11:37:20 -0800 I've been incredibly busy... and it took a week to get the list of changes updated on this website. The list is done now, but let me give you a quick overview of some features.<br /> <br /> First, if you use REBOL as a server or for CGI-scripting, notice there's only one task running now:<br /> <br /> rebol@linux:~$ rebol &<br /> rebol@ub10:~$ ps<br /> PID TTY TIME CMD<br /> 1474 pts/0 00:00:00 bash<br /> 1703 pts/0 00:00:00 rebol<br /> 1704 pts/0 00:00:00 ps<br /> <br /> The DNS subtask is delayed now until you use DNS (which many scripts may not need.) This change makes your CGI scripts launch faster and also makes it possible to setuid the main process before the subtask forks.<br /> <br /> There are also new functions for easier access to the OS environment. Notice that the secure level defaults to asking the user for permission:<br /> <br /> >> set-env "prog-home" "/tmp"<br /> REBOL - Security Check:<br /> Script requests permission to access OS environment: prog-home<br /> Yes, allow all, no, or quit? (Y/A/N/Q) A<br /> >> get-env "prog-home"<br /> == "/tmp"<br /> <br /> Of course you can allow such operations with:<br /> <br /> secure [envr allow]<br /> <br /> or by running with the -s option.<br /> <br /> Notice also, the list-env function:<br /> <br /> >> list-env<br /> == [<br /> "ORBIT_SOCKETDIR" "/tmp/orbit-rebol" <br /> "SSH_AGENT_PID" "1327" <br /> "TERM" "xterm" <br /> "SHELL" "/bin/bash" <br /> "XDG_SE...<br /> <br /> You can also access special OS related settings on Posix systems. For example, if you're running a server as root to obtain a listen port on 80, it's wise to setuid the process to some other account:<br /> <br /> access-os/set 'uid 1001<br /> <br /> Or, if you need your process id for something like building a lock file, you can get it with:<br /> <br /> pid: access-os 'pid<br /> save join %/tmp/lock- pid pid<br /> <br /> Brian Hawley also ported over a number of useful R3 functions. The full list is here.<br /> <br /> For example last? mezzanine is useful:<br /> <br /> >> list: [a b] <br /> == [a b]<br /> >> last? list<br /> == false<br /> >> remove list<br /> == [b]<br /> >> last? list<br /> == true<br /> <br /> The various R3 Unix-like shell functions come in handy when you're working from the REBOL console:<br /> <br /> >> cd %/usr/local<br /> == %/usr/local/<br /> >> ls<br /> bin/ etc/ games/ include/ lib/ man/ sbin/ <br /> share/ src/ <br /> <br /> I use dt (delta-time) a lot for measuring performance:<br /> <br /> >> dt [loop 1000000 [next "a"]]<br /> == 0:00:00.246217<br /> <br /> Speaking of which, I've added a new speed? function, but that's the subject for a separate blog. It is preliminary, so don't yet depend on it.<br /> http://www.rebol.com/article/0504.html http://www.rebol.com/article/0504.html no-spam@rebol.com (Carl Sassenrath) Thu, 6 Jan 2011 14:21:37 -0800 I've got some information about the status of REBOL.net.<br /> <br /> I talked with Richard today (who runs the REBOL.net servers) in Canada. The story is that they have plenty of Internet pipe bandwidth, but the "pipes froze".<br /> <br /> All joking aside, an upgrade at the facility shifted the IP addresses before anyone had a chance to reconfigure the servers. The plan now is to make the fix tomorrow, in-person.<br /> <br /> And, while I'm on the topic, there's the old issue of the REBOL email list. Can we retire that old server... which has been limping along for many years, and the list has not been very active. The user community has moved most messaging to other methods, such as AltME, etc.<br /> <br /> So, what's the general opinion of users regarding the email list? Time to retire it?<br /> http://www.rebol.com/article/0503.html http://www.rebol.com/article/0503.html no-spam@rebol.com (Carl Sassenrath) Tue, 4 Jan 2011 20:44:51 -0800 A user sent us feedback to note that on Fedora 13, you may need to install a few fonts to get REBOL/View 2.7.* working properly.<br /> <br /> These fonts were suggested:<br /> <br /> xorg-x11-fonts-misc-7.2-9.fc12<br /> xorg-x11-fonts-100dpi-7.2-9.fc12<br /> xorg-x11-fonts-75dpi-7.2-9.fc12<br /> <br /> This problem may exist on other versions of Linux as well, because REBOL 2 uses bitmapped fonts.<br /> <br /> This should not be a problem on REBOL 3.0, which can render other types of fonts.<br /> http://www.rebol.com/article/0502.html http://www.rebol.com/article/0502.html no-spam@rebol.com (Carl Sassenrath) Sat, 1 Jan 2011 17:07:33 -0800 Happy new year everyone. Wow, 2011. I probably should post some reflections of the past year or a plan of the new year, but instead, I've decided to go ahead and finish the release of 2.7.8... because it has various fixes and additions that are useful to everyone.<br /> <br /> While it is always possible to do more for a release, if you're not careful, you get stuck in a loop: there's always one more thing to do. And when you do that, there's always one more. It never ends, and you never release it. So rather than do that, I've decided to move ahead with the release.<br /> <br /> Many thanks to Brian Hawley for his additions and improvements to the mezzanine functions -- many of which provide R3-like features. Please be sure to note the R3-style funct function (default local variables), and you may never use func again (default global variables.)<br /> <br /> Also, if there's a bug you really wanted fixed, and it's not been fixed, sorry about that. Somehow the importance of your bug got lost. Note that if all you did was post it to an AltME world or other chat area, I don't have time to scan all those. Instead post it to the bug DB or send a web feedback. Hopefully we can get it into the next go-around.<br /> <br /> In addition, I should note that I coordinated with DocKimbel to make sure that REBOL/Core 2.7.8 is capable of running Cheyenne directly, even if you need to setuid out of root for security reasons (on non-Win32 systems.) http://www.rebol.com/article/0501.html http://www.rebol.com/article/0501.html no-spam@rebol.com (Carl Sassenrath) Sun, 19 Dec 2010 21:18:21 -0800 On Linux there's a lightweight "IDE" called Geany. I've used it just a bit so far -- nothing serious. However, it seems like it might be a good choice for editing REBOL scripts and projects.<br /> <br /> So, the question is... has anyone added support yet for REBOL in Geany, such as syntax coloring and evaluating a script from a key?