Home   Archive   Permalink

Red dialect (DSL) whose code-name is Red/CCC (Cross Chain Code). with GUI

The new message about Red dialect (DSL) whose code-name is Red/CCC (Cross Chain Code)says they will build a GUI for using the tool. I really, really, hope that they will build a small graphics very much like or exactly like AGG and tie it to RED, when called. That way the whole RED tool chain will have a easily compiled GUI just like Rebol. If they do this then, if I'm not mistaken, then the only change will be to find out how to write to a frame buffer for each OS that RED runs on and right after that you have a whole system with GUI and all. I think the idea that Rebol had of having a simple GUI with all the various OS's was pure genius.
I also think making tools for contracts and block chains will really drive, promote and advance RED. It's very forward thinking. The market for this is exploding. Even if BitCoin crashes block chains are very useful in themselves.

posted by:   Sam the Truck       28-Dec-2017/4:23:28-8:00

The counter question to ask is who will trust their bitcoins to any app that was created using Red?
With such a small group of users the apps and language can not possibly be robust enough for that kind of usage?

posted by:   Arnold       28-Dec-2017/9:15:37-8:00

Arnold, do you think that an average bitcoin investor knows or cares about the language technologies used to create bitcoin infrastructure?

posted by:   Nick       29-Dec-2017/5:15:40-8:00

The choice of preferred tooling used to create any new technology will be a engineer's choice, not an end user's choice. Doc's article points out that other existing blockchain development tools are currently not well established and troublesome, and that the market is young and poised to grow dramatically. If business managers currently have no other well established tools to trust, regardless of the language in which they're implemented, then there's an opening in the market for new technology. This sounds like a great way to attract the interest of serious engineers, potentially grow the user base of Red (among a class of developers who do more than trivial crud work), vet the entire Red platform in a rigorous environment, provide a modern use case for the relevance of dialects, etc. This seems to me to be a great potential proving ground in which Red could gain some traction.

posted by:   Nick       29-Dec-2017/5:44:55-8:00

I'm open to every argument, and success in this domain is not necessarily a silver bullet for Red. Here's an article which questions the practical value of the whole premise of blockchain:
Still, it's a trend, and capitalizing on the popularity of a prominent trend is not a bad marketing strategy. In a market which is extremely difficult to break into, I'd challenge anyone to come up with a better plan (I still think support for all modern desktop, mobile, and web platforms are key).

posted by:   Nick       3-Jan-2018/8:17:49-8:00

My whole "batteries included" GUI pitch might seem obnoxious to the purist but has a "firm" foundation in utilization of technology and history of winners. The best is not often the most used. The most easily accessible is. VHS vs. Beta. PHP? no one calls it the best language. JavaScript. "C" programming language and it's tool chain. The Unix operating system. There's a whole article on this somewhere about how in Unix the East coast version was made to be good enough with tons of holes but easy to patch up to do whatever was needed. Look at Common LISP. Widely seen as very sophisticated but instead people use JAVA.
I think Doc's abhorrence to a portable GUI is marketing based and a revulsion at the look of Rebol. I think he believes that any cheesy looking GUI that pops up instead of the native GUI will taint his product as some Chiclet thing with funny graphics. He may very well be right but the simple GUI will be much more portable. Write it in RED system as a library with all the VID stuff at a higher level. Use the native GUI on the larger platforms. The solution to this problem is to have the small built in GUI not be built in. Call it a
"portable GUI" and make it a library added to the console. That way people that use it will understand it's just the "portable version" and not the full course native GUI. So you retain all the virtues of a easily ported GUI without the negative connotations of the "portable GUI" unless it's needed and if so there it is.

posted by:   Sam the Truck       6-Jan-2018/10:32:03-8:00