Hacker News new | ask | show | jobs
by graycat 1522 days ago
> Lexical is comprised of editor instances that each attach to a single content editable element.

Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.

To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.

A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.

Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).

An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.

Uh, what is WCAG?

In what sense "minimal"?

For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found

"Markdown is a text-to-HTML conversion tool for web writers."

So, in particular Markdown is a computer program. Okay.

Again, from Google, apparently React is a JavaScript library for building user interfaces.

I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.

Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.

Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.

But I did nothing with React or JavaScript.

After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.

I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.

Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.

I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.

The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.

Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.

1 comments

I think the answer to your woes is to accept that the computing domain (while labelled by a single word "computing"), in reality is so vast that no one can expect to be a master of it all. Most of us are content to carve out our own little niche; I for one have no idea what a video adapter card is, nor how Tex works, but I have good grasp of what a content editable element is, and so on.

The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.

My view is that the bottleneck is documentation or technical writing. As far as I can tell, so far nearly all of practical computing is conceptually easy. Digging into the work on the question of P versus NP does get tricky quickly, but so far that question is not very practical, e.g., with the question and the work so far, in practice can't do much with them.

For progress on documentation, as I hinted in my post, a first step is to define terms and acronyms. A second step for a term, concept, feature, etc. is some examples.

With reasonably good technical writing, I understand quickly.

E.g., for M.2, nothing I found from Google, Bing, Amazon, Western Digital, etc. made much sense. Then I downloaded from Asus a PDF of the basic technical information on a current, high end Asus motherboard and just looked at the board "layout" -- there it was easy to see what M.2 was all about, and the information was darned explicit, sockets on a motherboard, and highly credible, an actual Asus product.

To me, in short, for the computer industry and the rest of the economy depending on it, the issue is technical writing and, there, defining and explaining terms.

E.g., React. Okay, I gave the one line Google description. React has to do with writing JavaScript code. Okay. Even though I wrote the software for a Web site, I never wrote any JavaScript at all. Microsoft's ASP.NET wrote a little for me, but for how my site's Web pages work that JavaScript seems optional. So, first cut, for now, I can f'get about React and tools for working with JavaScript. In particular, if Lexical is mostly about working with JavaScript, then, again, first cut, for now I can f'get about Lexical -- but on this point I wanted to be sure, and so far I'm not.

I'm sure good documentation, i.e. one that starts at a basic level assuming almost no prior knowledge and then gradually building on that, would lower the barrier of entry for many autodidacts. Maybe that will be the norm one day. But until then, we all find ourselves in the position where we need to quickly scan a text in order to assess if the level expertise required to understand it is within our potential grasp or not. Especially the texts that are posted here. Sometimes one might go down a rabbit-hole, google all the terms and see if it fits in with one's already acquired body of knowledge in an adjacent field, and sometimes one might find that one's knowledge actually has expanded.

Admittedly, that is the good feeling of having learnt something new. But sometimes it's just too many new terms and concepts to learn. I don't fret about it, one can't know everything. If one tries I suspect it would be a shallow understanding - except for the odd genius maybe. But I doubt it, even then.

That said, you can't go wrong with learning Javascript (Typescript) these days. It's really not hard once you've got a grasp of the basics and there is all kinds of documentation that guides even the complete novice. Writing a web-site without JavaScript at all is commendable (especially here on HN), but it doesn't hurt to know how it works.

Yup.