DEV Community: Lance Bachmeier

Learning JavaScript II

Lance Bachmeier — Fri, 23 Oct 2020 14:53:14 +0000

I'm learning JavaScript 30 minutes at a time...

I posted my program from last night on Gitlab in this new repo.

My program doesn't do much, and it's obviously not useful to anyone else. It shows you what I learned in the bit of time I put into it last night.

It (sort of) lets you move between two divs, with a box around the active div, using the up and down arrows. You can indent the active div (when it works) with the right arrow. That's it. As I said, it's definitely not anything useful at this point.

It's interesting to me the way you can manipulate the dom. My end goal is going to be an outliner type of notes app with these features:

Do quick outlining.
Add and edit text entries.
Indent/outdent text trees (a text entry box and all of its children) using the keyboard.
Rearrange text trees using the keyboard.
Markdown support for text entries, including math.
Save the current state to a file manually as a new html file.
Optionally, run a local web server, which would make the saving and loading more convenient.
Use a version system to determine if the current version in localStorage is newer than the version I'm loading from file. I think timestamps will work for this.

I want to be able to add a quick outline to a repo without a lot of ceremony. With everything in one html file, all I'll have to do is load that file into the browser and start typing. As I said earlier, I probably won't actually use this for anything, but I will learn a lot by implementing these features.

Learning Javascript

Lance Bachmeier — Mon, 19 Oct 2020 14:23:20 +0000

I haven't posted anything on here in a long time. It should come as no surprise that the pandemic has eaten up a big chunk of my schedule. I was overbooked prior to the pandemic. The need to move two classes to a new format, and learn and incorporate into my teaching new forms of technology, has been challenging.

Act I

Last week I dug up an old script (from 2018?) I had written while deepening my Javascript beyond the occasional copying of a few lines of codes off the internet. It was a static page generator contained entirely in one html file, requiring no server, no command line interaction, nothing but the single html file. You enter text into a box on the screen in markdown format (complete with equation support). There's a live preview below the text entry box. When you're done, you click the button and download it to your computer. I'm pretty sure the goal was to have something that could be directly uploaded to a Github repo for display on a Github Pages site.

I'll post a link when I make the html file publicly available. It still needs a little cleaning up, including the removal of personal information, before I can share it.

Act II

Over the weekend I decided to get a better understanding of modern web development by figuring out how to write a single-page web app. I was largely familiar with old school CGI apps. They're dead simple. You can learn all the "server" parts in 20 minutes. You then return text output based on the URL. CGI programming is just regular programming with external data.

Considering that I'm not a web developer, that's more than I need to know. My curiosity tends to get the best of me, however, and I had no choice but to figure out how to write a web app that communicates with a server but never reloads the page. So I set out to write one of the single page apps that can be used to manage a directory of markdown files and a few other things inside a repository (Git, Fossil, or otherwise).

I wrote the backend in D using Adam Ruppe's cgi.d. In spite of the name, it has an embedded http server that can be run locally to respond to requests on the local filesystem.

