Desktop/Console Goals vs. Web Framework Goals

Announcements
1

Things are currently going quite well with the JavaScript extension. It's an interesting case where we're actually on the bleeding edge of what anyone is doing--and our needs are feeding back into the design of Emscripten. So by comparison to our usual Amish tech modality, it's fun to feel somewhat relevant. :slight_smile:

  • The "ReplPad" console is coming along. It has a rudimentary Watchlist. It even has its own interactivity test. So hopefully we'll enter a virtuous cycle of improving it and being able to make sure it stays improved and does not break.

  • @BrianOtto has made an ambitious Rebol-powered application in UI Builder. You use a forms-building dialect to make a page that you can actually download as a folder you can put somewhere and statically serve on the web. Here's a tutorial...and you can see that it's a pretty intense first application!

  • @giuliolunati and @gchiu have been making it so that we can serve and get our hosted builds from S3, and we've done the magic so you really can make a jsfiddle and get yourself a Rebol, via one script with browser detection and wires everything up: load-r3.js

  • @gchiu is putting together some experiments embedding chess in the browser, or doing calculations for power bills in New Zealand.

I've mentioned that it's truly remarkable that the JavaScript code is all an extension. It adds nothing to the core build if you don't pick it out of the extensions during rebmake. It is an example of delivering what hostkit was trying to do but couldn't really: to make the core embeddable in an arbitrarily foreign host.

On top of all this, big technical steps have come down the pipe. Eliminating "hostkit" and factoring things into extensions slimmed the release JavaScript build by more than 100k (and the debug build by almost 200k). UTF-8 Everywhere made it in, and the system hasn't exploded yet. The Redbol emulation is still a very rudimentary effort, but it does build the static pages behind hostilefork.com, and it managed to generate a test PDF while running Gabriele's Rebol2 pdf-maker.r dialect.

...but in another month we'll be halfway through 2019

I'm trying somewhat to keep my eye on the clock.

In March I posted Web Build: Dangers and Opportunities. I said it was exciting there's interest in all these applications. And I've also encouraged people to do what's fun...it's better than being bored and wandering off. (When people are volunteering their time, they should do what they want to do.) But it means we're not really getting multi-person efforts--and keeping all these projects running has a cost.

It's an inescapable fact: these efforts are expanding the scope of the project--not focusing it. Reading between the lines, there is nothing metrically suggesting we are getting closer to any specific milestone of a language deliverable.

Open questions on GitHub and in forum posts are growing vs. contracting. There are some successes: there's nice solid "clicking" of things regarding the WORD!-ness of ISSUE!s and how ANY-STRING!s relate to ANY-WORD!s. But there's little in the way of historical question-marks being taken off the table.

Here's something that isn't a problem unique to Rebol in the world of software, but still a problem: if you sit down and try to write something real, you'll instantly face a paralyzing question with no compass. ("should the keys in a JSON object be SET-WORD!s...do you use MAP! or OBJECT!", "if you use a MAP! what would the literal form be", "how do module exports work", ...)

Should The Mission Be Changed: Web Framework 2021?

The pressures that have come down the pipe are to deliver more modularity for the construction of web apps.

This will consume all available resources.

My direction in thinking was different. I thought that a tutorial--and the vetting for what would go in the tutorial--would be a good thing to rally around. We could look at the script of what we were trying to teach people, and be asking "Hm, is that true?". This would provoke the writing of tests and specs...the closing of issues.

The tutorial itself would be feeding back into the definition of the artifact. When a tutorial point came to seem too much of a gray issue, we simply strike the feature from Beta One.

And having this tutorial selling 24/7 would hopefully bring on board new people, to feed back into the design and revive the effort of defining the language.

But if there's no common vision, we don't have to call this out as a priority. It can be a thing that happens on its own time--when and if it happens. So we can call it off if people think something more exciting is afoot. I just don't want to run into that trap of what I said in my other post: "If expectations aren't managed, then even Herculean successes can look like failures."

1 Like
2

I think people should write apps to learn what we can and can't do.

This will lead to demos for any upcoming tutorial but it'll mean considerable hand holding from you for us for the moment.

5

There's no question having a smattering of application types is informative. My point is that this is going in a different direction, so we have to sync up on that.

I was envisioning one web console--hosted on one site--with one master GitHub repository everyone added to. I was thinking it would be a bit of a monolith, added to with features mostly serving the tutorial. People were supposed to be excited about that, and save the idea of using it to write applications for "someday, future". I imagined the way the tutorial was built would be used for other things, just not that it would be turnkey any day soon.

