131–137 of 137 posts
Similar to woodworkers making their own tools, as programmers, we have the ability to create everything from operating systems to tools. This privilege is rare in other fields, allowing us to get closer to the tools we use. This autonomy enables us to have a deeper understanding and mastery of the tools and technologies we rely on.
Earlier quoted context omitted.
> I've been thinking about making the code editor (and all its various configs) a project-level dependency instead of a system config. > I know it sounds crazy, but If you bundle the tools needed to work on a project into that project, then wherever it ends up, the user has what they need to work on it, even if the internet is down: Little dev-focused operating systems bundled with each package so that the actual ope…
I was also motivated in this direction by some friends I want to teach to code. There's so much for a newbie to overcome that has nothing to do with code. What I'm struggling with right now is: How do you make supplying your own vim, say, versus the one that's default for this project... How do you make that feel like supplying a nondefault "Editor" type argument to a function? I'm aware that flake inputs support tha…
So the interface would look like
editors.vim.enable = true;
editors.vim.package = pkgs.neovim;
editors.vim.plugins = [];
editors.vscodium.enable = true;
editors.defaultEditor = "vim";
And the editors module would handle constructing the customized editor packages from the specified base packages, lists of plugins/extensions, included config, etc., as well as wrapping them so that they are called by the names `pvim`, `pcode`, `edit`, etc., and pointing them to gitignored RC files that live in-repo which users can edit.
--
Similar to woodworkers making their own tools, as programmers, we have the ability to create everything from operating systems to tools. This privilege is rare in other fields, allowing us to get closer to the tools we use. This autonomy enables us to have a deeper understanding and mastery of the tools and technologies we rely on.
Are you a summary bot?
Earlier quoted context omitted.
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Is this a joke I'm not getting? Any examples of such software?
Earlier quoted context omitted.
It's a famous quote and it is of course meant to be humorous, and a statement of how vast the functionality of common lisp is (huge spec and book)
I'm not sure I'd call it "huge" anymore, when the C++ specification (at least, this one from 2020) is 1841 pages long. https://isocpp.org/files/papers/N4860.pdf
Earlier quoted context omitted.
It's not its own kernel, but emacs can run on Linux as PID 1, at which point it rather seems like it should count as an OS. Given its affiliation, emacs/Linux probably still counts as GNU/Linux, but still...
Maybe a potential use case for GNU Hurd?
Earlier quoted context omitted.
Were you able to implement transducers at the core of Jank? Or did you end up sticking to the existing Java implementation as much as possible?
Transducers, in Clojure, are implemented in Clojure, rather than in Java. In jank, the Clojure source for transducers is exactly the same. For example: https://github.com/jank-lang/jank/blob/a14f4d7c7e8097d5ab588...
I can't find the reference right now though.
Might be a good Clojure 2.0 thing.