Hacker News Reader

Comment by michaelmrose | Hacker News Reader

Recompiling software to change options is utterly and totally ridiculous

Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.

What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave how we want.

Let's also remember that a great deal of software you don't even think about also runs this way; they'll have config flags to add and remove features at compile time (run Gentoo or FreeBSD ports for a few weeks and you'll see what I mean).

So having hardcoded options isnt that ridiculous nor uncommon on Linux. However mainstream desktop distros do a good job at hiding that from their users by picking sane defaults for them.

> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.

Cool... Now I know that it's not just me that does this then. :)

Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

> Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.

If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation.

Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)

Counter-example: Xmonad. Here's how I "configure" it:

Open ~/.xmonad/xmonad.hs. It's Haskell code, but frankly it reads like a configuration file, with a big list of shortcuts.

Edit the "code". You don't need to know Haskell, just follow the syntactic conventions you see there. Worst case, you have to search for configuration tips on the web.

Save xmonad.hs, hit the "recompile Xmonad" shortcut. You've now recompiled and restarted Xmonad, and all your windows are still where they were before. Application state survives recompilation.

I kind of agree. But, how often do you change your settings after you've found the right ones? A minimalist would see runtime configuration as bloat.

Finding the right settings is a relatively slow process. Also, finding the right values for 80% of the settings is fast, but fiddling with the rest can take time. Trying something new also becomes harder.

For the vast majority of user-facing programs, run-time configuration is a must. A fancy GUI for it might be superfluous; a simple text file / command-line way to set options should always be available.

Compile times for me are 0.2 seconds. And there is a text file available, it's called config.h.

This sort of rules out binary distributions, or changing settings on a remote machine where you don't have the build dependencies installed. The latter may be irrelevant for a terminal emulator, but not for the general case.

> This sort of rules out binary distributions

You can install software without a package manager.

In my experience if one can edit config files on a system, one has room to install a minimal C compiler. And one can distribute things in a binary form even if the config requires compilation. Consider distributing an application as a library or object files when the target machine needs to compile and link only the config file.

The difference between a config file that's dynamically loaded and a file that is compiled in is surprisingly small, as long as the compile times are very fast. First noticed that when using XMonad: one shortcut to recompile it and reload it, that's just as fast as editing configuration of any other window manager.

If it's one thing I've often had to change across systems (hardware and operating systems) it's things like font type and size. If one works mostly from one workstation (eg: a laptop) this is less of a hassle (just need to change on each new generation of ppi, and perhaps on some major system upgrades) -- but then one might want to switch things up as new fonts are released every so often.

Edit-compile-run is a rather complicated way to tune font size compared to a slider.

And on that note, while I admire ST for its simplicity, I've been a happy user of Sakura for the past few years (though, sadly not on windows 10... I've yet to find a really good console for w10).

https://launchpad.net/sakura (page down at the moment...)

http://www.pleyades.net/david/projects/sakura

For windows ten I'm using a combination of babun/WSL and cmder. But I agree that there is no good terminal emulator. It's not terribly surprising though. When those aren't enough I have a "seamless" ubuntu VM running.

I think it's somewhat surprising that they got the Linux subsystem for Linux working well, but apparently didn't spend much time on making a proper terminal experience.

Don't get me wrong powershell/the standard terminal is miles ahead of the old crappy cmd.com - but bundling a solid terminal would've gone a long way to pacify my desire to dual boot Linux (read:stop using w10) on my Surface pro.

If I weren't teaching students that run w10 on their own pcs, I would probably have relegated w10 to a vm/wine under Linux.

I use st in i3 under Cygwin on Windows 8.1. If Cygwin works in Windows 10, that (or any other Linux terminal manager of your choice) should be doable there too.

Well, the promise of the Linux subsystem is kind of to not having to run half-ports like cygwin in the first place... Still, appreciate the tip. Any idea how well that works on a high-resolution display like the surface 4?

No idea. But it works great for me with a resolution of 1920x1080. I don't see why it wouldn't work with a higher resolution display.

Why? It’s perfectly convenient if your software compiles quickly (st does), and saves having to make guesses about configuration file syntax.

Does not apply to all software. It is just a terminal (and pretty fast terminal). I don't need change options for ST often. Changed probably few times just after upgrade to new version.

More often options are changed on the shell (ZSH in my case) Then even more often on tmux.

I kinda love it. It's just so gloriously economical, and it clearly defines their intended user base.

Reply on news.ycombinator.com