m48

Obviously bundling nearly all of Chromium with an app is inherently inefficient, but out of curiosity's sake, has there been any objective analysis of exactly what makes this use a seemingly disproportionate amount of resources? Are JavaScript runtimes inherently inefficient? Is it Electron's node.js part? Is it the huge amounts of code needed to parse and render HTML and CSS? Is it the multimedia features, like WebGL and the video and audio players? Is the problem actually just badly written code running on top of Electron? And if so, what exactly are are most Electron apps doing wrong that one could avoid? Is it, as this blog post seems to suspect, that they aren't sufficiently taking advantage of Electron's node.js integration?

In addition, once the actual bottleneck has been identified, doesn't this open the door to fix things on the WebKit/Blink engine side of things? Before, when Electron was managed by GitHub, one could say this would be unreasonably difficult, but now that GitHub is owned by Microsoft, isn't tweaking Blink to be more suitable for deployment environments outside of Chrome exactly the type of thing they would have a vested interest in doing, and the resources to actually pull off? After all, with VS Code, they are one of the highest-profile Electron users, and using Blink in Edge presumably involves working with the Blink code to some degree anyway.

It's always struck me that a lot of Electron apps likely never use a single line of WebGL, while a lot of WebGL apps likely only use DOM APIs to pretend the DOM doesn't exist by plastering everything in a huge <canvas> element, and both likely don't want their binaries to include the Chrome devtools, but Electron includes all of these things anyway. I'm not sure how much space or resources it would actually save, but is Chromium/Blink refactoring their code and build process to facilitate Electron building different Electron "profiles" that include different sets of features even remotely a possibility?

Oh, I never noticed that. That's pretty interesting—although unfortunately, that syntax does not look terribly convenient to write, which is the main thing I'm after here.

I think the best way to get identifiers with whitespace to work in a Lisp would be contrive a syntax for S-expressions that uses something other than whitespace to separate things. Perhaps letting (first rest-1 rest-2 ...) be written as as (first: rest 1, rest 2, ...) or (first, rest 1, rest 2, ...), so that example could be written as:

  (let: ((first number: 10), 
         (second number: 20)), 
        (+: first number, second number))

Well, thinking about it more, I did realize there's a pretty nasty edge case with my hypothetical JavaScript syntax:

  let let x = 5;
  let x = 6; 
  // should this set the variable "let x"?
  // or define a variable named "x"?

I think the idea is worth experimenting with, though, and that a good implementation of it could be convenient enough for end-users to outweigh the implementation inconvenience.

Does one actually need whitespace to separate identifiers? This is something that's always bugged me a bit.

Aside from C-style type declarations ("unsigned int x;"), C-style syntaxes seem to always have ways other than whitespace to separate identifiers.

Like (using some JavaScript in a hypothetical example) I can't think of many concrete reasons why this is easier to parse:

  let first_number=2, second_number=2, answer=first_number-second_number;

  let first number=2, second number=2, answer=first number-second number;

I was always under the impression this program was a level editor made primarily for use with for the author's Clean Game Library [1], a game engine for a functional programming language named Clean [2]. I haven't used either, but maybe people into functional programming will be interested in studying a working game engine made in a functional programming language back in 1999? [3]

As for interesting features the program offers on its own… it has a pretty decent integrated graphic editor for tilemaps [4], and uses a template language for defining the output format instead of providing a generic parsable file format [5]. It also appears to abstract away layers by making each tile in your map consist of a "front," "middle," and "back" tile [6]. In general, it seems like a more old-school version of Tiled, and may be useful for people developing for/on older systems that want a very lightweight tilemap editor.

For people used to programs like Tiled, though, there's probably no compelling reason to switch to this tool. The lack of a working undo function in the map editor could be a dealbreaker, for one.

[1] http://cleangl.sourceforge.net/index.php

[2] http://clean.cs.ru.nl/Clean

[3] http://cleangl.sourceforge.net/thesis/

[4] http://tilestudio.sourceforge.net/drawing.html

[5] http://tilestudio.sourceforge.net/tutor.html#CreateTSD

[6] http://tilestudio.sourceforge.net/tutor.html#MapEditor

A quick explanation of what this is, because it took me a bit to figure it out: it appears to be an interactive fiction engine written in Clojure. The linked example game is running through ClojureScript in the browser, but the engine also works in the terminal.

Here's a quick link to the main code file defining the rooms and actions for the example game: https://github.com/facundoolano/advenjure-example/blob/maste.... I doubt I'm the only one that likes looking at this type of example first when looking at an interactive fiction engine, and it may help some people confused by the game.