But:

  • While asm.js and emterpreter were pokey and large, when I did figure out how to do pthreads + WASM...the result is fast enough to think of as a serious development platform.

  • You started the trend of forking it and other instances running on people's divergent sites--which may not have a console or tutorial at all.

  • We managed to clear the barriers for using it as a purely hosted lib through CORS, where anyone with a jsfiddle can name one file and write Rebol code in a <script> tag, manipulating CSS and the DOM.

This is all great and fine and interesting. BUT there's not much help on me make a tutorial (outside of helping with console UI, thanks @BrianOtto!) And there's no attention being given to mapping out and pinning down language commitments. What we ARE getting are cases of raising the bar higher and higher on what I have to build as a web application framework...and more and more concerns I have on whether if I change something, if it's going to break one of the N demos being juggled.

I'm not not saying this is intrinsically a bad thing. I remember reading that one of the arcade designers for Tempest who said they knew they had a hit on their hand because the other game designers--and just people around--were always wanting to play the prototype. If there's energy among the people making something where they feel compelled toward something--and you feel the pull of that gravity--it will probably translate to a general audience.

So while the Web Application Framework is a kind of insanely complex target--it may be we have the makings of a hit, here. Certainly there are others who would love to put whatever traditionally-desktop-codebase they have into your browser--whether that's Pyodide or .NET repackaged, or whatever. But their offering is ultimately different. ("These files can be quite large: Python itself is 21MB, NumPy is 7MB, and so on.")

If people are happy and things are being made how people want--at a rate that is acceptable--we don't need to stick to arbitrary milestones. I guess it's just a question of what people consider to be acceptable, and what they want.

It seems no one wants to put any energy into anything besides the web framework. So if that's the new deliverable, we should change to that and rethink scheduling.

1 Like
6

It seems no one wants to put any energy into anything besides the web framework. So if that's the new deliverable, we should change to that and rethink scheduling.

What are your expectations? I want to help but it's hard to do that at the same time learns the language. I have not moved forward since last time. I'm not really interested by a Web Application Framework.

9

I've learn't to expect nothing beyond anyone's stated commitments. (If that.)

Since volunteer efforts usually lack a lot of those, what worries me here is not really anyone else's commitment...but mine. I wanted to get a web tutorial on a somewhat pinned down "Beta" this year. I felt that could be about bringing in new people and showing why what we're doing is interesting. (It's worth watching that Python keynote from the guy talking about why Python needed to be on web and mobile.)

But I can't serve two masters. I can't do that -and- embrace developing this web framework that the small band of people who are already here want.

I could ignore @gchiu and his constant mad science, and say I don't care about the New-Zealand-power-bill-calculator or chess game (or wi-fi drone control, or...) But the thing is, this time it's not just him. @giuliolunati is factoring the Repl, @BrianOtto's first impression was to build the biggest baddest app he could think of (I hope, please tell me you're not planning bigger :-P)

It's a limited sample set, which points to my dilemma...and why I'm asking about if we're on the same page about seeing a tutorial built by the end of the year, with a push to getting what's in that tutorial to be language definitions we feel comfortable teaching.

If we don't push for that, the tutorial fades into "one of the apps" and we let it pop up when it is the right time, organically. So the question I'm asking is:

Are we happy enough with how things are going--in light of new information--to shift our bets and say "yes, this is more important, keep going this direction".

e.g. are we thinking that the first encounter your average user on HackerNews has isn't a guide toward a cool language tutorial, but a wild Rebol app built on this framework.

I think we'd do better refining and selling the language. The difference is the attention to detail. But I don't know, things are shaping up to be pretty cool.

10

Let's face it. You're doing things the wrong way round. Pioneers build the apps to show what's available, and the later immigrants are the ones that demand the tutorials.

Although it may seem logical to build the tutorial first, that's not the history of web development as I know it. Some hard core users get in first to do something cool, and the others follow.

I say we push on with a web development framework, and document the gaps as we go. Once it's usable by others, then the first of many tutorials follow

11

As far as I'm concerned, I think I need some written material to come to grips with, but there is a distance to Rebol that makes it more difficult. I like well-built documentations and I'm the type to buy a book for every language I learn, especially the books that explain the concepts of languages and then the language API reference. I'm not thrilled with the demo apps.

Everyone is not like me and I guess others want demos. Without written material what is a demo for? Rebol is too different.

12

Try this one. It was on Lulu but then made free

Rebol - A programmer's guide

Google for the free download from https://www.cristal.univ-lille.fr

