World: r3wp
[I'm new] Ask any question, and a helpful person will try to answer.
older newer | first last |
Pekr 31-May-2007 [400x2] | R3 should be released to public July 15. Of course there will be some bugs to sort out, some things to finish, etc. In the meantime, you can study some docs - most things will stay valid. It is not change in philosophy, whole architecture will just get much stronger. |
Now for some frameworks: | |
RayA 31-May-2007 [402] | Thank you for the links! I briefly saw some of the information, but not being a guru, I'm really looking for the "idiot's guide to REBOL" that gently introduces the reader to the power of REBOL through simple examples so I/others can "think deifferently" about programming and undo all the years of bad habits from other languages. |
Pekr 31-May-2007 [403x2] | We have XML-RPC for intercommunication, my guess is - not used much, but fine when you want to connect to server, which does use it. Rugby - RPC broker. VERY easy to use, you would be surprised! You simply start server, you define which functions you expose, something like server [my-func1 my-func2] and then you just connect. It uses functions stubs, so actually your source code is not revealed to client. |
REBOL/services - architecture developed by RT themselves, which will be part of every REBOL release, to standardise. You can find it via rebol.net IIRC. There are some docs, examples. It is not fully finished, it does not work if you are behind the proxy, and is not properly async, hence ppl work for R3 (which is async by default). Very strong concept, and once R3 is out, we will ruin other languages world via simplicity. You should also learn more about dialects, what they are, how those could be used, etc. | |
RayA 31-May-2007 [405] | I live in the East Bay of Northern California, and I'd be interested to meet REBOL developers/users in the area, if anybody is interested. Also, out of curiosity, where are the active developers located? |
Pekr 31-May-2007 [406x3] | Uniserve - multiplexing engine, kind of Medusa (Python). Uniserve engine is used for Cheyenne web server (look for that group here), and it is kind of cool web server, faster than Apache 1, fully REBOL based (well, who said scripting languages are slow? ;-), you don't need to install anything. It allows you to plug/unplug services when server is running! |
active developers? Here on AltME plus ML ... we are small community, but you mostly get your response/help in minutes/hours .... | |
also - in Rebol/View, start desktop and go to rebol.com site to see some tools, demos. Right clicking them you can get to its source code ... | |
RayA 31-May-2007 [409] | If you are are the norm, then this group is very responsive and helpful! Are developers using REBOL in there jobs or mostly in their spare time? |
Pekr 31-May-2007 [410] | some older resources - http://www.rebolforces.com/, weekly activity - http://rebolweek.blogspot.com/ |
RayA 31-May-2007 [411] | Are people many building tools for REBOL, or are they building "killer" applications? If so what types of applications or industry domains? |
Pekr 31-May-2007 [412x5] | mostly a spare time, but look at Carl's presentation - he sumes it up there too. There are few developers, doing REBOL full time: - few top developers present here work for RT on contractual basis. - there is a company called SafeWorlds (Reichart's company) - he employs tens of ppl IIRC. Their new system is http://qtask.com, front end is web 2.0, but whole back-end is REBOL based. - few developers working on their own - Henrik, Ashley, DocKimbel (mySQL, postgress cool protocols, Uniserve, Cheyenne) |
well, REBOL 2.0 generation allows mainly PITS (programming in the small). Some are building tools, or just some styles for View, then release to public. PPL do build applications, but I am not sure those are "killer" ones. E.g. AltME - secure from the very beginning, fine for your small team, but is that killer app? Hard to tell :-) | |
I forget few others, let me add them: | |
Graham - EMR system for doctors - http://synapsedirect.com/default.aspx Ashley - RebGUI - alternative gui system for View, less resource hundry, less free form, but more complete, fine docs! - http://www.dobeash.com/ Maxim - he does stuff, no one properly understands, he is kind of crazy, but we like him :-) Data Flow engines etc. Look for Still, Liquid, Elixir, etc. | |
and of course, there is one commercial system, which was nominated for Webby Awards in 2002(?), along with Google - REBOL IOS.Pity it is not supported much, but you still can buy it. With R3, altME, View and IOS concepts will merge, and what we will get will be kind of virtual OS ;-) | |
RayA 31-May-2007 [417x2] | I've "meet" Ashley, a very helpful Aussie who sang the praises of REBOL and got me conected to the Rebol3 world! So a big thanks to Ashley. |
It seems that the the time might be right to develop a "killer" application that leverages the power of REBOL3 ;-) | |
Pekr 31-May-2007 [419] | yeah, of course - any suggestion? :-) |
RayA 31-May-2007 [420] | Well actually I do, and the customers are ready for a major change, but the "killer" application must be scalable, fault tolerant, manageable, support hot code swapping, and by priced right. |
Pekr 31-May-2007 [421] | what kind of app are you about to build? Will you use also REBOL gui? Or a web front end? |
RayA 31-May-2007 [422] | I believe in Carl's vision "REBOL is perfect for lightweight distributed applications". Users need light-weight responsive gui clients that can work both online and offline. The evolution of the Web is moving (slowly) in this direction, with AJAX/Flash/JavaFX as examples of a more responsive and rich gui clients, BUT it's too complex and unreliable. The industry is adding kludge upon kludge to "fix" the problems resulting in further complexity and code bloat, but what is needed is a clean approach that captures the essence of what made the web a phenomal success in the first place - any body could set up/develop a web site and they did. Enterprise data centers need scalable, reliable, manageable (server) applications that run 24x7 on commodity hardware ata reasonable price. The user PC's should require zero management for the applications, which is the primary (only?) attraction of the web ui. Question if the application is simple to manage and delivers the functionality the user wants, why do they need a fat complex os? As an example my kids get online to play games, research homework, etc. and they hate it (so do I) when the PC/OS gets in the way. Also, that PC/OS is a major source of trouble with viruses and lack of (simple) control to what my kids can access. |
Pekr 31-May-2007 [423] | absolutly correct, and that is imo why you are here :-) |
Ashley 31-May-2007 [424] | re: tutorials. How about: http://musiclessonz.com/rebol_tutorial.html |
RayA 31-May-2007 [425x2] | Other examples. Google (and other NetSuite, etc) is developing suite of "microsoft office" online only applications, but I can only speculate they are working on how to make it also work offline as well. Microsoft is working on making office work on the web as SaaS (or S+S as their marketing refers to it), so the writing is on the wall. |
IMHO, I don't believe hese companies are capable of developing a clean solution, in fact it may not be in their best interest. | |
Pekr 31-May-2007 [427] | yes, they still base upon what is awailable, so extending the bloat, praying connection to internet and speed of our devices is fast to work with what they deliver .... |
DaveC 31-May-2007 [428x2] | Hi RayA and Welcome. I am a new to AltMe too. I think you are right about the evolution of the web. The Desktop OS has become an application in itself (IMHO). It's the focus of so much angst, controversy and complication. (Nailing my personal colours to post here: I declare myself a BSD UNIX type. I can still install the latest version in much less than 100MB of HD space and 32MB ram and 100Mhz CPU. In fact I run it on an old Toshiba laptop with that spec and get real work done) I think, in principle, DOS was my idea of a good OS (I know, I know...) It was small, fast a stable. Yes - lockups were common when pushed, but I found it was the application that crashed rather than DOS itself. Ok. back in the world of the 21st Century, an OS need many many times the resources of DOS just to get itself booted. But basically, all I want from the OS is to let the applications get on with the job in hand. What attracts me to Rebol is that it is clean and lightweight. Designed by a man who I respect as a Computer Scientist. (And, of course, the Rebol community, which collectively one might say is a "killer app" too). It's very productive and I'm building internal information systems with it. I've got a few ideas to build my own apps outside of work, that is an exciting prospect for the future. I keep trying other frameworks/languges and over the last six years or so I've lost the "Rebol way" and strayed from the one true path! I do find myself coming back to Rebol as I run into more library conflict/dependency/blot features of some of the other languages I used. Maybe I'm getting impatient of complicated technology now I'm older. I just get tired of having to search the internet for the latest whatever.so.1 lib, or what have you. I'm making a general point here BTW - I know there are some very good language implimentations out there. I don't know what the next killer app will be, but I do think there is a place for a machine "Powered by REBOL" which boots in a few seconds, lets me communicate, write view images, multimedia, code my own Rebol apps from a set of built in services, oh and the battery lasts for days - not hours! It would have to display HTML too (legacy web :-)) So there you go, a bit of a rant from an old geezer technologist . Now where's me 8" floppies I need to boot that PDP-11? |
blot = bloat | |
Sunanda 31-May-2007 [430] | RayA: <Other examples. Google (and other NetSuite, etc) is developing suite of "microsoft office" online only applications, but I can only speculate they are working on how to make it also work offline as well.> They announced how yesterday: http://gearsblog.blogspot.com/ |
Gregg 31-May-2007 [431] | Does REBOL provide architecture documentation/guidelines and/or frameworks for the development of scalable, fault tolerant, manageable, with hot code swapping for soft real-time 24x7 applications? Petr already covered the basics (Thanks for doing that Petr!), so I'll just chime in with opinions. I've been using REBOL since 2001. No tool is perfect, and REBOL is no exception, but there are only a few things I think it really isn't suited for even in its current form. It was not designed for programming in the large, but that's a benefit as much as a drawback, until you start building larger systems. IME, REBOL does require a different mindset if you want to get the most out of it. You can write code as you would in many other languages, but you won't see the big benefits REBOL offers if you do. It's still a good tool, even used that way. The docs and tools you asked about don't exist in official form, but there are a lot of "pieces" in the community. I'm working on something now that has those same goals. |
DaveC 31-May-2007 [432] | Rebol does require a different mindset if you want to get the most out of it It's what I call the Zen of Rebol. I think it explains why it's taken me years to really "get it". I'm still learning of course. In a way, I wish I'd not had a backgound in procedural languages before Rebol. |
Henrik 31-May-2007 [433x2] | I find myself changing the mindset with REBOL every few years, because for a long time I was afraid of for example, using PARSE. PARSE is so central and important that it can change the way you work with REBOL, if you have stayed away from it. I had the same experience when starting to use the SDK and when starting to do networking stuff in REBOL to let scripts communicate with eachother. It's not just a new set of ideas that turn up that lets me add to existing scripts, but doing the same scripts in entirely different ways. I feel I know about 30-40% of REBOL. :-) It's so damn deep. |
I'm still afraid of ports and the event system. :-) | |
DaveC 31-May-2007 [435] | Yes, I can only swim so deep before I run out of air :-) I read a snippet of code related to the system object and think, Wow! I didn't even know that existed. As you say, Parse itself is such a powerful thing. What I find inspirational is to sit down in front of the console and just explore ideas. |
Geomol 31-May-2007 [436] | REBOL is like a little, magic and very deep lake high up in the mountains. It doesn't look much on the surface, but you'll be surprised, again and again. It's a good exercise (maybe not for the totally newbie) to read some of the scripts, Carl has produced. They can be found e.g. in the Library. You find things like this one, that I trampled over in his color-code.r script: set [value new] load/next str load/next ... !!?? cute! :-) |
Pekr 31-May-2007 [437] | to not speak only in superlatives, there are also some darker corners though. One of them being REBOL's isolation. There is nearly none linkage to external technologies. The reason is, that so far /library interface is imo "weak", and commercial. While with most other languages you will find links to things like non-odbc, direct db drivers, via libraries, or wrappers to some other libraries, such things are nearly non-existant with REBOL, not to mention stuff like ActiveX (COM) integration etc. |
RayA 31-May-2007 [438] | Thanks everyone for your prompt and honest comments. Why did I join this community? The primary reason is to be part of a small, smart and passionate group who think differently, which when combined with REBOL is a very powerful combination. Therefore it would seem that focusing the resources of the community on a "killer" application leveraging REBOL3 would increase the chance of REBOL becoming main stream, and as a side effect possibly allow part time REBOL developers to become full time REBOL developers. As an example, think what Ruby on Rails did for Ruby. Wouldn't it be nice to get paid to do what you love! IMO/E I believe it's very important for the application vendors to have very close and strong ties with the platform vendor so architectures and features can be designed and exist at the correct layer. Also, if something needs to be implemented in the application but really belongs in the platform, it can be done in a way that enables that feature to be migrated in the future with minimal impact and extra work. This seems to fit with REBOL's history of improving based on experience. I'd like to think it's possible to build great applications in 3 months, with new releases every three months as required based on requirements, so I don't have the time (and maybe not even the ability) to spend years learning REBOL. I'd also argue that for a company to be successful, it needs a small team to have a number of diverse skills which is focused on delivering the product. I mentioned when I first signed on that I would be interested to meet REBOL gurus who are in Northern California and see what happens when interesting (or not) people get together. Sorry for the length of this post and thanks for listening. |
Henrik 31-May-2007 [439] | About dialects: You may not know what it is, so I'll give a brief real example of what I did, when adding a dialect to my database system. It does 3 different database operations, the details don't matter, but here goes: lock-state: db/release locker-id current-object set [lock-state current-object] db/add-object locker-id if all ['locked-by-me = lock-state object? current-object] [ current-object: db/advance locker-id current-object ] This is RPC based, which means I call specific functions in the database over the network, pass parameters, get stuff back in return and maintain database environment variables. This is how you do it traditionally. Now with a dialect, you can say something like this: do-database [release add advance] As you can see, it's an incredible code reduction. Same 3 operations. A part of it is of course that database environment variables are maintained internally and are not really a part of the dialect, which further reduces code. But I consider it a side effect of dialecting and makes it easier to design a uniform way of talking to the database. Now which method would you expose to a third party developer? :-) |
Pekr 31-May-2007 [440] | Henrik - in traditional environment, you could cover it with functions db_release(), db_add(), db_advance() :-) |
Henrik 31-May-2007 [441] | Pekr, the functions would have specific and different input parameters. That's not required here. For example above, the 'add word, adds an object to the database. The 'advance word advances the same object to the next stage (hard to explain), but I don't have to pass the object again, since the dialect parser is not finished with parsing and keeps the variables in the air automatically. Besides, do-database is only 1 network operation. The traditional one requires 3. |
Gregg 31-May-2007 [442x2] | Why did I join this community? The primary reason is to be part of a small, smart and passionate group who think differently, -- Then you're in the right place. :-) I love this community; it reminds me of the old MSBASIC forums on CompuServe, before the rise of VB. I'm in Southwest Idaho, but have a good friend in the Bay area who thinks REBOL is cool, though he doesn't use it (yet). And, yes, there are some dark corners in REBOL, and things I'd like to see change. It's hard to complain, though, because *almost* everything I'd like to change I *could* change if I really wanted to. |
An important aspect of dialects, for me, is that they *don't* look like a series of function calls; there is often "implied state" which I think is powerful, but messes you up if you think in terms of functional programming. | |
RayA 3-Jun-2007 [444] | Since REBOL requires a programmer to "think differently", in general what type of person, skill set, and/or background is required for a person to be a good REBOL programmer? |
Henrik 3-Jun-2007 [445x2] | you must be patient, definitely, particularly when learning PARSE. You must be willing to dive into how figuring out how REBOL works |
you must accept that it does certain things differently, because there is usually a reason to why it does things differently. Some people won't accept this, and they won't figure out the true strengths of REBOL and go back to other languages. | |
btiffin 3-Jun-2007 [447] | RayA; I'm of two minds on this one. I'm attempting to show construction site bosses how to be 'good' REBOL programmers. Very simple, data driven code sequences. If you want to be a 'good REBOL' programmer, hang out here and watch for posts from the likes of Anton, Henrik, Gregg, Ashley, well...most of the players here. But a 'good' REBOL programmer can be anyone, in my humble opinion. |
RayA 3-Jun-2007 [448] | Thanks for the feedback. I'm not the "best" programmer (hopefully I have other strengths ;-) ), but I'm looking for different and better ways to solve problems and build applications. Therefore, would a programmer with a computer science background with NON procedural languages like Lisp or ML be more likely to "grok" and appreciate REBOL? Would it make sense to "hire" a young/new programmer out of college and get them involved with REBOL early so they have less "bad habits" to unlearn? Are any schools teaching their students REBOL? I appreciate the help and opinions of the group. |
Henrik 3-Jun-2007 [449] | knowing PHP already did not help me in learning REBOL |
older newer | first last |