The history of interactive fiction and Lisp is surprisingly intertwined. To the best of my knowledge, all of the original Infocom games were written in ZIL [0], an idiosyncratic Lisp variant that was meant to be a more portable version of the programming language used to write the original mainframe Zork, MDL—which was apparently designed by some of the same people who worked on Scheme and Common Lisp [1].

There appears to be an active but still incomplete open source compiler for ZIL written in C# [2], and a few Common Lisp experiments, but not many mature projects combining interactive fiction and Lisp.

I hope projects like this one catch on more. I've had trouble grasping other interactive fiction engines, which I often feel are trying to please programmers and writers but hitting an awkward space in between. Lisp's "code is data" idea seems like it could be a more graceful way of hitting that balance.

[0] http://www.ifwiki.org/index.php/ZIL

[1] https://en.wikipedia.org/wiki/MDL_(programming_language)

[2] https://bitbucket.org/jmcgrew/zilf/overview

Started screwing around with a limited version of Visual Basic 6 when I was 8 or 9. I had always liked the visual design of computer programs, so the programming was sort of a means to an end to make cool GUIs.

This limited Visual Basic had most of the features of the professional edition, except you couldn't distribute compiled programs (only run them in the editor), and they took out all the help files for some reason. I got pretty used to having to forage on my own to find decent documentation for anything, relying on computer manuals from local libraries and tutorials from random sites to fill in the blanks. I'm not really sure why I had the patience to put up with that, to be honest. I think I just assumed everyone learned programming like that. I pretty much never met another person who knew anything about computer programming face-to-face until I went to college.

When I got tired of not being able to compile anything, I ended up experimenting with Visual Basic.net in a beta of Visual Studio 2005 a relative gave me, had a bad experience with that, and started looking for alternatives. Eventually, I basically settled on Python.