https://www.cristal.univ-lille.fr/profil/olivier.auverlot#page2

13

So, my view is we need both :slight_smile:

The apps are what people are going to try first and say "Wow, this is awesome! I should spend time learning the language and see what I can build in it." ... but then they start asking around for documentation and tutorials and the only thing we have to offer is 10+ year old docs that are no longer relevant (i.e. vid dialect and other unsupported things), conflict between each other (i.e. r2 vs r3) or have too many semantic differences from Ren-C.

So we definitely need something to inspire people, but then we need something official, modern and up-to-date to learn from too, or else we may get a huge influx of interest and then it just dies off right away... and I think that would be hard to recover from.

The problem I see is there is very few active people here, and too much work to go around, and I don't know how to fix that. I've started to look at the reboldocs site again, and I'm hoping to get some momentum on the documentation there. But it will be challenging because writing always takes a lot of time and there is a lot to cover.

If we were to put together a wishlist of where people are needed, I would suggest something like this as a minimum ...

  • 2 people working on Ren-C (@hostilefork on the core, someone else on the JavaScript extension)
  • 3 - 4 people working on web apps using the JavaScript extension (focus should be on one app each, that is continuously polished until it is production ready)
  • 2 people working on documentation for Ren-C

We don't have these kind of numbers, and I'm not at liberty to tell people what to work on (or how to do it)... but I think this is where the need is, if anyone is looking to contribute. So I don't know what the solution is at the moment. Does anyone have any carrots they could throw over to the Red side?

3 Likes
14

"The Washington Post has 35 subscribers. Obviously, we'd love to have those numbers..." :slight_smile:

We have not--as yet--done much in the way of outreach to try to bring in more people.

This is why I am thinking that delivering small...entertaining...educational things is worth it.

There is the option of focusing on Rebol2 compatibility through emulation.

I do want to build that compatibility layer, but it's work and testing.

This is why I kind of want to rein expectations in. But I don't want to rein it in to where you think it's too unimportant to participate. And @gchiu clearly wants to push it bigger.

I vote against the web framework goal. I vote we find something smaller we all enjoy developing and seeing get better day by day. If it's not the tutorial...then okay, I guess? I thought that was a kill-two-birds-with-one-stone kind of idea.

If no one else likes my idea, should we pick UI Builder? Power calculator? Chess? Italian Bible Search Tool? None of these were on my radar until people started making them.

I still think my plan is the best one. I haven't been convinced otherwise. This thread is about me wanting to convince you, vs. having to swim upstream against expectations which cannot be met.

15

"Our two remaining reporters worked for weeks on that piece and we also made the paper smaller so Michael could read it on the train ..." - That video is hilarious! :rofl:

The tutorial is small and educational, but entertaining, mmm, not so much... :slight_smile:

Having said that, maybe this is the key. What if we made the tutorial into something that builds an end product, like a game. It would have to be a small game (or whatever the end product should be), but it could be done in a way where each step slowly builds your understanding of the Ren-C syntax, but at the same time you're building something fun and you get to play with it at the end.

16

I'm all for gamification. I bring up code golf because that's a game domain I am personally interested in...

I've oft-mentioned my affection for SpaceChem. Which I think is brilliant, and at its core it is a "code golf" game, just made a bit more visceral through circuits-and-multithreading-as-told-through-fake-chemistry:

The idea of the tutorial giving you "levels" and having you complete each level to get to a new one... offering you limited parts and grading you on how many interpreter ticks you used vs. how large your program is... is something I do want to do.

I'm open to us saying it's a game, but games tend to need graphics. Is there a way of visualizing Rebol-isms to where GROUP! is drawn a way, and BLOCK! another way, to teach the evaluator? Can we give puzzles that are actually running some kind of Ender's Game of the evaluator?

1 Like
17

I'm happy to volunteer as one of the writers/editor for project documentation. I'm not a programmer/developer/software-engineer and so I will need to lean fairly heavily on Brian for insight into aspects of the language design as well as other skilled contributors in this small community.

I have some ideas for gamifying a tutorial. For now I will focus on the content, framework of topics/core concepts and pull examples together (while identifying gaps) and trying a few experiments to figure an interactive approach to showcase the cool new language features. If we're using WASM (and I think we should), I envision something like an interactive kiosk with progress tracking/saving, checkpoints and perhaps some other features. If some level of graphics/sprites are available we might adjust the balance of text/reference content and boost the interactivity/graphics. This latter part isn't my strong suit, but the writing, editing and basic content management/publishing is something I can help push forward.

