Sounds like PRQL [1].
1,576 karma · joined October 28, 2012
[1] http://www.bitsavers.org/pdf/symbolics/software/genera_8/Pro...
Cool, I'll be following that. To me, one of the most interesting aspects of Genera is the command line interface, where commands know their arguments' names, types, defaults, and help strings. The commands can output nicely formatted data such as tables and, because they're just Lisp functions, they can share structured data directly rather than parsing and serializing ad-hoc text formats as is that's typical in the Unix world.
Why do you think that? There's no need for a Python 2->3 like transition here, it could have been done while supporting the old C API for a while.
I think that's much more stereotype than reality. People see all these parentheses and think that it must be a difficult language that requires a big mindset shift, like these purely functional languages with dependent types. In reality, it takes a week or two, plus an editor plugin that highlights matching parentheses, to get used to writing (function arg-one arg-two) instead of function(arg_one, arg_two). After that, it's smooth sailing. Just another decently designed language that's dynamically but strongly typed. Feels like writing Python, except with a bit of metaprogramming from time to time.
I think you're overestimating the importance of syntax and underestimating semantics. It doesn't take a very long program to get bitten by bad semantics. A few years ago, I was writing a game extension in Lua. It was only a couple hundred lines, and I still wasted hours debugging problems that would've been one minute fixes in Python or Lisp. All because of Lua's ridiculous idea of conflating arrays with hashtables, plus its habit of returning nil instead of raising an error when you do something that doesn't make sense.
I think that this is a false dichotomy most of the time. Yes, there comes a point where to get more novice-friendliness, you have to trade off against the program's skill ceiling - its flexibility and the speed that a proficient user can achieve with it. But are we at that point? Have we really picked all the low-hanging fruit so that the only remaining way to decrease the need for manuals is to "lock the users into predefined tracks", as you say? Personally, I don't think we're even close. There seems to be very little exploration of that space. Apart from rare exceptions like Magit, I mostly see software that's designed to appeal to beginners, and then "power user UIs" that are either really old or imitate UIs that are really old.
Magit is actually a great counterexample to your framing. It turns your keyboard into a huge joystick for git commands, without forcing you into any particular git workflow. It's easy to integrate your own custom git subcommands into Magit. If some obscure thing you want to do isn't supported, there's a key to run a custom git command, or you can just do it in your shell and then hit the refresh key in Magit. Yet, because Magit shows you a lot of contextual information about your repository, as well as the keys you can press to perform various actions, it requires very little manual-reading to learn.
Or let's take shells as another example. Would it really "lock the users into predefined tracks" to make some part of the prompt bright red when you are root? To have the hostname in the prompt when you're logged in via ssh, so that it's harder to mess up and execute a command in a different window than you intended? When you try to run a program that doesn't exist, instead of just saying "command not found", to tell you the name of the command you appear to have misspelled, or the package you can install to get the command? When you start typing a tar command, to show you a little cheatsheet of the common flags? To have autocompletion for all the flags of the command you're typing, along with a short sentence describing each? To have a bit of syntax highlighting, so that you know right away when you've typed a command or a path that doesn't exist, because it's in a different color? To have the default variable syntax pass the value as-is, and use a special syntax for word-splitting, rather than the reverse? To have a fuzzy search window for the last thousand commands you've executed and directories you've visited? To pop up a desktop notification when a very long-running command has finished? To measure the running time of every command and make it accessible afterwards with a command or a variable, so that you don't have to re-run the command if you forgot to prepend "time" to it? To make the shell act a bit more like a Jupyter notebook, so that it's easy to run multiple commands in parallel, and you can have keybindings that scroll the window by command rather than by screenful? To show the contents of the current directory at all times below the prompt or in an optional side pane, so that it's easier to orient yourself in the filesystem without running ls all the time?
I don't think any of these things would "lock the users into predefined tracks". It seems to me that they would make life easier for novice users without hurting power users, and it's mostly for historical reasons that we don't have them by default.
Your example of a fully programmable text editor is probably the strongest. Emacs would indeed be more novice-friendly if its programming language was removed in favor of a couple pages of GUI settings, and I wouldn't want that. But after we've decided that Lisp programming it is, are there really no things that could be done to make it more approachable without lowering the skill ceiling? What about good default settings? Highlighting matching parentheses? On-by-default autocompletion that pops up a little window with the documentation of the item that you're about to select? Highlighting functions that are defined in the current Emacs instance with a subtly different color from those that aren't? Showing the user the signature of the function they're typing at the bottom of the screen, so that they don't need to open the docs if they're a bit rusty and forgot the order of its arguments? Showing all references, a link to the manual, and the source code of the function you're viewing in *Help*?
Lastly, your distinction of whether a program needs you to read the manual before use strikes me as too binary. There's also the matter of forgetting things over time. I think it's more accurate to think of each UI as having a range of usage frequencies that it's best for. For example, I know common Emacs, Vim, and Magit keybindings by heart because I do a lot of programming and quite a bit of system administration. But when I need to partition a drive, I just use GParted. I only do it once a year or so; it doesn't make sense for me to learn a command-line tool, as I would probably forget the syntax by the time I needed to partition something again. If I was partitioning drives all the time, then it would be different.
* Those designed for power user speed, with seemingly little regard to novice-friendliness (e.g. bash, tar, find, Emacs calc, Vim).
* Those designed for novice-friendliness and aesthetics, with seemingly little regard to power user speed (many GUI programs, almost all websites, almost all phone apps).
It feels like we're very far from the Pareto frontier, and I wish more people thought explicitly in terms of getting closer to that frontier - that is, "how can we maximize novice-friendliness under the constraint of not lowering the speed ceiling even a bit". I think this could be done through some combination of autocompletion, cheatsheets that pop up automatically, and consistency between programs.
Magit-like UIs are a happy exception to the rule. Their speed ceiling is very high because they're completely keyboard-driven and have no animations, but their discoverability is good because they constantly pop up little cheatsheets of what keys you can press to trigger actions. I was able to start using Magit almost immediately after installing it, and learn it gradually without looking at external resources. Now I fly through the common operations on muscle memory, and it feels like it took no effort to get there. I hope that more programs copy this UI paradigm.
1. Let's create a super advanced type inference system so that you can write Haskell like a dynamic language but have it be static.
2. Oops, now when you make a mistake, it propagates through your program and causes a type error somewhere completely different.
3. New code style rule: you may omit type signatures on local functions, but always place them on top-level functions so that they serve as a barrier to incorrect type inferences.
I found this, videoticle.com (gives just one screenshot + raw transcript), videogist.co (keeps erroring out), and some commercial tools (couldn't be tried without paying first).
Here's some feedback, since you asked. I tested your tool on one of my favorite technical talks, Linux Memory Management at Scale <https://www.youtube.com/watch?v=QZZWAsBI_zY>, resulting in <https://vi-su.app/QZZWAsBI_zY/summary.html>. It was very easy to use, worked on the first try, and took shorter than I expected to generate the summary.
Unfortunately, I don't find the result useful. The summary is mostly vague generalities like "Clarifies common misconceptions about reclaimable memory", "Explains the role of swap in memory management", and "Discusses the limitations of the OOM killer". It's actually less detailed than the text on the slides, so it doesn't provide extra value over just running a scene detection tool on the video to get one screenshot per slide. All the technical details, which are the reason I like the talk so much, are missing: the difference between kswapd and direct reclaim, why the kernel OOM killer won't save you (it runs as a last resort, which can be a double digit number of minutes after your system has become unresponsive), why Facebook shifted from using memory limits to memory minimums (minimums compose better), why they prefer btrfs to ext4 (the ext4 journal causes priority inversions when used with cgroup priorities).
I was looking for something that would preserve all the detail in the talk and could reliably work as a replacement for watching it. My ideal UI would be two columns: on the left, there would be screenshots, and on the right, there would be a full transcript, just cleaned up so that it reads well: ums, ahs, hellos, and thank yous removed, sentences rephrased to be more concise, everything divided into sections and paragraphs.
Regardless, thanks for posting. I'm glad that people are working on tooling like this.
My impression is that the priming chapter is bunk, but the rest has generally held up. Is that no longer true?
Recently though, I've been wondering whether advanced type system stuff is the right approach. It usually becomes pretty complicated, like another language on top of the regular language. Maybe it would be easier to have some kind of framework for compiler plugins that do extra checks. Something that would make it easy to check format strings or enforce rules on custom attributes, like Linux's sparse does, using plain imperative code that's readable to the average dev. Large projects would have an extra directory for compile time checks in addition to the tests directory they have now.
But I haven't seen any language community do something like that. What am I missing?
However, now that most people have moved to streaming services, I think that CDs may become the audiophile/hipster format of choice. They have the advantages of vinyl - being able to physically touch your collection and look at the cover art, generally no DRM, the nostalgia factor of using old technology - while also having near-perfect quality and not degrading with every listen.
Some operations on groups are also too verbose, like getting top 5 items in each group.