I still think Visual Basic 6 is one of the best programming environments ever made. It started in seconds, the GUI designer just worked, and the autocomplete was perfect. It even opened up with a blank project you could start screwing around with without even saving anything, encouraging a lot of experimentation with the widgets and language. It was QBasic for a different generation. :(

I've looked into it a bit. The answer appears to be… sort of. It depends on your definition of "modern," how many hoops you're willing to jump through, and which dialects of Lisp you're willing to use. These are some of the more promising options I found.

For Common Lisp, one of the longer-lasting and best supported options appears to be CAPI, which comes with LispWorks (http://www.lispworks.com/products/capi.html), but that costs a grand and is not open source, so that's kind of out of the picture for most people. If you're looking for commercial option that will just work, though, this might be worth investigating. (They seem to have recently released a "hobbyist" version that is only $500, but you can only use it for "non-commercial and non-academic purposes," so I'm not really sure how useful that is.)

Ceramic (http://ceramic.github.io/) lets you use Common Lisp to make desktop web apps using Atom's framework (http://electron.atom.io/). While that comes with all the disadvantages of making desktops apps with HTML+CSS+JS, it seems to be one of the more professional and easier to set up options.

If you're using a Java implementation of Common Lisp, such as ABCL (http://abcl.org/), you can presumably use any Java GUI framework. I've heard, however, that using Java libraries is significantly more awkward in ABCL than, say, Clojure, and that you might need to write some Java code to bridge the gap. The main attempt to get that to work I've seen appears to be this framework ( https://common-lisp.net/project/snow/ )—I'm unaware of any applications actually written like this.

Clozure CL (not to be confused with Clojure) has bindings to Apple's Cocoa framework (http://trac.clozure.com/ccl/wiki/CocoaBridge). Apparently there's a fairly battle tested cross-platform implementation of Cocoa that you can use to make it run on Windows and Linux too, but I'm having trouble finding a link to that right now. I think it was the framework used to port Comic Life to Windows, if that helps. Regardless, though, this sounds like a pretty scary option for someone without prior Cocoa experience.

Most of the more practical looking options I found seemed to be for Scheme.

Racket (https://racket-lang.org/) comes with a GUI toolkit that was originally forked from wxWidgets. The IDE is built in it, among other things. It has some quirks that wxWidgets doesn't, though—for example, all the widgets are native except for all text entry controls, which makes accessibility… interesting. (Also, on my computer, at least, they don't quite cooperate with high DPI displays.)

Chicken Scheme apparently has good bindings to IUP (http://wiki.call-cc.org/eggref/4/iup, http://webserver2.tecgraf.puc-rio.br/iup/), a fairly lightweight framework that uses native widgets on Windows and Motif/GTK on Linux/Unix/OS X. I wouldn't really call it modern, but it does look fairly convenient—the Scheme API seems to basically let you define GUIs in structured s-expressions (http://wiki.call-cc.org/iup-tutor#porting-some-examples-from...). (Also, I'm pretty sure it does support Unicode, and that the IUP site is just out of date.) This is the option I'm leaning towards learning.

Kawa Scheme runs on Java, providing the same benefits as ABCL, but it seems a little more battle tested, and provides native support for making Android applications (http://www.gnu.org/software/kawa/Android-view-construction.h...). It's used to, among other things, power MIT App Inventor. (You can actually unzip App Inventor projects and find Scheme files inside, which is kind of fun. I kind of wish the App Inventor team would make the framework more accessible from Scheme. :p)

And, of course, if you're willing to settle for dialects of Lisp more distant from Common Lisp or Scheme, you can use Hy and any Python GUI framework (http://docs.hylang.org/en/latest/), or Clojure and anything Java.

Hopefully there are some good ones I missed, because Lisp-like languages seem like they would be pretty cool for GUIs.

This may not be completely acceptable, but I swear by Mempad (http://www.horstmuc.de/wmem.htm). It's not open source, but that isn't a huge deal breaker for me, since it can import/export human readable text files very easily, and its file format is really simple. If I ever needed to convert my thousands upon thousands of notes to a different format, I could probably write a program to do it an hour, and most of my work would be writing the new format. Most of the open-source programs I looked at didn't make getting to my data that easy. (Plus, since I use speech recognition for everything, I can't get picky about source availability. Anything that uses non-native widgets is almost entirely unusable for me, so I can't use anything that uses GTK or Qt. That rules out like 80% of open-source.)

It only supports plaintext, which might be a deal breaker, but I've gotten used to it. I rarely find myself needing formatting, and it has some functions to get around that, like the ability to drag arbitrary URLs and files into the text box and have them turn into clickable links. If I ever need to have images in my stuff, I usually just have links like that in my text.

That might make working with the notes a bit awkward on Android, though. Honestly, I wouldn't know. I rarely edit my notes on the go. If I need to look at my notes when I'm not using my computer, I usually export a small section of my file and physically print it out.

The program's so small I just keep it and all the files it generates in my Dropbox. With that setup, I pretty much get all the benefits of Evernote I'd need without worrying about losing notes or proprietary file formats or whatever. It's kind of weird, but I would really recommend giving it a shot.

(Among other things, I wrote this entire post in it. :p )

I'm not completely sure it's his code. In his comments, he says it is for "those who are interested in trying something like this," and the readmes of most of the repos thank Tavis Rudd for inspiration, which would be a little strange if he wrote them. It might be based on his system, though, since he said he had privately sent some people his code. I haven't looked into it too much, though.

You can find my setup on GitHub fairly easily right now (my screenname's the same), but at the moment a good portion of the code is embarrassingly terrible. Making voice commands to code while using those voice commands to code is predictably awkward. Besides, I want to write some documentation on how to get it working and stuff.

I also have hand problems. I use speech recognition to type everything, including code, and a game controller to move around the mouse. The controller I'm currently using, a PS4 controller, has a trackpad in the middle, so I was able to mash that against my face and give her technique a shot.

It works better than you'd think. The PS4 trackpad isn't exactly brilliant, but I can move around the mouse and click on what I want to with some accuracy. Of course, the trackpad on the controller is very small and not very accurate, so it's not really practical for artwork or anything. But, with a better, larger trackpad, I can imagine this technique actually working. I might give it a shot at some point.

I am a bit worried about the inevitable neck and nose pain, though. I wish she had gone into a little more detail about how she avoids that. Maybe she just has a neck of steel?

For the curious, these are some other resources I've found about people working around RSI. Most of these are about using Dragon NaturallySpeaking to code by voice, since that's what I'm most interested in, but I think it's still interesting.

There really needs to be a list somewhere for open-source workarounds to disabilities. To the best of my knowledge, there really isn't one.

Natlink + Dragon NaturallySpeaking:

(NatLink, which lets you make custom speech commands for Dragon in Python, is currently being developed at http://qh.antenna.nl/unimacro/index.html, but that site's pretty incomprehensible. The original author's site is at http://www.synapseadaptive.com/joel/welcomeapage.htm. It's pretty out of date, but explains the fundamentals of the system better, I think.)

https://www.youtube.com/watch?v=8SkdfdXWYaI (don't bother looking around, the source code of this was never released)

https://github.com/simianhacker/code-by-voice

https://github.com/tgrosinger/aenea-grammars

Libraries for using Dragon NaturallySpeaking on Linux with VMs:

https://github.com/dictation-toolbox/aenea

https://github.com/russell/damselfly

It seems a post about this kind of thing pops up about every other month or so. I'm thinking of showing off my system here when I polish it up a bit. It's not nearly as complicated as some of these other ones, but I'm beginning to get pretty close to normal typing speed coding by voice.