Re: Documentation - language default

[Sriram Ramkrishna <sri ramkrishna me>]

On Wed, Apr 4, 2018 at 3:35 PM Emmanuele Bassi <ebassi gmail com> wrote:

Mostly because "promoting _javascript_" from a documentation point of view isn't related to toolchain improvements.

Right.  That's why I wanted to ask where we were with tooling when it came to _javascript_.  Christian and I have had some discussions especially around the toolchain so I'm not unaware of this particular bit of feedback.  Like you, I agree that resourcing development around the toolchain is an important part of the effort.
 

The people that can write documentation are not the ones that are going to hack on

 - the documentation platform

 - the JS engine

 - the plethora of tooling necessary to work and debug applications

I concede all of this.  But I have volunteers to deal with the documentation platform, but not the js engine or the tooling.
 

Even with the first item we've failed. We've had, what? 4 or 5 documentation hackfests in the past 5 years, and all of them have a line item about having better documentation platforms for our *C* API reference.

I really don't want to take a dig at anybody at the DX and documentation hackfests — they are all volunteers and they work *really* hard. The job is daunting in the best case scenario of somebody actually paying for this stuff; that we have documentation already is kind of a miracle.

Documentation that sadly has not kept up and I suspect we have all kind of new ways to write applications.
 

Since this conversation could easily get derailed,

That's probably the understatement of the year — *but* I think we'd be better served by actually going a bit deeper than just "let's evaluate a single language for our platform".

I tried to not focus on that aspect.  I failed.  I wanted to see where we were at on which language has the most mature tooling and it seems that we are behind on everything.  Unfortunately, if we are going to want to progress the platform forward we are going to need to figure this out as a long term solution.

Everything is connected.
 

 

what I would like to focus on is using _javascript_ as the default computer language for developing 3rd party apps on the GNOME platform.  We would like to validate what the current state of _javascript_ is for writing applications and whether we now have good support in flatpak, debugging toolchains (eg gjs and builder) and other factors we might have not considered but should be identified.

What does "validate" mean? You want to write an application? What kind of an application?

What does "good support in Flatpak" mean?

What does "debugging toolchain" mean?

More importantly: what are you planning to do if you find issues?

All great questions and exactly why we put all this out there before getting ahead of ourselves.

 

Let's say that _javascript_ fails to clear some arbitrary bar you defined — and I'd really like to see how you define these bars to be cleared first — what are the contingencies? Launch a D20 and choose another language?

We haven't set a bar, we're basically trying to create something that would work in an interim until we can figure out what the long term approach is.  I'm not accepting status quo.  One has to start a movement in order to excite others enough to work on the other parts.

 

Any input in this regard would be well appreciated to drive good documentation to write applications for the GNOME platform.

While good documentation is a necessary stepping stone towards a decent SDK and application development experience, it's nowhere near sufficient.

You can have the best documentation in the world — but if you don't have people working on the tooling and the actual integration between the language and the platform, then you don't have anything that other people can use.

I think we're on the same page.  I'm not looking at documentation as just documentation but one part of a set of things that needs to be done.  After all, I've spent time trying to do a conference around application development and have learned quite a bit from that endeavor.

So to be clear, I am not accepting status quo because wrong and out of date documentation is worse than no documentation and right now.  We are expending a lot of effort in things like flatpak/flathub/atomic workstation that needs a platform that caters to everyone.  Secondly, to reach the desired end will require many moving pieces, none of which can be done in a vacuum.

As for the other languages, you had made the suggestion on IRC of approaching each of those communities and create ties with each of them similarly to how we have with Rust.  That seems like another effort that needs to be analyzed.  I'm not afraid of going to each of these communities and engaging them.  But we need a good argument on why they would care.

Great discussion thus far.  Thanks for keeping it high signal, low noise.

sri

--

https://www.bassi.io
[@] ebassi [@gmail.com]