Comments on: Fight Software Complexity Pollution
We run the Cheyenne web server on our cloud servers. It's small, fast, has many great features, and integrates well with REBOL. The source code is about 164 KB, and the executable is about 350 KB. That's an entire web server with many nice capabilities!
When we run on cloud servers we install a very small Linux core and no other extra services. On top of that we run various REBOL processes, including Cheyenne, that are microscopic and do everything we need. As a result, our IT maintenance is trivial.
However, to keep Cheyenne updated, we need Subversion... and to install it using apt-get, we see:
The following extra packages will be installed:
libapr1 libaprutil1 libexpat1 libneon27 libpq5 libsvn1 libxml2
Suggested packages:
db4.6-util patch subversion-tools
Recommended packages:
xml-core
The package is nearly 50 times larger than the software we're trying to update!
Sorry, not going to do it. I know I'm going to hear comments from you: "it's no problem, just do it, works great, it's how it's done nowadays, the standard of practice, everyone does it, you're old fashioned, ignore the overhead, memory is cheap, blah blah blah."
Sorry: no. No!
This is software complexity pollution. You need one little thing, but then it requires another, and another, and before long you're installing (and maintaining) a half dozen different subsystems. It's a complexity snowball.
Well, I'm rebelling against it. And, this is not just a Linux problem, it's a universal attitude in software design. It's the mindless world of complex modern software. I gave my iPhone to my son after I discovered that every update to it was more than 450 MB. What kind of garbage is that, and from Apple?
Anyway, I'll find some other way to keep the Cheyenne server updated.
So... just say "no" to software complexity. Do it every chance you get. Do not be swayed by mindless "experts" who tell you that it's the "standard of practice". You have a choice. Keep it simple.
64 Comments Comments:
Tcheko
11-Nov-2010 11:32:14 |
Size matters. You are right about it.
| Henrik
11-Nov-2010 11:38:20 |
I'm working a bit with Git now, and although it appears simple at first, it consists of a lot of nuts and bolts to make it run.
I would like to see a REBOL based clone of Git in a few kilobytes, which has greater emphasis on size than speed (because we don't have that many big source files). I think it's possible to do and it would run on many more platforms than Git. | PG
11-Nov-2010 12:57:36 |
I can only recommend cpdup by Matt Dillon (Dragonfly BSD) - neat, simple tool to deploy files | Maxim Olivier-Adlhoch
11-Nov-2010 13:14:47 |
Carl, complexity IMHO arises from how computer science is being taught nowadays.
We've lost the sense that programing is also an art. And that like for all art you need to understand and even be able create your own tools, not just use them. Ironically, I did a few semesters in visual arts (at university) recently, and that reasoning has somewhat found its way into arts to!
Teachers all had their own cheap easy to use and purpose-built custom tools ex: a stick with a needle, a crude cardboard holding handle which allows you to cut and replace the cardboard (for painting & sculpture), etc.
but then, they ask their students to buy tools which do the same, cost a lot of money and limit creativity. ironic.
People don't realize that when you create tools, you will inevitably innovate, you will WANT things to remain simple so will indirectly find new solutions which create new opportunities.
People also forget how easy it sometimes is to make tools for a specific purpose. You don't have to solve the general case. | onetom
11-Nov-2010 15:22:52 |
I COULD say complexity NO a lot more times IF you would open REBOL up even more.
We should see REBOL on Android!
I just bought a Ben nano-note $100 computer from https://sharism.cc/
It would be great for running REBOL on it, but it has a MIPS processor (and just an OpenWRT Linux on top of it).
I would run Cheyenne and educational web apps and collaboration platforms on routers with DD-WRT firmware. Those are MIPS again.
I want to create a minimalistic uClibc based distribution, so a full, programmable, command line Linux distro could fit in 10MBs. Can't do it because of glibc dependencies. | onetom
11-Nov-2010 15:37:09 |
On SVN vs GIT:
If SVN is bloatware to you then you shouldn't stop at GIT either.
If u really want to follow the KISS principle, try DARCS.
Even the static exe is "just" 4M and 1 file & 12M only if extracted!
http://teratorn.org/code/darcs-2.5.0-linux-i386-ghc6.12.3-CURL-static.bin.bz2
Btw, it's a lot simpler to use compared to git...
They also have a github-like public repo site at http://patchtag.com/ | CVM
11-Nov-2010 15:39:56 |
You are on an island of sanity in the sea of software insanity. Please stay out of the water.
| Me
11-Nov-2010 17:34:43 |
subversion is to keep the programmers updated, not the server. thats why its called version control. diff etc. | Ken C.
11-Nov-2010 21:40:36 |
You might want to take a look at Fossil:
http://fossil-scm.org | Narkado
12-Nov-2010 2:23:55 |
onetom++, revolution against software complexity needs an open Rebol toolkit. | Luis.
12-Nov-2010 3:24:07 |
There is another choice: Keep it working...
If it's needed now why not use it and then start on the process of replacing it when more resources are available?
Personally, I'd rather go for the sting of replacing it now, though that decision is not mine to take.
What of a different approach? Why not implement an updating framework/module that could wrap around any app?
It's not the same as version control, with all its bells and whistles, although it would be a small step towards avoiding the bloat.
Cheers,
Luis.
| Steven White
12-Nov-2010 11:36:06 |
Well, you know, "complexity" has several facets (or are those "faces"?).
I saw this posting, and, since we are looking for a way to deploy in-house applications, I thought I would try Cheyenne. I downloaded it, I installed it, I ran it, and...it didn't work--no connection. So I tried reading the documentation, but there is not much, so I beat my head on it a while, and then tried it on a totally different computer. I downloaded the "view" package, installed it, ran it, and it worked.
Then I tried to get some cgi scripts running. I wasn't sure where I was supposed to put them, and there was no documentation, so I looked in the configuration file, made a guess that they were just in the document root, and got a simple test running. Then I tried an html form and a script to display the contents of the form. The form and script work on a computer with Apache, but the same script (unless I made a copying error) on Cheyenne does not work--it acts as if it is not getting any data from the form.
So to the point, I have installed Apache by downloading, running an installation file, changing one line in a configuration file, and putting some scripts in a cgi-bin directory, and the setup worked and has continued to work and the administration has been non-existent. Now I install Cheyenne in the name of "simplicity" and I can't get it to work.
Non-complexity is not just smallness. It is completeness, documentation, intelligent default configurations, documentation, skillful hiding of complexity. What are the effects of "complexity"? Frustration, puzzlement, lack of success in getting something to work. If it is caused by true complexity, or simplicity combined with no documentation, does it matter which?
(This is not a request for help. I probably will stick with Apache unless we are forced by the I-T guys to use IIS. It is just a complaint that no matter how "simple" things are, they never seem to "just work.")
| W^L+
12-Nov-2010 12:21:55 |
(at)"Me":
It is pretty standard these days to use your version control system to deploy your changes to a web site. However, it is my impression that most of the site is static files. SCP or SFTP could probably be used to copy static content from a development environment to its deployed location without all the hassle of current version control systems.
It is probably time for one or more Rebol gurus to create a quick and simple version control system, something that is specific to the needs of RT and the Rebol community. Git was created to meet the needs of the Linux kernel developers (probably not what you need), so why not talk with the gurus to give them some ideas of what is needed and how to proceed? | Kaj
12-Nov-2010 13:45:57 |
Ken, thanks, Fossil looks awfully good. Carl, you should have a serious look at it. | Karl
12-Nov-2010 14:00:44 |
Steven, you make an excellent point! Transparency trumps smallness when it comes to grappling with complexity. I spent countless hours trying to understand the REBOL parse dialect. When I eventually implemented my own version of it the behavior was, of course, obvious. This is why I refuse to use closed-source software for any job that matters and will happily install bloated open-source tools (such as Git for version control).
| Karl
12-Nov-2010 15:00:34 |
P.S. Above I called Git 'bloated' (got carried away with Carl's rhetoric), but to be fair, the 64-bit binary is just over 1MB. On Fedora it is packaged with each tool as its own file (142 commands), but most of these are hard links to the main binary. The RPM itself is 12MB which includes documentation in man, text, and HTML formats. | Laurent
12-Nov-2010 18:35:58 |
Carl, you should release this very small linux core with various rebol services and Cheyenne as a Linux distribution. Success garanteed. It would help Rebol beeing known. | Kaj
13-Nov-2010 2:16:41 |
That's exactly what Syllable Server is. :-)
http://web.syllable.org/Linux/index.html | DocKimbel
13-Nov-2010 9:27:39 |
(at)Steven
Non-complexity is not just smallness. It is completeness, documentation, intelligent default configurations, documentation, skillful hiding of complexity.
Well, that's why the current version is labelled "0.9" and not "1.0", this means "not ready for prime-time". Don't expect a non-completed product to be complete. Full documentation and a web admin panel are for 1.0 (you seem to have ignored the Roadmap on Cheyenne's web site).
Also, you could have reported the issues you've stumbled upon in Cheyenne channel on Altme's REBOL3 world (or through the REBOL mailing-list), not only you would have received fast help and advices, but you would have gave me a chance to fix or improve Cheyenne if required. You could have also learned then, that good REBOL CGI scripts use READ-CGI function to get POST data (from forms for example) and not READ-IO, which would have made your CGI scripts compatible with Cheyenne... | Greg Schofield
13-Nov-2010 22:19:07 |
onetom
We should see REBOL on Android!
Yes please!
Carl keep up the good fight. | Steven White
14-Nov-2010 18:32 |
DocKimbel,
My apologies if I seemed disrespectful of your efforts. A complex software product that is installed just by copying it to disk is an ideal I myself only aspire to. My "complaints" were meant to be a bit more generic, since I have had them about many products I have encountered, including REBOL itself (especially VID, and I know I am not alone in that).
I did not realize that the mailing list might be an appropriate place for a question. I thought the mailing list was for REBOL itself, and AltMe was more of a chat room. When I get to the office, I will see if I can isolate the "problem" I encountered into a small test script and put it on the mailing list. I suspect I am reading the CGI input in the correct way, because the only way I know to do it is the way shown in an example from the REBOL documentation. On the other hand, maybe my own code is too complicated.
| Kaj
15-Nov-2010 4:02:22 |
If your CGI script is REBOL, Cheyenne runs it as Fast CGI inside its own processes, instead of as regular (slow) CGI. If your HTML form uses the POST method, the interface for the POST data is then different. It should not be read from the standard input stream, because Cheyenne has already done that. It's in the REBOL word INPUT, which is predefined by Cheyenne. | DocKimbel
15-Nov-2010 6:56:24 |
(at)Steven
Thanks for reporting your issues by whatever mean you find most suited to you.
FYI, as Kaj explained, REBOL CGI scripts benefit from an optimized default treatment in Cheyenne which gives them FastCGI performances, but at the price of a compatibility issue: READ-IO is not supported and scripts should rely on READ-CGI and INPUT functions instead.
Beyond the improved performances that such interface can give to CGI scripts, there's another technical reason why this mode is used as default one: on Windows, environment variables cannot be set properly by Cheyenne due to a strict variables per-process OS isolation. Working around this is possible but requires to re-implement most of CALL native at mezz level in order to support plain CGI mode on Windows. Until now, I was reluctant to do that, estimating that the cost (in time and additional code size) wasn't worth it (and that everybody should use RSP technology instead of CGI), but your post here, makes me realize that it's a necessity. | Greg Schofield
15-Nov-2010 16:09:22 |
Steven White, touches on things beyond documentation.
I have a theory, that REBOKL should be amongst the easiest languages to use – but isn’t.
For a long time I thought it was just a need for more documentation. But I don’t think so anymore. While more nice examples and how-tos can never go astray. And despite that there are some well known documentation holes and some newly developed ones; REBOL’s documentation is actually O.K..
I have decided the problem lies elsewhere. Some people get REBOL and others like myself struggle and struggle and don’t really get it. I can get things done, but soon forget how I did it in the way I did.
Documenting for what you are likely to forget is a forlorn enterprise, it assumes you know what is vital at the time which is a mistake -- I like everyone else suddenly see how things could work better, write test it and then forget the inspiration which was probably a visual or linguistic analogy to begin with.
What is wrong with me are assumptions, half-baked notions picked up from half-dozen different script languages and dodging about minor software fixes. I have the confidence to get things done, albeit slowly and with some confusion, but I do not have the competence.
There is something fundamental missing, and it has little to do with REBOL except in REBOL this fundamental understanding is at the heart of it, something that is very well hidden in many other languages (usually under a huge number of prewritten functions, which is usually what people like me look for – that is the bits that “do things” and the other bits that let these bits do there thing where it is needed).
Hence if you come to REBOL with experience in compiled languages, you may have a big advantage, but if you come in from the user end of things, then you may have a big disadvantage. Ironically gaining from the pool of established programmers is self-limiting, it is the great unwashed that are the real hope (after all haven’t they made things like Python popular).
So here is my big thought for REBOL to gain the popularity it deserves – don’t explain REBOL so much as how REBOL interacts with computational logic. What makes it work, in general. Where does its character lie in terms of the machine? Why does it go about things the way it does and what does that tell us about computers?
Then introduce the language – but first get the concepts right, so that a novice not only understands REBOL but gets a much clearer picture of how computers work with languages in general (based on REBOL’s character).
One of our problems is that Carl and the other developers are a little too good. They are well ahead conceptually and people like me are sitting in their dust.
Sometimes the best route between two places is an indirect one.
I think we need someone whose knowledge of computing is profound to write down the fundamental idiots guide to how a language makes a computer do things – that the whole point of this is to illustrate each notion rebol-like and make the language the most natural conceptual explanation of the computer (ie only those aspects that fall within a scripts purvey – not every possible thing). | Kaj
16-Nov-2010 6:12:40 |
I agree, I think Carl has been too scared to explain REBOL in all its naked difference. By trying to explain it in terms of other languages, you're obfuscating it so that it takes many years to discover the simple truths. | GUI
19-Nov-2010 18:09:31 |
on on that note, from an end user perspective, carl already knows that people interact Best with graphic tools and objects as was seen in the simple stuff , make a box ,fit it with stuff, connect to another box and SEE the Interaction visually....
all the core dev's working on rebol seem obsessed with the written word, but ordinary people dont think like that, logicically You NEED a GUI like that old Very limited script Carl already made years ago but on-one ever took up and actually expanded into a full self contained app
http://www.mail-archive.com/list(at)rebol.com/msg10235.html
"[REBOL] GUI Maker - You'll like this.
carl
Mon, 18 Sep 2000 15:27:51 -0700
I just uploaded layout.r -- a script that builds REBOL graphical user interfaces.
With it, you can easily create REBOL GUI's without needing to program a line of code.
You can get layout.r by running REBOL/View and clicking on REBOL.com. When you start
Layout it includes a few short instructions on how to use it.
It's pretty good. You can do some fairly sophisticated GUI editing with it. Of
course, it is just a prototype and there is more to come. It is likely to blow out
here and there, so save your work as you go.
Operation note: run the script in a directory that has a few image files (jpg, gif,
png). That way you can paste the images easily.
So, now you have no excuses. Let's see some REBOL/View interfaces.
-Carl
PS: I wrote this script over the weekend, along with crushing our Merlot grapes. It
will give you a good idea for what 25K can do in REBOL/View.
"
drag and drop pre-made GUI/scripts into these types a box app's, and you have a simple DPaint type layout app that's actually a very good visual aid to creating masses of Real end users app's in a flash, keep it simple, so make it simple for end users, that is all.
| John
21-Nov-2010 18:51:46 |
If you want more people using Rebol, make is easy to do things with it.
When i first started messing with it, I was looking for a simple to use scripting language. Not Tck/TK, Perl,etc.
Rebol was it. I saw some of the scripts and thought, "This is what i've been looking for". But now some of the scripts i see are as confusing as C+. I realize you're trying to keep it small by cramming a bunch of stuff into it. I wouldnt mind having to grab a "module" to perform a specific task. Its that what Rebol was for to start off with? I think it would be the perfect SOA language if it was ever stable enough.
I dont care how it interacts with the computer. I just want it to do the processing it supposed to do.
| Steven White
22-Nov-2010 9:13:40 |
"But now some of the scripts i see are as confusing as C+."
Yeah, I notice that also. Why is that (a rhetorical question)? I don't have the specific example, but I can remember looking at ONE LINE of REBOL and being completely unable to figure out what it was doing. I think the problem is in my own head somewhere, maybe from decades of programming with one tool, and therefore thinking that ANY programming language has to have SOME way of doing the things that I am required to do with the tool I have been using--a chain of questionable assumptions.
I think Carl has something in his head that makes some things self-evident to him, that are not to others. | Greg Schofield
22-Nov-2010 18:18:04 |
Steven White
Assumptions are damn hard to dispose of unless you know what they actually are, which is my problem as well.
It is not self-evident to me, and it is clearly self-evient to others. Besides which, I always write code with too many redunancies as I never sure just what is doing what and how. | Kaj
23-Nov-2010 9:06:58 |
Here we're reaching why REBOL is different. It's hard to explain with simple examples, because they still look fairly much like other languages. When people try to do larger things in the style of other languages, or when you look under the hood of REBOL's implementation, things get complex or unfamiliar or both.
REBOL's way to solve this is its fundamental building block: dialects. REBOL's implementation under the hood is meant to facilitate dialects at higher levels, and at those higher levels, people are supposed to develop dialects to reduce complexity. This requires a degree of understanding of language technology, so it is not for everyone to design, but it should be for everyone to use.
Developers are not designing dialects enough, because they're still in the mindset of other languages. | Steven White
23-Nov-2010 10:18:57 |
"REBOL's way to solve this is its fundamental building block: dialects."
Now that is an interesting topic. My mindset definitely is of other languages. I try to write COBOL-like REBOL just to organize my thoughts in a familiar way.
So, regarding dialects, VID is a dialect. I can imagine how someone would invent it. One would want a way to place things like text/fields/buttons on a screen, so one might decide just to declare them with key words ("text" "field" "button") and let them be placed on the screen in order of declaration, top to bottom, left to right. Add a few positioning words ("across" "return" "offset") and so on. I can imagine how one might use "parse" to get the individual words of the dialect. But then what? I have no idea how one would proceed after that.
That seems like a possible documentation topic: How to write a dialect. How to use REBOL effectively.
| Kaj
23-Nov-2010 11:36:20 |
Yes, VID is the best example of a dialect and its usefulness. It also shows that Carl is still journeying along his "grand experiment" because VID is all new for REBOL 3, and the way it's implemented has also developed quite a bit.
I made an attempt at explaining REBOL in terms of dialects in my Boron presentation a few months ago:
http://tryrebol.esperconsultancy.nl/Boron/ | Nicolas
27-Nov-2010 0:03:24 |
If Rebol went to android it could actually find a successful niche in software development. | Kaj
27-Nov-2010 3:44:50 |
It will. | Luis.
30-Nov-2010 1:32:18 |
It's not 'just' the complexity issue, it's also a 'completeness' issue. Last post on Twitter (6:44 PM Nov 11th) essentially says: 'If you want graphics on OS X do it yourself'. Ok, well, same would apply to Linux I would assume, so Rebol would no longer be cross-platform by _default_. It can get simple, but it needn't get too simple or you leave people behind.
Sure 'why don't you port it if you need it': Some of us don't have the time/resources/ability - From Rebol 2 to Rebol 3 you'd expect some semblance. I'm surprised that even in the Quick Reference Card no R3 Schemes are documented.
Oops, better get off this tangent...
Cheers,
Luis.
| Kaj
30-Nov-2010 14:24:46 |
Yes, because an alpha version means that software is not complete yet...
I'm very pleased that REBOL 3's new strategy is "do it yourself". That has allowed me to get it to run on Syllable Desktop, a year ago after Windows and Linux, before Mac and all the others. What do you think the chances of this happening would be if RT had to do it?
If a platform is in demand, it will get a REBOL 3 port. If it isn't in demand, nobody will care anyway. | Luis.
1-Dec-2010 1:58:21 |
Shouldn't the Alphas progress at a similar pace, regardless of the Platform? Unless you meant to have that as an indicator as to where the Company priorities are, which is a sure way of alienating a range of users...
But then it might just be the way RT does Alphas?
From 'What is Rebol?': "REBOL is cross-platform.
A program written on Windows runs equally well on Linux, BSD, OS X, and many other platforms... with no changes necessary."
Are you implying that that comment will require a disclaimer or that the comment should be removed?
Nowadays, the target audience is varied, as well as the developemnt platforms. When you hobble one it affects all the others, as well as the commitment to the product, especially when you a led to expect feature parity.
Cheers,
Luis.
| Kaj
1-Dec-2010 10:30:30 |
Why do you keep expecting release quality from an alpha? | Luis.
2-Dec-2010 2:04:14 |
(at)Kaj: I never stated that.
Feature _parity_ is not equal to release quality.
Cheers,
Luis.
| Kaj
2-Dec-2010 13:55 |
Reaching feature parity would be a good criterium for moving R3 from alpha to beta status. One way or the other, alpha status promises neither release quality nor feature parity. | Brian Hawley
3-Dec-2010 16:39:14 |
Luis, the other platforms aren't "hobbled", they just don't have as many people working on them at this early stage. They don't have as many users working on them either, so that's understandable.
It is possible for R3 to be in beta on one platform while being in alpha on another and not even started on another. And it is definitely the case now that while features are being designed that they can initially be implemented on a single platform to test out the design. Features that are designed to be cross-platform can have most of their design issues resolved quite nicely using a single reference platform. If you port features to other platforms too early then the port will sometimes need to be redone as the design is refined, wasted effort.
I for one am putting platform issues on hold until the non-platform-specific design issues are resolved. When we have a stable core then I can worry more about varying hosts. | Brian Hawley
3-Dec-2010 16:55:25 |
"an indicator as to where the Company priorities are"
The core is a company project with community help. The rest is straight-up community projects, in some cases with certain parts of it being sponsored by other companies. Everything platform-specific is in the community portion, and everyone in the community has their own priorities.
In a community project, the way that you avoid alienating people is to make it possible for people to make stuff available on their favorite systems. Like Kaj is doing with Syllable, or Steven Solie is doing for Amiga. There are people in the community that work on OSX and Linux, so they are getting some work too, though they could use more help. Beyond that, remember that this is a community project, and participate. | Luis.
8-Dec-2010 6:49:45 |
So, RT no longer delineating the 'outer' layer/schemes means that feature parity will no longer be a selling point? Does this mean that Rebol Core would be the only 'truly' cross platform version?
Will RT only be producing Rebol View for Windows?
To me it's not a question of alienation in the sense you appear to refer to, rather a consistent and predictable behaviour set akin to what Rebol 2 is now, which may alienate those looking for exctly that which was present in R2.
Cheers,
Luis.
| Kaj
8-Dec-2010 8:56:56 |
Sure, people who insist on having exactly R2 will be alienated, no matter what. But of course, they can still simply download R2. | Brian Hawley
10-Dec-2010 17:01:10 |
Luis, even Core won't be truly cross-platform. Back in the old days of 10 years ago all of the popular platforms were operating systems that ran programs that were pretty much comparable in concept to programs on other platforms. You could support 40+ platforms pretty much identically.
Now most of those 40+ platforms are gone, no longer supported by the people who made them, and the popular platforms that are comparable to those old ones are at most 6, including server operating systems, and even those aren't quite the same any more.
New platforms have come up that REBOL could support, but they are less compatible with each other than ever. Some don't even have programs as a concept, some are applications themselves that people write plugins or extensions for, some only support apps that are a hybrid of more than one programming language, and some don't even have displays at all. Different form factors, different scales of operation, different purposes.
There is no reason to expect all of your code to be portable or even definable in all of these varying contexts. If there is no display, there is no point to a View build. You might not even be developing applications in the sense that R2 allows. R3 makes this possible in ways that R2 couldn't.
Possibility is the selling point, not limiting ourselves to what is portable. And if you want to limit yourself, R2 is still there, stable (for the most part) and supported. | Luis.
15-Dec-2010 1:17:46 |
Sounds like a good way to reduce your user base.
Well, looks like reason enough to finish up my work on R2 and find an alternative to R3.
Cheers,
Luis.
| Kaj
16-Dec-2010 8:38:17 |
Is RT supposed to scrap its new product line now, because you're threatening not to use it? | Luis.
17-Dec-2010 2:20:44 |
(at)Kaj: If you're taking my CLEAR and DEFINED position/opinion as allusion to grandeur, think again.
Cheers,
Luis.
| Brian Hawley
17-Dec-2010 16:34:41 |
R3 and R2 are going to be aimed at different purposes, and are designed for a different world; a lot has changed in the tech world in the last 10 or so years.
Some people for whom R2 is more appropriate won't make the transition to R3. On the other hand, some people for whom R2 was not enough may find R3 to be more capable. Some people will likely be upset by the changes, or upset that things haven't changed enough. Any change in the user base will be a net change, not a strict superset or subset.
I wish you well in your endeavors. Good luck with the new and varied tech world we will all have to adjust to eventually. | Luis.
20-Dec-2010 3:24:20 |
So much for the 'Fight' in 'Fight Software Complexity Pollution'.
Cheers,
Luis.
| Kaj
20-Dec-2010 8:33:53 |
And your solution is to give up completely and switch to something else? | Luis.
21-Dec-2010 3:07:47 |
If all I get is one shoe to run with, yes.
Cheers,
Luis.
| Michael Czajka
21-Jan-2011 1:42:34 |
I like the Rebol approach. I've made a point of searching out small and simple programs that do what big porky ones do. Same with operating systems.
It's definitely possible.
The place where small is good is on mobile phones... maybe there's a place for Rebol there?
:-) | Henrik
22-Jan-2011 0:30:31 |
It's interesting that, when:
1. Carl creates an open model for development.
2. Spends years constructing R3 for open adaptability to different host OSes.
3. Invites the community to participate in REBOL 3 hostkit development, when the hostkit is available in the first version.
4. It's interpreted as "do it yourself, stupid, I'm not helping you", by one simple tweet.
The ball is truly in the community court, regarding the OSX version, but nothing has happened yet. Carl might be pretty disappointed to find that out!
Is this due to the above interpretation? If so, that is exactly why the OSX version is going nowhere, fast. It must be some kind of cultural difference, I don't know about? Is Carl using the wrong words? It's simple work delegation. Is that so disastrous?
The AmigaOS4 version is actually ahead of the OSX version, simply because one determined and skilled developer, Steve Solie, wanted R3 to run on AmigaOS4. It does so now with graphics and awaits the next hostkit version for fixing flaws that he exposed in the current hostkit.
Mr. Solie interpreted the tweet correctly. | Kaj
22-Jan-2011 7:37:13 |
Both these viewpoints are unreasonable. Yes, we have a great opportunity now to influence REBOL's destiny. No, it's not reasonable to expect "the community" to take on advanced tasks right away after they have become possible. For one thing, "the community" doesn't exist. We're all individuals with different life and business priorities. Carl is one such individual, and REBOL has mostly reflected his priorities for thirteen years now. That creates a certain environment, so yes, there's a cultural difference. The current REBOL ecosystem reflects thirteen years of this dependency hierarchy, and above that, half a decade of decay of that system. All the effects we've been seeing stem from that.
You know I'm working fulltime to add to REBOL 3 since that has become possible recently. I've mostly aligned my priorities with those of REBOL. But you can't expect many people to do the same at the flick of a switch. Rome wasn't built in a day. It was destroyed in a much shorter time than it took to build. And rebuilding? That may take longer than the original build. | Luis.
27-Jan-2011 6:52:41 |
You're not getting my analogy with the shoes...
Currently, R2 comes complete. R3 will not. That's not what I would have expected.
Whatever the reasoning behind open/closed is moot: To me (and it appears, to some others) R3 when 'finished' will not be 'complete'.
As Kaj noted, we've all got different priorities. My priorities were covered with R2, and they will be lacking in R3.
Lets say you had the option to buy a PC with Windows, MINUS ActiveX, IE, Paint, etc, which you would have to look for and install yourself (provided they were available for your 'make' of PC! The maker of PC-A might not want to 'develop/convert' IE for their model - Extreme, I know, just using this to make a point...) and one with Windows INCLUDING ActiveX, IE, Paint, etc. Even if they cost the same I would estimate a much larger percentage would opt for the PC with all the apps included. Which option would a company wanting to buy a new round of PCs go for?
Another example: What if Python didn't have an OpenGL Library for Windows, but it did have Direct3D for OSX, QNX... How many Windows developers would pick it up?
Cheers,
Luis.
| Kaj
28-Jan-2011 7:57:17 |
The only "solution" to this would be to postpone the release of R3 for several more years. What good would that do? | Henrik
28-Jan-2011 11:38:41 |
Luis,
I'm not sure what you will be missing in R3. R3 will be able to do everything that R2 does and much more.
Compared to R2, R3 is going to be an enormous effort to finish, since it allows for much greater flexibility and depth in places that R2 could never reach. R3 allows for more conceptual usage, as a glue tool inside other programming environments unlike R2, or as a complete REBOL-only environment with a console, GUI, etc. like R2, but internally is highly modular. Also, given Brians reasoning, R3 must be much more flexible, to fit in a modern environment.
R3 cannot go unprepared into future operating systems. This is where R2 fails.
R2 is also not as complete as you think: The OSX version lacks several important features that the Windows version has. The Linux version has various deviations. Other OS versions are no longer maintained. They cannot be quickly updated by third party developers, because they are part of the closed source environment of R2, where everything has to go through Carl.
They can be added in R3 right now. | Tired of waiting
17-Nov-2011 10:28:15 |
I've concluded that Rebol is, and always will be, little more than a hobby language, a toy, which is a shame. Carl is Rebol's Wozniak, but who is the Jobs, the person who will actually get the R3 product out the door and into the hands of the public? Doesn't seem to exist. When will it be ready, if ever? Five years? Ten? | Scot Sutherland
10-Dec-2011 23:21:24 |
I am fully and totally behind the "Fight Complexity Pollution" campaign because whenever we are required to install huge software libraries we don't need we become enslaved to software that will require frequent updates that break our code, or we become constrained to requirements that are neither useful or necessary.
I recently wrote a complete video analysis software tool for our research lab. It makes it easy to synchronize multiple videos with network data streams and transcripts, clip synchronized video and add subtitles with network data.
The tool compiles on Mac OS X to 840K on disk. We use the Quicktime 7 Pro libraries and my biggest worry is that QT will be updated and the libraries will no longer work. The tool works perfectly as it is and we don't need any updates. Yet because Mac OS X is frequently updated, QT gets updated as well. Complexity pollution. We are slaves to these unnecessarily monstrous libraries that may not work with the next OS update.
On other projects using other platforms I have found myself continuously rewriting old code because the libraries I am using have been "updated." Just like the government workers who spend their lives redesigning processes around filling out forms, we will soon be spending our entire existence continuously rewriting old software. The kinds of innovation we saw in the Amiga days are long gone, not because programmers aren't smart enough to be creative, but because complexity has engulfed is.
In my experience open sourcing software makes the problem ten times worse. Each developer thinks they have a better way to design the software and it fragments into dozens of incompatible threads. Open architecture-closed source is the best approach because everyone is constrained to the same architecture.
So I am 100% with you Carl. Fight complexity pollution. Keep REBOL closed source but continue to open the architecture.
Dialects are amazingly helpful and powerful. In our algebra classroom network environments I use dialects that allow the TI-83/84 calculators to work with the Net Logo server in a distributed computing system. No REBOL to be found. I think we need to stop making excuses and fight complexity wherever it's found.
DOWN WITH COMPLEXITY POLLUTION! | buddyontobuddy
4-Jul-2012 10:23:11 |
I have been researching every aspect of a possible career move. This post is very helpful and shows that you have a lot of knowledge on the topic. Do you have any others?
here
| sentrycontrol
9-Jul-2012 5:50:31 |
Part of a class I am taking involves this particular subject and I am researching for information to use in an upcoming report. Your post is really helpful; do you have any others on this topic?
cost of liposuction
| ZeeTv
15-Jul-2012 21:53:37 |
Your article has helped me to understand this subject on a different level. I would like to appreciate your efforts for exploring this issue. Thank you for your information.
EEG Neurofeedback
| Elliott Smith
22-Apr-2019 18:51:56 |
Tomorrow, Tomorrow
https://www.youtube.com/watch?v=dEscwi6OZWk |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