The frontend (I think that's what the kids call it these days) is in Javascript. I learned about fetch, which is both simple to use and beautiful in the functionality it provides. I had heard of fetch before but it was limited to copying a single line of code from a stackoverflow answer. I used URLSearchParams to create a URL that can be used for a GET request. I learned async and await to deal with promises. In the end, I had some functionality working. I had a sidebar with a listing of all files, could display and edit existing files, create new files, and preview files.

While this is functional, it doesn't do anything more than I can do better with various other tools, including a basic text editor. As a learning exercise, it was successful. As a tool, it provides no value at all in its current state. I just want to be clear on that last point because tool creation was not my goal over the weekend.

The project will continue. Some of the things I will do include:

Figuring out XMLHttpRequest, which seems to be powerful but not as easy as fetch.
Understanding promises.
Adding tag support to allow easy querying of all files in the repo with that tag.
Adding backlink support to query all files that refer to the current file. I'm not sure how useful that will be but it should be easy to implement and experiment with.
Saving to localStorage and allowing recovery if the browser gets closed.
Add file metadata support so I can add a description of arbitrary length to be displayed with individual files.
Add a "timeline" where I can quickly enter project updates. One problem I have with Git repos is that there's no standard way to post updates. When I return to them later, I can't easily figure out the state of the project.
Add an "inbox" to note things that need to be done or issues. This would differ from the timeline in that these posts would need to be queried, grouped, and archived.
Rewrite the Javascript parts in other languages that compile to Javascript. Strictly speaking, there's nothing wrong with JS as a language, but there's also not much that makes me enthusiastic. I'd describe it as a "vanilla" language that does the same things as other languages but not providing anything that reduces the pain of programming. In that sense, the "Java" part of "Javascript" fits even if they are unrelated.

Everything will be handled in text files - no database. Standard Unix tools such as awk, sed, and grep provide the database functionality I need. My repos are small (a few hundred files at most). The advantages of no dependencies and having text files under version control with no overhead far outweigh any possible advantages of a database.

This remains a learning adventure. If I end up with a tool customized for my workflow that I use in the future, that's a bonus. I probably won't use it when it's written. That's okay with me.

Edit: It looks like I've played with ClojureScript in the past. I posted about it here. I don't have any recollection of that, and rereading the post, it looks like I didn't spend much time with it.

org-mode quick start

Lance Bachmeier — Mon, 25 May 2020 15:19:28 +0000

Someone on Hacker News made this comment

A few simple observations:

the venn diagram of people using emacs and using org-mode seems to largely overlap. That makes it impractical in non emacs heavy environments (aka. the wider industry).

tooling outside of emacs is mostly not there.

org mode is a basically similar to other wiki dialects with similar syntax, limitations, tooling, etc. Other than the (emacs) tooling, I don't see a strong reason for preferring it.

The above makes it a non-starter for me personally (not an emacs user) or for teams that have non emacs users (i.e. all teams I've been on, ever). That does not invalidate it as a personal note taking tool of course. But lets indeed not overstate its utility. Some people like post-its, scribbling in a notebook, simply remembering to do stuff, or their super duper emacs setups. Whatever works for you.

I thought it would be worthwhile to elaborate on my reply here. I think it's a myth, promoted by Emacs users, that you have to engage in extensive customization and memorize many weird keyboard shortcuts, in order to use org-mode. That's very wrong. Anyone that uses a computer can use org-mode in Emacs.

org-mode is available by default. That means you only need to open a .org file in Emacs and all of org-mode is waiting for you. It may not be well known, but Emacs has a menu bar. You can click to open a file as in any other GUI program.

Wiki-style hyperlinks without a browser and web server. Hit C-c C-l and it will prompt for the link and description. If you want to link to another .org file, remember to add the path, as in ./anotherfile.org. To edit the link, use the same shortcut. To open anotherfile.org for editing, click the link. None of this is hard. Indeed, this is as easy as any self-hosted personal wiki solution I know of. It's unclear how it could be any easier in the absence of reading your mind.

A full-blown outliner. If you want a top-level heading, start the line with *. If you want a second-level heading, start the line with **. And so on, as deep as you want to go. You can add notes to an item by typing below the heading. You can hide the notes by hitting Tab on the heading. What's really powerful is the ability to move subtrees around using Alt plus arrows. Left and right change the level of the heading. Up and down move the entire subtree up or down. If you want to get REALLY FANCY, you hit Shift along with the right and left arrows to cycle through marking items as TODO, DONE, and unmarked.

I've just outlined a tremendously powerful knowledge management system. I provided one shortcut for hyperlinking. I talked about the Alt-arrow combinations for outlining. I talked about Shift-arrow combinations for TODO functionality. I challenge anyone that reads this to leave a comment demonstrating another system that does all that but with a significant reduction in complexity. No such system exists, because it's close to the lower bound on complexity.

FOSS and Entitlement

Lance Bachmeier — Mon, 20 Jan 2020 15:58:28 +0000

Another day, another discussion of entitlement on Hacker News. This time the post that drove the discussion is My FOSS Story.

Let me say that I know nothing about the author or any of the background behind the post. My comments are general in nature. The biggest problem is inappropriate expectations of open source project maintainers.

The author of the post writes:

I've seen or experienced this in FOSS in a number of different ways:

You should put out a new release.
You should rewrite this in [insert programming language here].
You should rename your project.
You should [insert major architectural change here].
You should change the license of your project.

That apparently bothers the author. I don't understand why it matters. Of course people are going to request/suggest things. If you don't like what they're asking you to do, just ignore it, or even better, answer that you've open sourced your project so that you can incorporate pull requests.

Anyway, I don't really understand what this has to do with "entitlement". If you put your project out there for the world to see, you're inviting comments, feedback, and shoulds. If you don't like it, don't share your work.

Later on, he writes "At some level, even the act of opening a bug is a form of entitlement". Of course it is. That's why the dang bug tracker exists. The author even says that in the very next sentence. Evidently the complaint has nothing to do with entitlement.

My suggestion (or "should" if you want to use that term) is to be very clear on the project site what limitations there are. If you don't want feedback, state that clearly. If you don't want bug reports, state that clearly. Even better, make a release and tell the world "this is complete, take it as it is, I have no plans to make changes to this project". It's my opinion that you should normally release open source code without any promise to evolve the project or to do any more than basic maintenance. The real problem in that post is that the author is experiencing burnout. He's spending a lot of time on things he doesn't want to do because he doesn't see them as valuable. He should step away, or at least be clear as to the things he's going to work on, and let the community take care of the rest.

Does It Make Sense To Prefer A Text Editor?

Lance Bachmeier — Fri, 11 Oct 2019 13:21:09 +0000

I've always had a preference for using a text editor like Emacs or Vim rather than a program like MS Word or Evernote. I'm not the only one; millions of others use text editors by choice and complain when it's not an option.

This confuses a lot of people. They just cannot wrap their minds around the idea that someone would prefer a primitive text editor over a fully evolved GUI program like MS Word. Someone even asked me once, with a disgusted/shocked look on his face, "Why would anyone use that?"

I have an answer to that question on my website:

The vast majority of people do not use text editors like Emacs. They'll use MS Word, Google Docs, and the like. In contrast, I try to avoid those apps as much as possible. I'd much rather use Emacs in the terminal. This is not because, as many people might assume, I'm old and don't understand how to use technology. Over time my workflow has evolved in the direction that provides the greatest productivity, and for me that has been away from Google Docs and toward text editors. There are two reasons a text editor in a terminal makes me more productive. (I make no claim that this applies to others; you should use what works for you. This works for me.)

Text editors are designed to support a full workflow without a mouse. This is one that I never understood until I was trying to understand why I was so much more productive when I avoided using the mouse. Text editors allow you to do everything with the keyboard. A mouse distracts you every time you use it. No matter what you do, the mouse will be in a different position the next time you use it, the cursor will be in a different position on the screen, and you will be doing different things. You can never automate the use of a mouse no matter how many times you use it. You have to think about it every single time, every time you save the document, select text, or scroll to the start of the document. The keyboard never changes. You quickly adjust to the keyboard shortcuts associated with a task, and you can do it without thinking about it. I'm able to think much more clearly when I'm typing in a non-GUI text editor because I'm not subject to the constant distraction I'd have if using a mouse. Many writers have moved to markdown, and I think that's because you don't have to leave the keyboard to write a fully-formatted document.

Text editors make it easier to focus. A text editor is a minimalist app. You don't worry about formatting. You just write. There's no way to procrastinate when you're looking at a terminal with no formatting options other than what you put into the text. The content is all you have. You get it right if you can't make up for weak content by making your document look nice.

This doesn't say anything about the ability to customize the heck out of your text editor to do everything you want it to do. I haven't mentioned that because text editors vary in their support for customization.

Customizing Emacs for Editing org Files

Lance Bachmeier — Tue, 08 Oct 2019 02:50:45 +0000

My preferred way to use Emacs is to open it to edit a particular filetype with a custom init file. Most commonly, this is a .org file that I'm opening with a script. The primary advantage of using a custom init file is that you can optimize Emacs for one type of file without causing conflicts for other modes. Emacs is almost unusable in its raw form. Duplicating a line requires this mess: C-a C-SPACE C-n M-w C-y. Obviously, nobody wants to deal with that. It's easier to select, copy, and paste the line than to type that - assuming you can even remember it.

I open .org files with a command like this:

emacs -q -l custom.el foo.org

This opens file foo.org using custom.el as the init file. Inside custom.el are the lines:

(setq inhibit-startup-screen t)
(global-set-key (kbd "C-c x") 'org-cut-special)
(global-set-key (kbd "C-c c") 'org-copy-special)
(global-set-key (kbd "C-c v") 'org-paste-special)
(cua-mode t)

The first line makes Emacs open without the annoying startup screen that for some reason opens by default no matter what. You'll go crazy if you have to deal with it every time you open a .org file, so get rid of it. Lines 2-4 make it possible to cut, copy, and paste items in your outline. This is really handy for moving content around. Line 5 is by no means necessary, but I always forget which of C-w and M-w is copy and which is paste. cua-mode gives copy, cut, and paste the normal shortcuts of C-c, C-x, and C-v.

This minimal configuration file is sufficient to make me extremely productive editing .org files that contain project information, checklists, and any other information I need to track.

Pandoc TOC without standalone mode

Lance Bachmeier — Fri, 13 Sep 2019 02:44:08 +0000

This is a specialized post that very few people will find useful. But since it's not something you can easily find by searching, I'll make it available to anyone else in my position.

I wanted to add a table of contents to a document in Pandoc, but without standalone mode - something that is not possible. However, you can just use a very minimalist template called something like blank.html:

$toc$
$body$

That's it. Then this

pandoc -s file.md -o file.html --template=blank.html

is just as good as not using standalone mode.

D Interop with C++

Lance Bachmeier — Sat, 07 Sep 2019 01:34:10 +0000

D continues to carry C++ interoperability forward more than any other language. I've not dug into it at all, but the latest additions allow you to work with C++'s std::vector and std::string in your D code. Various other libraries let you work with std::allocator and the C++ new operator.

Scripting with Textadept

Lance Bachmeier — Fri, 30 Aug 2019 15:44:47 +0000

Yesterday on Hacker News, someone commented

Other editor users simply have no concept of how easy it is to whip up some quick script to perform some task in emacs.

I think many Emacs users have this view, and as a long time Emacs user, I love the ability to write libraries of functions and interact with them from a text editor. Unfortunately, it's not an accurate statement. Other text editors do have that capability. Textadept - probably influenced by Emacs - is one that I've used extensively as a frontend for a programming language. This was my response

I don't want to start a flamewar, but I moved most things I was doing in Emacs to Textadept a while back because I found Textadept more convenient. That's not to say TA does everything you can do in Emacs, but it replaced all of the scripting I was doing with Emacs.

You have the full power of Lua inside TA. Emacs always has a lag when I start it up, whereas TA is instant. I slowly built up functionality inside TA to the point that I realized I could replace everything I was doing in Emacs.

It's so small and lightweight that, just for fun, I wrote a "web browser" inside TA. It calls out to lynx and loads a readable text version of the page. I use a keyboard shortcut to open links. I have functions for searching the web, I can search YouTube and open the videos in VLC, and so on. This was a practical thing to do: I can use TA as a browser on really old laptops.

It maybe isn't for everyone, but in Emacs when I was doing this[1] to duplicate a line:

C-a C-SPACE C-n M-w C-y

I asked why I wasn't using a better text editor. In TA, it's C-d. Just as Emacs is an interface for Emacs Lisp, TA is an interface for Lua, and with a lot less overhead.

[1] https://stackoverflow.com/questions/88399/how-do-i-duplicate...

That last bit wasn't important from the perspective of scripting. (But it's correct - Emacs is not a lightweight text editor, and you can end up going down rabbit holes when you try to change a key binding, unless you're willing to accept verbosity. Textadept, by just being a text editor out of the box, doesn't have that problem.)

I might post more on this topic in the future, but let me give you an example of one customization I've done with Textadept. First, some background on my workflow so you understand what I need to do. I have a lot of information flying at me during the day: a link I come across that is not of any particular use right now but that may be useful in the future, a few pieces of reference material someone sent me for a service project, a request for a meeting, an example that came to mind randomly that I want to incorporate into tomorrow's lecture, a minor comment from a coauthor about a problem with one of the figures in our paper, a clarification on a rule for the graduate program. It's an unending stream of a few big items and a lot of small items.

There's simply no way I can properly organize the several dozen of these that come along each day while I'm working. After trying many different solutions, what I found works best is a file called capture.txt where I know everything will be safe until I have time to review each item, make a decision about what needs to be done, and take appropriate action. There's no time or mental energy available for an elaborate system while I'm working. I need to enter a few keystrokes and start typing.

So, how did I implement this system in Textadept? The first thing I did was add a menu item for opening the capture file if it's not already open. (I prefer a menu item because I don't do this task often and the cognitive overhead of a menu item is lower than a keyboard shortcut or calling a function.) I added this in the menu.lua file:

{_L['Open Capture'], function() io.open_file(_HOME .. "/capture.txt") end},

Upon restart, which is instantaneous, I had a menu item to open that file.

Just having the file open isn't enough. I might be in the middle of the document when a new item comes in. I wrote a function that moves to the top of the document, adds two line feeds, and moves the cursor to the beginning:

function new_capture()
    buffer.insert_text(0, "\n\n")
    buffer.goto_pos(0)
end

The 0 in the first line of the function body tells it to insert that text at the start of the document. The second line moves the cursor to the start of the document. I could have called that function by hitting Ctrl-e and typing

new_capture

That's inconvenient, so I bound that function to Alt-i (for insert). In my init.lua file, I added

keys.ai = new_capture

Now all I have to do is hit Alt-i and start typing.

I quickly discovered that isn't a complete solution. If I just type, I'll soon have a file that's a big wall of text, and it's not easy to work with something like that when I'm processing everything at the end of the day. That led me to resist the processing, and the system's a failure if I'm not doing the processing on a daily basis.

The solution is to start each item with an identifier so I know what I'm dealing with. If it's a task I need to do, it starts with %task. If it's a note, it stars with %note followed by a timestamp, which I've learned is often useful information. I have several other identifiers that may change from time to time.

For notes, I have the following in my init.lua file:

snippets['n'] = '%%note ' .. '%<os.date("%x at %X")> '

To enter a new note with a timestamp, the total work I do is:

Hit Alt-i to make space at the top of the file for the note.
Hit n followed by tab to insert the snippet.
Get all the information out of my head.

The snippet puts something like this:

%note 08/30/2019 at 09:53:54 AM

Of course you can do any of this with Emacs. The point is that you can do it in Textadept just as well, or even easier, and you might prefer a lightweight, extremely performant editor. It's not the case that you have to use Emacs to get this functionality. Anything you can do in Lua (which is a heck of a lot) or by calling out to a command line program (which might be written in Emacs Lisp) you can do in Textadept.

"Don't Rewrite Code" is bad advice

Lance Bachmeier — Thu, 22 Aug 2019 19:32:10 +0000

I have read many times the advice that you shouldn't do a rewrite of a working program. I think the idea was popularized many years ago in a blog post by Joel Spolsky. That's probably reasonable advice for a million-lines-of-code program you're using in production. It's bad advice when your programs is only a few thousand lines. Here are a couple of reasons rewriting code is a good thing.

Freedom to rewrite makes you more productive. If you know in the back of your mind that you can do a rewrite if it doesn't work out, you won't try to engineer a perfect, general solution on the first go. The critical step is writing a working program, complete with tests, that does exactly what you need it to do. You want to silence the voice in the back of your head that keeps asking, "What if I decide to add X in the future?" Once you give in to that urge, you'll be going down rabbit holes and spending long hours engineering solutions for problems you don't have.

Rewrites are cheap. Your time, on the other hand, is not - don't waste it writing programs that don't provide an immediate return.

You can rewrite and test a lot of code quickly. I can knock out a lot of (fully tested) code in a couple of hours if I'm doing a rewrite. I can reuse much of the earlier code, and once I understand the logic, I can do a much better job. And it can be hard to write good tests while you're trying to define the problem. When you start a rewrite, you know what you're trying to accomplish, and that makes it a lot less challenging (and faster!) to write good tests.

Messing with ClojureScript

Lance Bachmeier — Thu, 15 Aug 2019 14:12:23 +0000

My usage of Javascript has been limited to copying and pasting a few code snippets from the web. I don't do much web development, and when I do, I normally use CGI with D. JS does offer some big advantages, however, like not requiring a running web server.

The main reason I haven't learned JS is that I don't like it. That's not due to flaws in the language - though like any language, those exist - it's purely a matter of preference.

I worked with Clojure years ago, but didn't really have a good use for it, so I set it aside and never returned. ClojureScript has some appeal because it allows me to write Clojure rather than JS. So last night I checked it out.

I went to the website and found a "Quick Start" page. The first thing I learned is that this isn't really true:

If you are using macOS or Linux the only dependencies required for the main part of this tutorial are a web browser and an installation of Clojure.

You actually need an installation of Clojure as described at that link. It doesn't work if you install Clojure using your distribution's package manager.

I then created several directories and the two files. I was left guessing which was the directory to do the compilation, so I tried the one with my source file (that seemed natural coming from the C world). Nope. I had to go to the top directory and do it from there.

After a while, a browser tab opened and I waited for something to happen. Nothing happened. For some reason, an html file that does nothing gets opened. I returned to the terminal. I could type things in, but this was in no way different from just running a Clojure repl. At that point, I was done with my "quick start". I didn't feel I got started on much of anything, because I hadn't replaced JS with Clojure (the whole reason I tried ClojureScript). So I decided to look around for a guide that might show me what to do. There are a lot of links, but there was really nothing that helped.

I searched for ways to call Clojure functions from JS, and it pointed me to this answer on SO. From there, I went to this documentation page. I used that information to export my Clojure functions, compiled a Clojure library, and called those functions from html using something like

<button onclick="console.log(hello_world.core.average(3.4,7.8))">Click me</button>

I think part of the problem is that I don't know JS, so none of this was obvious to me, and evidently the standard use case for JS is something other than creating functions to be called from html when you're clicking buttons. It can be frustrating when you see others writing about how good ClojureScript is, but you can't even figure out how to do basic things.

There are very few cases where the language choice actually matters?

Lance Bachmeier — Mon, 12 Aug 2019 02:43:48 +0000

The title is a reference to this blog post. The author writes

Before I talk about how I evaluate languages, I want to make something very clear. There are very few cases where the language choice actually matters. There are things you can obviously not do in some languages. If you write frontend code, you don’t get a language choice. There are also specific contexts where performance is important and X language just won’t do, those situations are quite rare. In general, language choice is usually one of the least important issues for a project.

I strongly disagree with this statement in general. Of course there are many cases where it is true, but as a general statement that every developer should learn, I don't think it's anywhere close to correct.

I would say that one of the most important things you can do is choose the correct language. Here are some things that you do need to take into account when you're working on a software project:

What are the performance requirements? This is not limited to the small subset of programming problems, like high frequency trading, where you need to squeeze every ounce of performance from the processor. Is the interface responsive? Will the program scale? Can I write in an idiomatic style, or do I have to resort to things like vectorization, which destroys readability and is hard to do? Performance concerns are not as big as they used to be, but they are not rare. Jeff Atwood had a few things to say about performance a while back.
How am I going to model the problem? Sometimes a functional approach is best, sometimes an OOP approach is best, and sometimes you just want to write a quick script. Haskell's not the right choice for an OOP program. Java's not the right choice for a script. But it's more than that. We resist doing things that our language doesn't do well. We limit our projects to the things we can do easily in the language we've chosen to use.
Which libraries do I need? Not all languages have equal access to libraries. Even if they exist, they might not be complete, they might not be supported, they might not be documented well, or they might be awkward to use. Poor/nonexistent library support can sink a problem or require a costly rewrite.
What parts of the ecosystem have to be strong? If you prefer using an IDE, some languages are better choices than others. If you run into trouble, is there a community that can help you? Is there good documentation to guide you to do what you need to do?
Which languages are fun to use? Nothing can kill your motivation like having to use a crappy language. If you dread the thought of open the project up because the language sucks, I can say with certainty that you will be less productive. If a language is fun, and you enjoy learning about it, you will leave for the office 30 minutes early and stay 30 minutes late at the end of the day.
Which languages do you know well? Do you need to hire others to work on the project?

It's surprisingly common to see people say the choice of language is unimportant. I find that argument to be bizarre. You wouldn't expect a mechanic to say "The choice of tools is not important. If all you have is a hammer and a socket set, use that." If you ordered an Uber and the driver showed up in a Kenworth T800, it's not likely that you'd think "The choice of vehicle isn't important. All we need is a tool to take me from my house to the airport." Sure, you'd have plenty of space for luggage, but it would not seem to be an unimportant implementation detail. And you wouldn't say the choice of spouse is an unimportant detail so long as they are capable of carrying out the spousal duties.

No, the choice of language matters, and it matters a lot. I won't speculate on why someone might claim otherwise. It is an observation that conflicts with my experience.