2 Likes
18

I've had various thoughts about this.

  1. Just try to improve the embedded help. Try help/doc default and it will take you to help pages on github where you can add to the embedded help with examples as I did there on that page. This is supposed to be a collaborative effort but not a single PR was made for it from anyone else.
  2. Take an existing open source book and rewrite it for ren-c ( eg maybe take some examples from F Jouens books
  3. Work on Carl's docs and port them but he has asserted his copyright on those so that may be tricky
  4. Take a book like Starting Forth, a real classic which the text is available, and port it to ren-c. Trouble is, although the text is available, it's in LaTeX

The problem is, if the people writing code do this, they won't have time to write code. So, people who don't write code but have a good understanding of Rebol/renc need to do this.

2 Likes
19

Here's another idea. A documentation manager collects the topics that need writing. They then break it down into chapters, or pages or paragraphs, sketches out what needs writing, and then puts it out there for people to volunteer to tackle. Breaking it up like this is a bit like square foot gardening; make it into manageable chunks for people to work on.

2 Likes
20

I'm for improving docs:
1: add sort of links in embedded help, e.g. some SEE ALSO section
2: automate making of docs from source
3: exploit existing tests to make a DEMO function

1 Like
21

@BlackATTR

I like these ideas. It gives you a framework to work from (i.e. for the type of chapters and content to include) that is known to work well. Another book to consider emulating is Automate the Boring Stuff with Python. It is very practical and keeps beginners interested by focusing on projects you will likely find in the real world.

I started thinking about books too, when I was looking at our documentation again and another idea I had was we could turn the book into an app similar to the ones UI Builder exports. It could be a single HTML file that contains the Ren-C interpreter. This would allow you to embed a console in the book, so that you could try out the examples as you read about them. The chapters would just be divs that are hidden/shown as you navigate through the book.

:boom: Modern Rebol: An Interactive Guide to Ren-C

Anyway, just throwing it out there as a future possibility. The main thing right now is just writing the content, as that is the hard part. We can figure out the rest later.

If you want to start adding this documentation to the rebol docs site then let me know, and I'll revive that repository and write up a tutorial and how to get started with that.

22

Thanks. I have that Python book, by the way-- it's a very good one.
I'm in favor of an immersive and practical approach. Don't spend a whole lot of time on the background (but link to reference material)-- cover some of basics (values, blocks, words, fns) and wade carefully into some common real-world examples.
Really like the idea of embedding the interpreter. I'd like to shoot for a form an interactive kiosk or CBT (computer based training) program, with benefits of an executable and a web site (locally searchable, printable).

You're right, ultimately there is likely to be a lot of content. My preference is to provide enough content to cover a small number of real-world examples, and not to aim for comprehensiveness at this early point. We'll work on expanding the content organically as the project gains notoriety.

1 Like
23

Documentation is something that sounds nice in theory. And certainly, following a proven formula for a book that has already worked sounds like a good idea.

But I want to be wary of following the pattern of what Rebol already did: dump a bunch of documentation on people without ever getting the motivations right...focusing on what instead of why. It's what Red is trying again, and there are things like Red by Example, which are arguably better than nothing...but still, don't give the impression I'm looking for.

I kind of want to flip the expectations here, conveying the why, and inviting people to become part of the process of helping define the what. And when it comes to the language, I don't want any selling of snake oil or misdirection. Everything should be explainable and justifiable to a computer sophisticate.

It would be better in my view to teach people one constrained dialect that they could think of as cool, and not teach them a zillion features. When they find it useful and want to explore how it's done, they will bring the motivation. That motivation should come with more curiosity than expectations.

So I'm already infinitely more on board with getting a good online workbench for using PARSE...uploading and downloading your data with drag & drop. And maybe the whole language is not taught for what you can put in the GROUP!s as code, but you get a few stock things you can do. Then, the code in GROUP!s is taught as a "bit of a black art" that is in the development stage, and people can come join and get involved in designing it.

Again, I'm talking about setting expectations that can be met. Documenting and getting people into the usage of PARSE alone is a huge project. We don't want bigger than that, and "the whole language" is going to be be bigger than that, by definition.

24

I think we're aligned. Personally I think PARSE is the most practical part of Rebol (and certainly a gateway to dialects) -- around half of the tutorial should be devoted to it. Until you get to PARSE, much of Rebol is a sort of quirky questionable language that for most devs will smack of being too clever for it's own good, i.e., being different more for the purpose of being different than being truly innovative. :slight_smile:

1 Like