[HN Gopher] Enlightenmentware
___________________________________________________________________
Enlightenmentware
Author : zaik
Score : 357 points
Date : 2024-05-20 20:23 UTC (15 hours ago)
(HTM) web link (mmapped.blog)
(TXT) w3m dump (mmapped.blog)
| jiehong wrote:
| Speaking of Bazel, I wanted to try it out for a Java project, but
| it felt a bit more complex than expected.
|
| Would you recommend using it even for mono languages projects?
| colordrops wrote:
| If you haven't already committed, consider Nix instead.
| threePointFive wrote:
| I'm still trying to understand why people recommend Nix in
| place of a build system. Nixpkgs stdlib by default expects an
| autotools project. It will happily integrate with other build
| systems, as long as you've spelled out your dependencies in
| both. I've yet to see it generate a Makefile or make any
| decisions about compilition that weren't spelled out in a
| "traditional" build system. Could you shed some light on what
| I've missed?
| __MatrixMan__ wrote:
| I'm not sure why you'd want to generate a Makefile if
| you're using nix. Unlike make, nix understands the inputs
| to a build step and won't bother rerunning it unless their
| inputs have changed. You would lose that you generated a
| Makefile instead of having nix build whatever it is that
| the Makefile builds.
|
| Otherwise it does the same things as make: this bunch of
| commands depends on this other bunch of commands... It just
| makes you express that as a function so it can be smarter
| about memoization.
|
| I've not used it for large complex builds, so maybe there's
| some itch it fails to scratch at finer granularity which
| I'm overlooking. I liked this artical about where it shines
| and where it fails to be a build system:
| https://www.tweag.io/blog/2018-03-15-bazel-nix/. I've been
| waiting for the problem to arise that encourages me to
| learn Bazel so I can use it alongside nix, and it just
| hasn't yet.
| ris wrote:
| So.. it's sort of a battle over territory between build
| system and package manager.
|
| Bazel is there becoming ever more complex and unwieldy in
| an attempt to provide supposed reproducibility - taking
| control of the provision of ever more of a project's
| dependencies (in often very janky ways). But to Nix people
| it's clear that what people are actually doing here is
| slowly building a linux/software distribution around their
| project, but in a very ad-hoc and unmaintainable way. And
| bazel projects will continue to grow in that direction
| because until you have control of the whole dependency
| stack (down to the kernel), you're going to struggle to get
| robust reproducibility.
|
| I don't think many Nix people would suggest actually using
| Nix as the _build system_ , but probably to use a
| comparatively simple cmake/meson/whatever build-system and
| use Nix to provide dependencies for it in a reproducible
| and manageable way.
| threePointFive wrote:
| Thanks for the summary. I've been using Meson + Nix, so
| the comments about using Nix as a build system have been
| confusing. I think what I've been seeing though are "use
| Nix instead of Bazel", not "use Nix as your build
| system".
| colordrops wrote:
| What I mean is use a relatively simple build system
| instead of Bazel, and deal with dependencies and
| reproducibility through a Nix development environment.
| fire_lake wrote:
| You lose out on some of the incremental compilation speed
| that Bazel offers doing this. I think many in the Bazel
| space suggest using Bazel inside of a Nix environment.
| zokier wrote:
| You call blaze side janky and ad-hoc but to me (as
| complete outsider) using monorepo+build tool seems more
| principled and working more with fundamentals, while nix
| feels more ad-hoc and trying to fix stuff post-facto.
|
| > And bazel projects will continue to grow in that
| direction because until you have control of the whole
| dependency stack (down to the kernel), you're going to
| struggle to get robust reproducibility.
|
| This is bit weird statement, considering that it's not
| where bazel is growing to, but where bazel is growing
| from. The whole starting point for bazel is having full
| control (via monorepo) of the dependency stack
| AlotOfReading wrote:
| Bazel is probably at its simplest in a monolingual codebase.
| Toolchains have a lot of complexity.
|
| It's like that Churchill quote about democracy: Bazel is the
| worst build system except for all those others.
| sanderjd wrote:
| Used bazel for years, now using pants[0] and really enjoying
| it as a tool that is good in the same ways, but better in
| some smaller ways.
|
| 0: https://www.pantsbuild.org/
| Tijdreiziger wrote:
| Why not Gradle or Maven?
| WatchDog wrote:
| While maven and gradle may lack the architectural purity of
| bazel, they work much in the same way.
|
| Plan and execute steps, building a graph of the required build
| tasks, only executing the tasks that have changed inputs.
|
| With that said, it's quite common to see maven/gradle builds
| that are misconfigured and execute tasks unnecessarily.
| fire_lake wrote:
| I would use choose it for a C++ only project, but that's
| because the alternatives are so horrible.
| jchw wrote:
| Doubt anyone will be surprised by this from me, but, Nix, 1000x.
| The amount of crazy stuff you can make work with Nix and Nixpkgs
| is _nuts_. This weekend someone pinged me wanting a static build
| of a Rust binary that had some gnarly bindings to C++ libraries.
| In under 100 lines of Nix, we have everything: static musl-based
| build, dynamic glibc build. Want an AppImage? `nix bundle` with
| an AppImage bundler. Want an OCI image? dockerTools.buildImage on
| top of your derivation. Throw it in GitHub actions using the
| Determinate Nix Installer action and you get automatic caching of
| the Nix store using GitHub actions cache; pretty useful since
| neither musl Rust nor static LLVM are cached in Hydra. Want to
| share your cache? Pipe a list of Nix store paths to Cachix, then
| they can pull it down, or add the Cachix GitHub action to
| automatically pull from and /or push to it for the CI build. So
| if anyone wanted to re-use your cache from GitHub Actions CI
| runs, they could, provided they trust you. You can even cross-
| compile with MinGW, or run it on macOS.
|
| It's a hugely complex time sink, but my God, it's great. Whereas
| I don't generally recommend people go down the NixOS rabbit hole
| unless they're convinced it's right for them, I definitely think
| Nix is worth having in your toolbelt, it's ridiculously
| versatile.
| xyzzy_plugh wrote:
| This 100%. It's the gift that keeps on giving.
| nicce wrote:
| You need to give the first gift, however. Time. And lot of
| it.
| renewiltord wrote:
| Wait, this is a pretty good sell. I'm going to give this Nix
| thing a shot. All the other times it's posted people talk about
| things I don't care like replicable builds and stuff.
| __MatrixMan__ wrote:
| My guess is that if you use it long enough for it to start
| being useful, you'll find that "replicable builds" solves a
| wider variety of problems than you initially thought it did.
|
| At that point, the hard part becomes getting your co-workers
| to recognize that all of these little problems that they
| perceive as separate are actually just facets of the the same
| huge nondeterminism problem.
| renewiltord wrote:
| I'm sure. It's just not a selling point for me right now.
| jauntywundrkind wrote:
| I see tons of people very happily using Nix, but also from what
| I've seen Nix is one of the most opaque hard to understand
| inscrutable systems on the planet. The language is impossible
| to learn, and my limited experience has been that there are
| extremely few good guides to peering under the covers.
|
| Nix is one of the most powerful & well-used bits of modern
| computing, hugely adopted and loved, but my limited
| understanding (and what's kept me broadly uninterested) is that
| it is on the wrong side of the Age of Reason trying to
| overthrow the Age of Magic war.
| jchw wrote:
| Honestly, I suspect a lot of what makes it opaque is the fact
| that it hinges a lot on functional paradigms, this definitely
| made it a lot harder for me to understand. The trouble is
| that now that I understand it, I'm not sure how they could
| architect this in a more scrutable way. This is the problem.
|
| I think most of us who use and love Nix understand that it is
| too complicated, but it's too complicated because none of us
| can figure out how to make it simpler.
| infogulch wrote:
| I'm also nix-curious and intimidated by the wall. I feel
| like things would be a lot easier to grok if Nix actually
| had a static type system or even something opt-in instead
| of "the object has whatever fields I happen to put in it,
| good luck lol"-typed.
| colordrops wrote:
| The language is not the hard thing, it's actually
| straightforward once you get it. It's the crazy amount of
| convention and the number of layers in the stack that make up
| the Nix ecosystem that takes so long to grok.
| memothon wrote:
| What's the right way to learn how to use NixOS?
|
| There are a few different approaches to doing everyday
| development (oh use Flakes or just make it a default installed
| package) that it's tedious to do lots of things I've found.
| jchw wrote:
| I don't think there's a right way to do it, you are correct
| in that learning NixOS is pretty tedious.
|
| Re: flakes, my personal opinion is to use flakes. While
| Flakes are imperfect, they still provide a lot of
| functionality that Nix doesn't otherwise have. In my mind,
| it's like Nix's equivalent of "Go modules" or something like
| that. I do feel like people who do not like flakes make many
| valid points (the boilerplate, the fact that the top-level
| flake expression is a subset of Nix for some reason, etc.)
| but the argument isn't that those problems shouldn't be
| solved, it's that flakes are a sub-optimal design. Since
| they're so proliferated throughout the ecosystem though, it
| is _quite_ unlikely that Nix or any prominent fork will
| outright drop flakes support any time in the near future. For
| better or worse, Flakes are part of the Nix ecosystem for the
| foreseeable future. In my opinion, one may as well take
| advantage of that.
|
| If you haven't already, I'd get your feet wet with installing
| Nix on a non-NixOS machine first, and please feel free to ask
| questions about Nix in the NixOS Discourse "Help" section.
|
| I have some recommendations:
|
| 1. https://github.com/nix-community/nix-direnv - Since Nix
| derivations usually wrap around other build systems, the
| entire derivation is recomputed when any file in it changes;
| using direnv, you can just get your _normal_ dev tools upon
| cd 'ing into your project directories. This gives you a lot
| of the benefits of Nix during local development, but with
| your normal stack, and without needing to globally install
| anything. Importantly, this works around the problem of
| needing to rebuild your project every time a file changes;
| Nix caching isn't granular enough (at least when wrapping
| around other build systems as it normally does.)
|
| 2. If you are trying to build something, chances are you can
| find inspiration in Nixpkgs. Are you curious how you might
| package a Bevy game? No problem: literally search "bevy" on
| the Nixpkgs GitHub repo and see what comes up. I found a
| derivation that does: https://github.com/NixOS/nixpkgs/blob/m
| aster/pkgs/games/jump...
|
| 3. If you use flakes, you should keep the flake "schema"
| handy. There are a lot of different kinds of flake outputs
| and there are different ways to specify the same thing, which
| is somewhat needlessly confusing; keeping the flake schema
| handy will make it easier to understand what Nix is looking
| for in a flake, which might make it easier to see what's
| going on (especially if it's obfuscated.) The most important
| takeaway here: A command like `nix run flake#attr` will try
| _multiple_ different attributes.
| https://nixos.wiki/wiki/flakes#Flake_schema
|
| 4. Likewise, I really recommend reading up on what NixOS
| modules are. NixOS modules are the basis for configurations
| on NixOS, and having a clear understanding of what is even
| going on with them is a good idea. For example, you should
| understand the difference between the Nix language's `import`
| directive, and using the NixOS modules `imports` attribute to
| import other NixOS modules. Understanding how the
| configuration merge works saves a lot of headache, makes it
| easier to understand how people's configurations works, and
| also makes it easier to modularize your own NixOS
| configurations, too. https://nixos.wiki/wiki/NixOS_modules
|
| Unfortunately though, there's just no way to make it "click",
| and I can't guarantee that it's worth all of the effort. For
| me, I felt it was, but yes, there's no one correct way to do
| it.
|
| But please feel free to ask questions if anything seems
| confusing.
| memothon wrote:
| Thanks for the inspiration. I actually already have nixOS
| installed on another laptop, but lapsed back to my Ubuntu
| machine out of a bit of frustration. I'll try it again and
| see how far I get with these tips.
| SSLy wrote:
| Point 4 is incredibly under-marketed. Almost all of
| Nix/NixOS documentation focus on the language-y and build-
| system-y parts of Nix, and the NixOS modules are usually
| not talked about. Terrible state of docs doesn't help.
| atrus wrote:
| The No Boilerplate video is what got me started:
| https://youtu.be/CwfKlX3rA6E?si=hJZ_mm9vaeKI0w8V
|
| It's just super nice having everything in a git backed
| config, for multiple systems. Working with NixOS seems like
| I'm simultaneously working 10 years in the future and 10
| years in the past.
| pxc wrote:
| > What's the right way to learn how to use NixOS?
|
| Just commit. Make it your daily driver, engage the community
| for help, and learn whatever you need to learn to do things
| the idiomatic way. Then settle in and get comfy.
|
| That said, I hear you about the paralyzing number of choices.
| Here are some okay choices you can fall back on when you get
| dizzy: - use flakes with direnv for all your
| projects - when in doubt, just write the damn package
| - need to use some Python library that depends on another
| Python library that's not in Nixpkgs? Package 'em. Package
| all the recursive dependencies, then package the library you
| wanted to use. - want some program that's not in
| Nixpkgs? package it - want to reuse a binary built
| for a traditional distro? package it. Look at examples in
| Nixpkgs of similar things (e.g., Discord, Steam) - seek
| community engagement on Discourse and Matrix, not elsewhere
| (not Reddit, not Discord, not Slack, not IRC)
|
| This is the best way to learn NixOS, imo. But if it seems
| like too much, it's not the _only_ way.
| emporas wrote:
| Nix is one of the reasons open source wins in the long run. I
| would have never imagined that package dependencies could be
| installed and managed across programming language boundaries,
| kernel boundaries, shell boundaries, dotfile boundaries etc.
|
| Given that computer complexity grows exponentially all the
| time, then at some point everyone will be forced to use
| something like Nix.
|
| I agree with the article with Emacs and Unix/Linux.
| fire_lake wrote:
| Functional Programming approaches usually win in the long
| run. This is a common thread in the article too, although not
| explicit.
| trashburger wrote:
| I think you mean declarative. Whether something is FP or OP
| usually doesn't matter _too_ much (unless you go to the
| extremes of each end of the sprectrum a la
| AbstractBeanFactory /IO Functor State). Declarative
| solutions last longer by virtue of their declarativeness;
| the underlying implementation can evolve as long as the
| declarative layer is untouched.
| zarathustreal wrote:
| Isn't a class a declaration (of a class type)? Isn't a
| function a declaration (of an algorithm)?
|
| I'd assert that every programming language is
| declarative. Especially once you get enough written to
| constitute a DSL.
| helpfulclippy wrote:
| I had only a dim awareness that Nix was even a thing before a
| few weeks ago. Then somehow I decided that I needed to commit
| to it 100% and make NixOS my daily driver and make myself learn
| this. It's been a lot of fun. Like, Dwarf Fortress kinds of
| fun. The kind of fun where when I first looked at it I thought
| it was insane inscrutable nonsense, and now I kind of wonder
| what happened to me that it's kind of making sense now. The
| kind of fun where I keep telling myself I just want to make
| some tiny little thing work, but actually I find excuses to
| rabbit hole down a bunch of different pathways and find
| amazingness under every stone. The kind of fun where I know
| better than to try to count how many hours I've spent on this
| now.
|
| Except unlike Dwarf Fortress, I feel like things are actually
| improving over time instead of shambling ever-onwards towards
| an inevitable downfall. So I guess maybe it's more like the
| kind of fun the very first time I installed Linux and didn't
| know my way around anything.
|
| I'm surprised how much I enjoy customizing things now. I always
| thought of my desktops sort of like betta fish before -- like,
| I've taken care of them, but also known better than to get too
| attached. Eventually the reformat is gonna come, and I'm never
| gonna set things up QUITE like I had it before. That's
| definitely not true now. I could start from scratch and be up
| and running with my entire suite of applications, themes, add-
| ons and configurations in no time, because it's all just a git
| repo of nixfiles.
| dizhn wrote:
| You have a typo. "earn to" when you probably meant "yearn to".
| roman-kashitsyn wrote:
| Fixed, thanks for reporting!
| dist1ll wrote:
| I would say the compiler explorer[0] fits the definition
| perfectly. It may seem like a straightforward piece of software,
| but it has immensely changed the way people discuss and share
| knowledge around compilers and performance optimization.
|
| I regularly feel the impact on the quality of forum discussions.
| There's a lot less speculation about if "call X gets inlined", or
| "Y gets vectorized". Bold claims can be supported or disproven
| quickly by sharing a link. And then you have tools like llvm-
| mca[1] or uiCA[2], if you don't mind going into the weeds.
|
| [0] https://godbolt.org/
|
| [1] https://llvm.org/docs/CommandGuide/llvm-mca.html
|
| [2] https://uica.uops.info/
| zem wrote:
| along those lines, the entire notion of a web playground (a
| sandbox where users can just write and execute or otherwise
| process code) has vastly reduced the barrier for checking out a
| project or experimenting with its behaviour
| ReleaseCandidat wrote:
| > web playground
|
| This _so_ much. Where in the past I've used Jupyter Notebooks
| for short, one off stuff or to test something, I now do that
| online for almost any language.
|
| Notebooks are still useful to write documentation though.
| coldtea wrote:
| Well, Notebooks main use case is a different purpose, not
| for trying one-off stuff or checking if some syntax is
| valid. It's for doing stuff step by step, annotating the
| steps and/or explaining each result.
|
| Web playgrounds are ok for testing some syntax (if you
| don't have a local REPL/easy way to test), but not for one-
| off stuff that involves file input or that you want to
| check against real environment assets.
| ReleaseCandidat wrote:
| > Well, Notebooks main use case is a different purpose,
| not for trying one-off stuff or checking if some syntax
| is valid.
|
| I know, but that's what I had used it for too. Like
| posting some code, for example in a HN post ;) As I've
| said, I still use it mainly for documentation.
| rnewme wrote:
| I would dare say for me the https://pythontutor.com/ even more
| so than compiler Explorer. (hint: it's not just for python)
| AceJohnny2 wrote:
| > _(hint: it 's not just for python)_
|
| I would definitely have overlooked it, and it really needs a
| better domain name.
| ot1138 wrote:
| Pahole is a related utility for high performance programmers.
| I've been able to attain orders-of-magnitude performance
| improvements in trading applications using it.
| hu3 wrote:
| Docker is one of these tools for me.
|
| The unspeakable amount of my time and headache it saved during my
| consulting career puts a smile on my face.
|
| Docker allows me to quickly iterate over the steps required to
| run ancient projects.
|
| Not having to install 5 different relational database servers on
| my host OS alone is worth the learning curve.
|
| Also crucial for running concurrent, reproducible, Python
| environments in my laptop.
| XorNot wrote:
| While it takes heavily from the UI, podman with user namespaces
| enabled is the completion of this idea for me.
|
| No more sudo requirements, greatly reduced attack surface,
| isolation as a "user" concern. It sits happily in my UI doing
| _exactly_ what I need it to do for all these use cases.
| udev4096 wrote:
| Imo, making a Dockerfile for an ancient project isn't always
| easy
| fmbb wrote:
| But usually easier than making it build locally.
| vvern wrote:
| Maybe one day the buck2 ecosystem will evolve to be that bazel
| replacement. It has a much smaller core. Right now it's lacking
| in ecosystem support, tooling, examples, and a local build
| sandboxing (which could be fine if there was an easy to use local
| implementation of remote build that felt natural). Also no go
| support is sort of painful, and it's a bunch of work as i
| understand it to get something like rules_go to work for buck2.
| bbkane wrote:
| It looks like Go is starting to get better support in buck2 -
| see https://github.com/facebook/buck2/issues/455
| zokier wrote:
| Buck2 is really enticing. If I had too much time on my hands,
| I'd love to try to make a full bootable Linux distro as
| monorepo and built with buck2. I do see some sort of
| convergence between package managers and build tools, nix and
| buck2 do seem to approach similar problem from different
| angles.
| ReleaseCandidat wrote:
| > examples
|
| As it may be that people don't find them, the official ones are
| in `examples`
| https://github.com/facebook/buck2/tree/main/examples language
| examples in `examples/with_prelude`
| https://github.com/facebook/buck2/tree/main/examples/with_pr...
|
| There is a minmal Go example too:
| https://github.com/facebook/buck2/tree/main/examples/with_pr...
|
| More "real world" examples are dtolnay's CXX for Rust and C++
| interop: https://github.com/dtolnay/cxx
|
| and my own ones (sorry to link these again, but I do not know
| of any others):
|
| C++ with Vcpkg: https://github.com/Release-Candidate/Cxx-
| Buck2-vcpkg-Example...
|
| C++ with Conan: https://github.com/Release-Candidate/Cxx-
| Buck2-Conan-Example...
|
| OCaml: https://github.com/Release-Candidate/OCaml-
| Buck-2-Examples
| ReleaseCandidat wrote:
| And a remark: the "real" problem when using Buck 2 is the
| interface to the LSP, as most LSPs only work with the "native"
| project configuration. For C++ generating a
| `compile_commands.json` is quite easy (see my C++ examples in
| the other post), not the least because there is no single
| standard for a project's configuration.
| delta_p_delta_x wrote:
| > I couldn't fathom why anyone would use Windows2
|
| I saw this sentence, was about to type something in response, and
| then I expanded the footnote (side note: is it really a ' _foot_
| 'note if it's not in the footer of the page?):
|
| > I became significantly more tolerant since my early university
| years. Windows (specifically the NT family) is a great operating
| system. I even have it installed on my gaming pc so that I can
| buy games I never play.
|
| It's pretty rare to see such a balanced perspective with respect
| to Windows when someone starts off with 'UNIX'.
| ghostpepper wrote:
| > From that moment on, unix followed me through all stages of
| my life: the toddler phase of keeping up with the cutting-edge
| Ubuntu releases, the rebellious teens of compiling custom
| kernels for my Thinkpad T61p and emerging the @world on Gentoo,
| the maturity of returning to Ubuntu lts and delaying upgrades
| until the first dot one release, and to the overwhelmed parent
| stage of becoming a happy macOS user.
|
| I started off as a Linux zealot and followed a very similar
| trajectory. I think it's a sign of maturity to realize there is
| no absolute "best" in engineering, just a best solution in a
| particular problem space, and Windows is the best for a large
| number of users for a reason.
| aulin wrote:
| I started as a Linux enthusiast a long time ago, these days
| in my own time I use macos and I don't miss Linux that much,
| as long as I'm in the terminal I don't feel a difference.
|
| At daily job I'm forced to use Windows, the only thing that's
| keeping me from changing jobs is WSL2. I'm just not
| productive with mouse based tools, I need a terminal and
| powershell doesn't do it for me. Everything feels alien and
| less usable to me even after years, fonts, window
| decorations, file manager, UI inconsistencies between
| different tools. Everything seems slightly hostile and out of
| place.
| mhh__ wrote:
| Pedantry: it feels like false balance.
|
| Windows is fine, that's it. I use it every day, but it's got so
| many weird quirks that (that I can't do anything about, being
| the difference with Linux) it seems ridiculous to call it
| "great".
|
| I'm in the other room from my windows laptop. It's late,
| there's almost nothing running in it, the lid is closed,
| surprise surprise I can still hear the fans.
| rusk wrote:
| > I can still hear the fans.
|
| I could not deal with that I'm sorry. I'd have to turn it
| off.
|
| The only way I could make Windows usable day after day in a
| previous job was to shut it down every night, and then I had
| the BIOS configured to start it up again and iterate through
| my extensive startup list before I got into work. Was quite
| effective like that.
| xandrius wrote:
| Fans are probably either a rogue service you can find in the
| task manager or hardware problem (maybe it needs some new
| thermal paste or a good air blow to remove dust).
|
| That has usually nothing to do with the OS itself.
| andrepd wrote:
| Recent Windows releases are notable for _not_ running
| software without the consent or wishes of the user :)
| 20240519 wrote:
| Windows 2000 was great IMO, and peak Windows!
|
| XP was peak if hardware compatibility is important.
|
| Then it went downhill slowly. UI decisions and telemetry and
| now needing an internet connection and a MS account to install
| and now Win11 refuses to install on perfectly good but older
| hardware.
|
| Microsoft cloudifying Office ironically makes going to Linux as
| a normie fairly easy as Office is the only thing I would miss.
| And mainly due to it's dominance rather than it being great.
|
| Windows dark side is a shame as MS as a developer's company is
| really good. VS, VSCode, Typescript and C# and F# are awesome.
| And also some changed to Windows are good.
| Affric wrote:
| Occasionally I have to help my father with his windows
| computer and each time it actually gets worse. Edge.
| Suggestions.
|
| Like I am sure the actual fundamentals of the OS are fairly
| high quality but holy shit it sucks to use.
| h4kor wrote:
| I had a similar, frustrating experience last weekend trying
| to copy data from a phone to a windows machine.
|
| Windows is trying to hide all "technical" stuff so hard
| that it becomes impossible to do anything.
| GuB-42 wrote:
| I put the peak at Windows 7.
|
| Windows 7 UI is like Windows XP but prettier thanks to GPU
| acceleration. Compared to the XP generation, it had better
| security, 64 bit support out of the box, it was an "internet
| age" version of Windows, but it could still run offline and
| wasn't too obnoxious with ads, telemetry, etc...
|
| It definitely got downhill after that.
| timeon wrote:
| > Windows 7 UI is like Windows XP but prettier
|
| Isn't 7 UI basically Vista?
| Aeolun wrote:
| Sorta, but Vista was slow and stuttery, so they don't
| _feel_ the same.
| Zecc wrote:
| I mostly agree. But Windows 10 added virtual desktops[0].
| Took them long enough!
|
| Its dialog when copying files in nicer as well IMO.
|
| [0] Windows 7 supported up to 4 virtual desktops, but not
| out-of-the-box: https://learn.microsoft.com/en-
| us/sysinternals/downloads/des...
| pie_flavor wrote:
| On the contrary, footnotes on a webpage belong in the margins.
| Putting them at the foot of the article in current year is like
| banging rocks together.
| analog31 wrote:
| The main thing keeping me on Windows is touch screen support. I
| know I'm a freak for wanting it, but we all have our ergonomic
| preferences.
|
| Beyond that, I treat the OS as an appliance. Most of the
| software that I use is platform independent.
| DeathArrow wrote:
| After 20 years of using Linux on the desktop (and FreeBSD, and
| NetBsd) in parallel with Windows, I gave up. I don't like to
| always configure things, I don't need 20 different ways to
| accomplish a task and some of the software I use is not
| available on Linux. So I went Windows only for the desktop
| since 4 years. Of course, when I had to do something server
| side, it was Linux only.
|
| Recently I bought a MacBook Pro and the experience is very
| Windows like. I don't have to mess with the OS and it just
| works.
| worksonmine wrote:
| Stick to one Linux distribution and you can have the "one
| size fits all" experience you want. Who's forcing you to
| unixhop and constantly fiddle with your stuff? I'm on Debian
| and never have to change anything and my setup just works.
| flobosg wrote:
| > (side note: is it really a 'foot'note if it's not in the
| footer of the page?)
|
| These are rather sidenotes (or margin notes).
| lelanthran wrote:
| > It's pretty rare to see such a balanced perspective with
| respect to Windows when someone starts off with 'UNIX'.
|
| I dunno. I've posted some pretty balanced opinions on OSes:
| I've frequently criticised Windows, Macs, Gnome, Plasma and
| more.
|
| They all each suck in their own specific ways. Most people
| acknowledge this.[1] Many people are just like me: we put up
| with the crap on each system in order to get work done.
|
| [1] The exceptions are almost always Mac and Gnome users:
| trying pointing out that UI can be objectively bad, and the
| default Mac/Gnome experience fails on more than a few of the
| objective UI metrics, and you almost always get multiple
| Mac/Gnome users saying that UI is all subjective.
| bitwize wrote:
| I'm not the Linux zealot I was as a kid, but I can never see
| myself going back to Windows. The particular niceties of a Unix
| environment are ones that I've come to rely on, and I could
| never go back to managing all my files and data through rat
| wrestling, the way Windows seems to want you to do.
|
| That said, I can see the merits of Windows, especially for
| normies or video game players. It's just absolute friction town
| for me to use it.
| ctenb wrote:
| I think the peak of windows was when they introduced WSL,
| making windows the ultimate crossplatform dev OS.
| jwrallie wrote:
| I hope the author would consider trying Doom Emacs, he mentioned
| knowing Vim and using Vscode, so with Evil and lsp support he
| will feel at home, the configuration has great defaults!
| srcreigh wrote:
| Evil offends my simple sensibilities. I prefer boon for modal
| editing due to its simplicity and how it fits with emacs so
| well.
| roman-kashitsyn wrote:
| I tried God Mode and Evil several times, but it never ended
| well. Mostly because of the muscle memory I accumulated over a
| decade.
|
| Evil is fantastic, but it doesn't play well with all the
| packages in the ecosystem. There are adapters for Magit,
| Compile, etc., but most packages define key bindings that
| require Ctrl-Meta cords, which causes cognitive dissonance.
|
| God mode is a neat idea, but I never committed to it, and I
| found it confusing at times.
|
| Overall, I decided to accept Emacs as it is, with all its
| quirks, and embrace its way of doing things. I'm not married to
| it, so I can occasionally cheat by switching to Vim or VS Code
| without feeling guilty.
| mkesper wrote:
| I never was able to use evil per se but it works really well
| in doom emacs (and before that in spacemacs). Oh and use Caps
| Lock as Ctrl to minify pinky usage!
| jdeaton wrote:
| JAX
| somishere wrote:
| Great article. For me it's creative use of tools by others -
| sometimes myself - in a non-standard way (sometimes that becomes
| standard!) that brings enlightenment. Be it language, source
| control, networking, you name it.
|
| Aside: assuming the author is reading, minor typo in the first
| para: _But once in a white while_
| joe8756438 wrote:
| Happy to see emacs on the list, changed my life.
|
| Enlightenment hardware: kinesis advantage 2, many non obvious,
| non ergonomic benefits, like adapting the hardware to _my way_ of
| working/thinking.
|
| Certain games also feel like enlightenmentware.
| Barrin92 wrote:
| Smalltalk and as a particular case Pharo is an example of this
| for me. (https://pharo.org/). When I was in uni a paper that I
| always came back to was Licklider's 1960s paper on human-computer
| symbiosis.
|
| _" [...] to enable men and computers to cooperate in making
| decisions and controlling complex situations without inflexible
| dependence on predetermined programs."_
|
| Experimenting with Smalltalk (and also with Clojure and Emacs)
| was one of the things to me that genuinely felt like that vision
| of programs as living, interactive, organic things rather than
| the formulaic, static and low level programming that I was used
| to learning. I think it's still such a shame that in daily jobs
| it's so difficult to convince people of trying these technologies
| out because it requires such a big shift in how people think
| about software.
|
| https://worrydream.com/refs/Licklider_1960_-_Man-Computer_Sy...
| vegabook wrote:
| NixOS fits the mold. The confidence it instills feels similar to
| when I moved from Windows to (Ubuntu) Linux.
| jauntywundrkind wrote:
| I want to thank wmii for being a vanguard force in illuminating
| the path before me, by being both a fine tiling window manager,
| while also showing it's guts, exposed as a 9p file-system.
|
| Being able to craft together super crappy shell scripts to
| monitor and manage my windows was amazing. It was a huge turn on
| to feeling like someone who was really communing with the
| computer at it's deeper level, rather than just surfing above the
| application's crust. This feels like the real enlightenment goal:
| bringing forward the (ab-)natural philosophy that underlies each
| bit of software, rather than crafting facades of interface atop
| the core.
|
| I have high hopes that general systems research can one day again
| spark an age of revelation & understanding, that we can form
| better more earnest symbiosis with machines. wmii was a good
| example of one way to let bonds grow close & strong.
| nighthawk454 wrote:
| > They are "round": they pack the most volume in the smallest
| surface area. unix surface area is tiny, but it unlocks much
| power. Emacs and Git are all over the place, but their core is
| small, sweet, and easy to appreciate.
|
| I really like this 'round' concept, seems very precise. Maximum
| interface area / use cases (surface area) with minimum core
| volume.
| ssivark wrote:
| Unfortunately, a sphere of characterized by exactly the
| opposite property. The article switches the intended meaning of
| surface and volume to get away with the metaphor, but I'm less
| than thrilled about the metaphor.
| infogulch wrote:
| "encapsulate the most complexity with the smallest API" seems
| to fit the metaphor better.
| kergonath wrote:
| I am not defending this specific metaphor as I am not sure it
| is really good in this case. But they are right about this
| specific property of spheres: they have the highest
| volume/surface ratio (i.e. that's the way of minimising the
| surface area of the enveloppe for a given volume).
| mbwgh wrote:
| In Ousterhout's "A philosophy of software design", this aspect
| is described similarly via "deep classes", as opposed to
| "shallow classes".
| Narigo wrote:
| Docker would be on the list for me - for reproducible
| environments. Probably JUnit as it was my first real testing
| framework - for being able to use test driven development for
| hard problems.
|
| With programming, I had so many "aha"-moments, it's hard to
| remember them. It's not all about software, but more about
| understanding the concepts and being able to transfer this
| knowledge. Being able to pass functions or function pointers.
| Streaming / piping data instead of a fixed data structure.
| Interpreted vs compiled languages. How everything we do here only
| happens through a long list of 0s and 1s and how this clever
| setup makes us even see graphics on the screen. Or hear audio
| through a screen reader....
| zem wrote:
| blaze is one of mine too, specifically for the realisation that
| your build setup really feels rock solid when your entire
| dependency list is spelt out as an explicit DAG in a build file.
| inferring or otherwise auto discovering dependencies on the fly
| is seductive, but it always ends up letting me down when things
| get complex.
| jovas wrote:
| LaTeX.
|
| I LaTeX, Git, and emacs every day.
| nephanth wrote:
| Honestly TeX/LaTeX the engine is a marvel of technology,
|
| But everytime i see a \makeatletter or get a runaway argument
| it reinforces my belief LaTeX the language was a mistake
| isametry wrote:
| (La)TeX is an example of a very enlightened _idea_ that offed
| itself _\footnotemark{}_ with a spectacularly cursed user
| interface. It is simply gross to write, and it 's difficult
| for frontends, converters and GUIs to make it much better.
|
| Yes yes, I can already hear the cultists chant "YoU dOn'T
| wRiTe In LaTeX" but this mentality is precisely the problem.
| If I can't write directly in your typesetting system
| nowadays, then I'm sorry, your system probably sucks.
|
| You could unfortunately write an article or thesis quite
| comfortably in Word or even InDesign, while formatting as you
| go. (I say "unfortunately" because from a business-model and
| hacker's perspective, these tools suck.)
|
| _\footnotetext{_ not implying that LaTeX is dead, but
| referring to how it sentenced itself to the academic niche,
| in which case it might as well be dead... _}_
| sssilver wrote:
| > I also must confess to a strong bias against the fashion for
| reusable code. To me, "re-editable code" is much, much better
| than an untouchable black box or toolkit.
|
| I had never come across this particular thought by Knuth, but
| this hits home so hard.
|
| It feels that most of our productivity is a function of how re-
| editable the code is in the codebase we operate.
|
| It's intriguing to think about what makes code re-editable vs
| simply reusable.
| RivieraKid wrote:
| JAGS - allows you to specify a probabilistic model and sample
| from the posterior distribution
| tkgally wrote:
| I'm barely a programmer, but I have been using computers for
| nearly four decades. Among the various tools that have, over the
| years, captured my imagination, opened new possibilities, and
| affected how I create things with computers, the current leading
| enlightenmentware by far is LLMs. Nearly every day I discover
| something surprising and useful that they can do for me.
| 20240519 wrote:
| I would add
|
| Haskell - the rabbit hole to category theory and all the mad
| stuff Haskell people get into (compilers, proofs etc.)
|
| Bitcoin - love or loath it, technically it is a marvel. At the
| time Bitcoin came out I was musing on the same problem but never
| could figure out how to avoid double spends and would never have
| come up with blockchain!
| tsimionescu wrote:
| Now that the blockchain itself is actually not novel, it was
| already a part of Git at the time of the Bitcoin white paper.
| The novel part, I believe, was the proof-of-work concept.
| kevindamm wrote:
| Even proof of work was not novel, there were proposals for
| fighting email spam with similar techniques. Bitcoin's
| fortune is combining the right pieces at the right time and
| getting sufficient buy-in to become relevant and more
| difficult to ignore.
| 20240519 wrote:
| Yes I take blockchain to mean proof of work (or proof in
| general) validating blocks such that you can track time to
| some extent in a system that cannot be sure of time because
| of being distributed and nodes not being trusted.
| roman-kashitsyn wrote:
| Haskell was one of my most important discoveries; it affected
| my thinking and approach to software engineering the most.
|
| However, as I mentioned in the opening section, I deliberately
| removed programming languages from candidates for several
| reasons: 1. They received enough praise already. 2. My
| presentation would be very biased. 3. The article would be way
| too long.
| rjmunro wrote:
| > Git was nothing like Subversion. It had a steep learning curve
| and confused everyone to no end
|
| I've actually found git much easier to teach to people who don't
| know subversion than to people who do. It's still a confusing
| mess, though. Why do you create a branch with `git checkout -b`
| rather than something like `git branch -c` (`-c` to checkout new
| branch)?
|
| It looks like the `git switch` command helps a lot, but I never
| remember to try to use it as I'm used to the old ways, so I never
| teach it to new people either. I wish I could alias `git branch`
| and `git checkout` to remind me to use `git switch` but you can't
| alias over a built in command.
| yjftsjthsd-h wrote:
| I started on mercurial, _then_ git, and I think that was the
| happy path / easy on-ramp. Actually I still _mostly_ prefer
| hg, but it has some downsides and the overall ecosystem really
| prefers git.
| mkesper wrote:
| For teaching to newbies, please use the new commands! Much
| better to distinguish `git switch` from `git restore` than to
| use `git checkout` for all possible tasks.
| comment_ran wrote:
| One day, I'm working on a Linux machine with my Emacs open, I'm
| using a Bazel to clean my today's to-do list project. And I open
| the browser to find a person who wrote a blog about Boost.graph
| which I never heard about, but I'm really interested to look at.
| I finish this writing, save the buffer and =C-c g= to lunch magit
| to write a commit message "good day", then pushed to my git repo.
| bbkane wrote:
| Coming from C++ and Python, Go's packaging + deployment tooling
| really enlightened me. It's SO EASY to depend on things and
| deploy my apps, I love it!
|
| I've also heard Rust gives folks similar warm fuzzy feelings in
| regards to building and deploying, one day I'll try that too
| nox101 wrote:
| I felt that way about node and yet node lead to an explosion of
| poorly written and designed packages and constant notifications
| about needing to upgrade project X because it depended on Y
| which depends on Z and Z has some DoS issue if you pass the
| wrong regex to it.
|
| I don't feel confident that rust won't go the same way when I
| tried to update the rust docs (https://github.com/rust-
| lang/docs.rs) cargo build Downloaded
| 541 crates (55.2 MB)
|
| Seriously? 541 crates for a static site generator for docs?
|
| rust is clearly off to copy npm in all of it's faults. I have
| no idea if go is similar in the explosion of dependencies and
| supply side attack surface area explosion
| nicce wrote:
| > Seriously? 541 crates for a static site generator for docs?
| rust is clearly off to copy npm in all of it's faults. I have
| no idea if go is similar in the explosion of dependencies and
| supply side attack surface area explosion
|
| In Rust, it is design choice. They try to keep the standard
| library small, and let community create competitive packages.
| You see the result in those numbers.
|
| It is hard judge based on those numbers only.
| nox101 wrote:
| That's the same argument node people make. See how well
| it's worked out.
| kergonath wrote:
| The philosophy does not really matter, though. Any one of
| these dependencies could be a vector for a supply chain
| attack and all these libraries being updated independently
| and a synchronously is just asking for 2 dependencies
| requiring incompatible version of something else. We've
| seen this happening already and it usually ends up in 2
| ways:
|
| - the node approach: who cares? YOLO!
|
| - the particular circle of hell that is Python and its 25
| ways of doing virtual environments. Wait, 26, yet another
| one just dropped.
|
| For all its faults (and there are some), a centralised
| approach like with Boost has some merit.
| nicce wrote:
| Rust, the language itself depends on 220 packages:
| https://github.com/rust-
| lang/rust/blob/e8753914580fb42554a79...
|
| If you trust nobody, it is hard to use anything.
|
| But about your second note, (environment, mismatched
| dependencies), I would argue that Rust provides the best
| tooling to solve or identify issues on that area.
| WillAdams wrote:
| Yeah, one of the best programmers I've ever worked with would
| launch Epsilon (a commercial emacs style editor for various OSs)
| each morning and then do _all_ of his work from it.
|
| The closest I come to that is messing emacs keyboard shortcuts
| when I'm not using a Mac.
|
| I really wish that there were more programs which completely re-
| examined all aspects of various tasks _and_ incorporated
| scripting in a fashion which allows folks to take advantage of
| it.
|
| Some of the apps I would consider if putting together such a
| list:
|
| - LyX --- billed as a "What You See is What You Mean" Document
| Processor, v2.4 is looking to be quite promising...
|
| - TeXshop/TeXstudio --- the former in particular is _very_ nice
| for folks who aren't able to devote the effort to learning emacs
|
| - pyspread --- have a spreadsheet where every cell can contain a
| Python program or SVG graphic is _way_ cool --- I just wish it
| was as flexible as Lotus Improv/Quantrix Financial Modeler
|
| - Solvespace --- I wish I could do better with 3D --- usually I
| fall back to OpenSCAD, esp. now that there's a Python-enabled
| version: https://pythonscad.org/ though I often use:
| https://github.com/derkork/openscad-graph-editor
|
| - TikzEdt/IPE --- I really wish there was a nice graphical front-
| end for METAPOST/METAFONT (or that the graphical front-end for
| Asymptote was more flexible)
|
| On the gripping hand, one has to give props to the Krita folks
| for making scripting a first-class citizen:
| https://scripting.krita.org/lessons/introduction
| senkora wrote:
| > LyX
|
| During college, I time-tracked how long I spent on each
| homework for each class. I can confidently say that using LyX
| instead of LaTeX for my math assignments resulted in me
| finishing them 50% faster.
|
| I think that most of the improvement was that the WYSIWYM
| reduced the cognitive load enough that I could write equation
| reductions inside the editor without having to write them out
| on paper first.
|
| I highly, highly recommend LyX to anyone who needs to typeset
| math equations.
| lejalv wrote:
| Have you seen TeXmacs (https://www.texmacs.org/)?
| brcmthrowaway wrote:
| Closed tab at Bazel.
| zvorygin wrote:
| I quit my last job in no small part because of Bazel. I hated
| it so much. It tortured me.
|
| I think Bazel is the kind of really complicated language that
| invites clever engineers to build incomprehensible balls of
| spaghetti. And the tooling and docs are really underinvested
| in.
|
| But I got a new job, and to my surprise I've been doing Bazel
| all day. And I love it. I don't really know why.
|
| All this to say, don't make a final judgement yet, there's
| something brilliant buried underneath that pile of rules and
| aspects.
| ASinclair wrote:
| I work on a couple sets of rules at Google. I enjoy it.
| Though I agree people really can make balls of spaghetti with
| it. Everyone's macros are terrible except for mine . The
| configuration system is where things can get really out of
| hand: transitions, selects, flags, etc.
| roman-kashitsyn wrote:
| Bazel confused the hell out of me at first, and I think the
| two-phase execution model (the "plan-execute pattern" as I
| called it) is to blame.
|
| My favorite thing about Bazel is how easy it is to get stuff
| done if somebody sets up the rules for you. Copy-paste a code
| snippet and fiddle with the dependency list until it works.
|
| But as soon as you go deeper, you get overwhelmed with new
| concepts, and the documentation doesn't explain them well
| enough. I think this huge spike in complexity makes people
| hate Bazel, especially if their colleagues force it on them,
| breaking the usual workflows.
|
| I don't love Bazel, but it's the build system I hate the
| least. And it taught me a lot.
| sneilan1 wrote:
| I found quicken to be enlightening. It took me two months to
| master my family's finances and budgeting and I've never looked
| back. Learning it's ins and outs and why it is what it is and
| provides some features but not others was a wonderful learning
| experience.
| flatline wrote:
| Boost::graph feels like one of the dustier corners of the Boost
| libraries. I have used it, it worked, but it took a long time to
| wrap my head around the design and actually adapt it to my
| project. It is not great for getting simple things done, but it
| will get them done, with the power and flexibility as stated in
| the article. You will likely never see the Boost interfaces
| poking through whatever facade you end up erecting around it.
| revskill wrote:
| It is vscode and es6 to me.
| tithe wrote:
| Shells, and how by scripting them you have programmatic access to
| the entire operating system.
| donatj wrote:
| We used SVN at my first job in 2006 and I had the exact opposite
| experience with it. I never fully understood what I was doing,
| nothing made rational sense, merges were an absolute nightmare,
| and somehow I would always ended up corrupting the repo and had
| to pull a nightly backup to get out of the broken state.
|
| Git was a literal breath of fresh air in comparison. I fell in
| love hard and fast. Everything just made sense, even if our
| workflow using git am patches seems downright ancient these days.
| Friends at the time tried to sell me on hg, but I was in love.
| WatchDog wrote:
| I thought SVN was great, easy to use, and very intuitive, that
| is until you had any merge conflicts.
|
| At the time, it worked very well for our small team, I imagine
| it would work less well for large teams on a single codebase.
|
| I miss having a commit serial number.
| ahartmetz wrote:
| I used kdiff3 and could never understand people complaining
| so much about SVN merges. Now I use kdiff3 in Git and it's
| fine, too. What isn't fine (though occasionally improving) is
| Git's UI and mess of termnology and concepts.
| WatchDog wrote:
| It's been a long time since I used it, I don't remember
| what I was using for diffs, but I suspect it was just
| whatever the default built in diff support was.
|
| It occurs to me that many people these days use git with
| github exclusively, and have it configured to only allow
| commits via PR, and only allow either squash or rebase
| merges, it's kinda SVN with extra steps.
| globular-toast wrote:
| You have to sacrifice the serial number to get a distributed
| system. Well worth it IMO. But if you really wanted you could
| tag every commit on master with the next number (should be
| easy to do with a hook).
| WatchDog wrote:
| I can't really think of a good example that other people haven't
| mentioned, but I have an anti-enlightenment piece of software,
| spring framework.
|
| Spring actively hindered my ability to understand the simple
| concept that is dependency injection, and I know I'm not alone.
| Many a Java developer think that you need a big complicated
| framework to pass dependencies into your modules, instead of
| having your modules fetch them for themselves.
|
| This isn't a criticism of spring per se, it's fine, it provides
| value for people, but I think it can lead people to build
| software that is more complicated and less portable than it needs
| to be.
| kookamamie wrote:
| I would dare to say Dependendency Injection as a concept is
| unnecessary and creates more problems than it solves.
| throwanem wrote:
| One might about as sensibly say the same of functions being
| able to take arguments. If this is meant to illustrate the
| damage working with Spring does to understanding the concept,
| then it's an excellent, if mildly horrifying, illustration.
| WatchDog wrote:
| I'm still very much pro DI as a concept.
|
| I don't think DI itself really causes any problems, the
| solutions designed to save you from a little bit of
| boilerplate code, cause the problems.
| kookamamie wrote:
| I mean the original statemement from the perspective that
| only certain languages/environments (Java, etc.) propose DI
| as a solution. E.g. in my current language of choice, C++,
| DI is nowhere to be found.
| WatchDog wrote:
| C++ has constructors doesn't it?
| ReleaseCandidat wrote:
| And higher order functions.
| ReleaseCandidat wrote:
| > in my current language of choice, C++, DI is nowhere to
| be found
|
| STL, for example when passing explicit allocators. You
| can even call any higher order function using dependency
| injection.
|
| And of course there are C++ codebases that look like Java
| - the pattern book works with C++ too.
| The_Colonel wrote:
| One elementary need DI (or perhaps IoC more generally)
| provides is the ability to mock certain parts of your
| application for automated tests. While I'm not a fan of
| mocking too much and prefer higher-level tests
| (integration/component), mocking is still quite often needed.
| Is there some alternative to IoC/DI?
| poorlyknit wrote:
| Effect systems spring to mind but they're rather esoteric
| (in the Java world).
| RamblingCTO wrote:
| Totally agree. Spring and actually everything in that realm is
| plain horrible. DI is awesome on it's own (especially if you do
| hexagonal architecture), but spring hides behaviour and brings
| in undocumented changes on updates and things like that (same
| for any spring related project and hibernate). That's my
| biggest problem with it.
| penguin_booze wrote:
| I've had my short stint at using Spring. Often I was dropped
| into a project where it's already setup and working. When
| something breaks or I want to extend/modify what was working, I
| hit a wall in terms of discoverability: how it's been working
| all this time, and how to find a suitable level of
| documentation to help me. There are reams of documentation for
| Spring, but nothing of the kind that'll help me if I'm lost.
| So, from my perspective, it's write-only framework; it's hard
| to reason back.
| WatchDog wrote:
| I spent a lot of time with spring, and became a bit of an
| expert on it, I'm able to debug and understand most issues
| that come up with it.
|
| Still, I agree wholeheartedly, there is too much magic, it's
| very difficult for someone to come into a spring codebase
| without a lot of background experience, and understand how
| things tie together, and I don't think it's really time well
| spent acquiring that experience.
| The_Colonel wrote:
| > Many a Java developer think that you need a big complicated
| framework to pass dependencies into your modules, instead of
| having your modules fetch them for themselves.
|
| Not sure what you mean by "module" here, but DI means that the
| dependencies are defined externally to the actual business
| logic, which kinda contradicts this "fetch them for
| themselves".
|
| I think the problem with Spring is that it has too many
| features, too many different ways to do the same thing, too
| much configurability. Historically, Spring jumped on most
| hypes, tried to basically support everything. We ended up with
| this complexity monster, but this also made it popular. Spring
| is the Oracle DB of the backend development in the sense that
| you won't ever get fired for choosing it, it's the safe choice
| which will support in some way everything you might need to do.
| vl wrote:
| I'll mention Typescript.
|
| It elegantly improves almost unimprovable mess of JavaScript. It
| makes JavaScript development much more productive and pleasant.
| And it's surprisingly powerful.
| xandrius wrote:
| I agree but it's a shame we need to put a bandaid over JS
| instead of having a properly typed language option for the web.
|
| Now we start seeing some wasm being used but I still wouldn't
| use it for the whole project, so TS is the way for now.
| 8s2ngy wrote:
| Magit, the git client for emacs, fits the bill perfectly. It is a
| masterclass in simplicity, effectiveness, and discoverability. It
| is one of those rare tools that makes you better at the
| underlying tool it abstracts over; instead of introducing its own
| jargon and workflow it exposes git's capabilities better than git
| does.
| beautron wrote:
| I'm sure Magit is lovely. But I can't resist sharing the story
| of my bad experience with it over a decade ago (which has left
| me scared away).
|
| It was maybe early 2012, and I was excited to try Magit. I got
| it set up, and called 'M-x magit-init' from a source file I was
| editing. My understanding was that this would create a new git
| repo in that source file's directory, ending up with something
| like "/home/beautron/myproject/.git".
|
| But something else happened. The git repo was put here instead:
| "/home/beautron/myproject/~/myproject/.git". Note the peculiar
| "~" directory, created inside the project directory.
|
| Huh. Weird. Well, let's get rid of this mess and try again. I
| went to the project directory in my bash shell, typed "rm -r
| ~", and hit enter. Somewhere between my mind firing the signal
| to hit enter, and enter actually being hit, I realized with
| horror what this command would do. But it was too late to
| cancel the brain signal.
|
| I didn't lose everything, because I had not typed something
| worse like "rm -rf ~", and somewhere in my home directory tree
| was a read-only file. So the command only deleted so far as
| that file, and then paused to ask for confirmation.
|
| I estimated I lost about half of everything (the first half of
| the alphabet was gone from my home directory). The most
| frustrating thing was not even being sure what all I had lost.
| On the plus side, this experience improved my regimen around
| backups.
|
| As I was trying to salvage the wreck of my system, I had a
| separate laptop out on the side, where I was trying to get some
| help, or maybe just some sympathy, from the #archlinux irc
| channel on freenode. But the two people who responded to me on
| the channel were very snarky to me. I felt they thought I was
| clearly an idiot for having run that command.
|
| The irc people refused to believe that Magit created the "~"
| directory. They were convinced I had done that myself, with
| some other series of stupid commands. (If you had to guess the
| source of weird "~", who would you choose: the established
| Magit project, or the guy who just deleted half his home
| directory?)
|
| But a short time later I was vindicated! From Magit's github
| issue 383, Feb 29, 2012:
|
| > So if you're editing "~/Temp/foobar/boo.txt" and call "M-x
| magit-init" which defaults to "~/Temp/foobar", instead of
| creating a git repo in "/Users/jimeh/Temp/foobar" it creates it
| in "/Users/jimeh/Temp/foobar/~/Temp/foobar".
|
| Source: https://github.com/magit/magit/issues/383
|
| It was a long night (and I had to leave on a trip the next
| morning). Now it's fun memory, perhaps with a number of lessons
| in it.
| nephanth wrote:
| Agda. Not as in something i'd use everyday, but using it
| definitely shaped the way i reason about programming and type
| systems
| aulin wrote:
| > It turned a mundane job of fixing bugs into an exercise in
| skill.
|
| Emacs does this for me. It's like a toy always there to play with
| when you're bored with mundane job tasks.
| komali2 wrote:
| I really like the buku terminal bookmark manager.
| https://github.com/jarun/buku I like that I can just `man buku`
| when I don't understand something and I can actually find the
| answer I'm looking for.
| alceta wrote:
| lazygit (https://github.com/jesseduffield/lazygit) is
| enlightenmentware for me. It helps me navigate Git commands I
| forget all the time, like using the reflog to undo things, custom
| patches, or rebase --onto.
|
| It makes working with Git a lot more fun, and I giggle like a
| little child whenever one of the weirder things work out again.
| xandrius wrote:
| I find VSCode/Codium to be even better at that! And worst case,
| open up the terminal and do the job there.
|
| Even merging which was often an annoying endeavour is quite
| smooth there.
| globular-toast wrote:
| My road to Emacs was similar to the author's. When I was learning
| programming everyone was using IDEs. It seemed like they were
| inseparable from the programming language. I remember thinking I
| couldn't learn C++ because I didn't have a C++ IDE. After my
| second or third language I started to think this was ridiculous.
| It's all just text! And these built in text editors are terrible!
| It took the best part of a decade for everyone else to realise
| and move to VSCode, a vastly inferior editor.
| maxander wrote:
| I don't know whether this is a provocative or tedious thing to
| say, but the quintessential 'enlightenmentware' to have come out
| of the past several years is ChatGPT. Name anything that brings
| as much functionality with so simple an interface and so elegant
| a core!
|
| (It's simply a pity that we can't install it locally or tinker
| with the internals. :) )
| ReleaseCandidat wrote:
| > Name anything that brings as much functionality with so
| simple an interface and so elegant a core!
|
| The most important thing of the last years has been LSP
| support! I can live perfectly fine without LLM autocompletion
| (although I did use Tabnine long before ChatGPT came out), but
| not without a LSP.
| kaycebasques wrote:
| > These tools capture our imagination, open new possibilities,
| and affect how we design our own systems.
|
| Puppeteer/Playwright fits the bill for me. Learning how to scrape
| websites with those tools subtly changed how I approach lots of
| other programming tasks and opened many new possibilities in both
| personal and work projects.
|
| The event model of the web platform has had a deep effect on how
| I generally think about systems.
|
| Some people may throw tomatoes at me for this last one: Google
| Apps Script. The docs and API aren't great, but it has opened so
| many new possibilities for automation of things related to my
| personal and work Google accounts.
|
| Re: capturing my imagination, physical computing with
| RPi/Arduino. I've also gotta admit that GenAI APIs have been an
| explosion of new possibilities for my line of work (technical
| writing)
|
| Thank you to OP for creating a productive and inspiring topic
| (enlightenmentware) for us to discuss and share ideas around
| kreyenborgi wrote:
| Can you give some examples of what you've created with Google
| Apps Script?
|
| I've used it a little, but it's one of those things I always
| spend an hour building up courage to attempt (because of the
| slow feedback loop, browser-based testing, confusion about
| different deployment types, permission models and extension
| types). In such ways it's the opposite of writing Emacs
| extensions, though I can see how it promises to give something
| similar in the end.
| boffinAudio wrote:
| I have a couple of these to add as well:
|
| VCVRack - simply one of the most mind-expanding things a
| synthesizer-nerd can play with. (https://vcvrack.com/)
|
| ZynthianOS - another example of a simple software solution to a
| problem nobody realized existed, opening the door to an
| absolutely astonishing array of Audio processing tools
| (https://zynthian.org/)
| fbn79 wrote:
| In my case Cycle JS (https://cycle.js.org) was very enlightenment
| and pedagogic. It make me realize that software is always and
| only a matter of data transformation. And those pure data
| transformations can be keep separated and decoupled from "side
| effects".
| mihaitodor wrote:
| Streaming and transforming structured documents at scale used to
| require some awfully complex machinery such as Apache Camel,
| Kafka Connect, Flink, etc. I was so happy when I bumped into
| Benthos https://benthos.dev which can be used as a lightweight
| replacement in most cases. Bonus: It's written in Golang, so I
| don't have to bother with heavy dependencies and slow start
| times.
| bitwize wrote:
| Emacs, Squeak, and Genera (Lisp machine OS) all qualify for me.
| It's no surprise that all of these examples are what I call
| "pervasively programmable": you can not only extend them with
| code, but examine and modify the running system by typing code
| into it, shaping the system to your needs as it runs.
|
| Another pervasively programmable piece of enlightenmentware is
| Ashton-Tate Framework. It wasn't just a spreadsheet but a piece
| of "integrated software" (the 80s term for office suite),
| sporting spreadsheet, word processing, database, graphing, and
| serial communications capabilities, all under a unified desktop-
| GUI-like interface and programmable with the Lisp-like FRED
| language. If there were ever an "Emacs for business", it'd be
| Framework. It's pretty amazing that a program that powerful
| existed on 1980s PC hardware.
| bluepoint wrote:
| > Although I'm writing these words in Visual Studio Code, I
| always have my Emacs open
|
| He is writting the blog's text in Code praising Emacs. Makes me a
| bit sceptical or am I missing something?
| valtism wrote:
| React is this for me. Before it, I was fumbling around with
| libraries like ExtJS for my first job, but after I started using
| it the concept of components that produce a view as a functional
| output of state really made so much sense to me.
|
| It has given me so many powerful primitives to use while coding
| for the web
| JoeyJoJoJr wrote:
| I would also say Redux. Even though I grew to dislike Redux,
| understanding the power of reducers was quite mind blowing.
|
| And further I would throw in Tanstack/Redux query.
___________________________________________________________________
(page generated 2024-05-21 12:00 UTC)