Re: [Chicken-hackers] (Removing) ambiguity in csc's command line options

[felix . winkelmann]

(tl;dr: don't)

I know, I'm a bit late to this discussion, but let me ask, nay, implore you to
leave things as they are, for the following reasons:

First, nobody really wants to go through each and every tool, figuring out the
command-line parsing, changing (and breaking) everything in the process of
doing so, scratching his or her head over the interesting bootstrapping
problems this will introduce (think about it!)

It's not that serious, and: don't we have better things to do? Don't we already
have much too ambitious plans for CHICKEN 5? I mean, it doesn't reduce our
already tectonically slow release cycle... all that for a slight little bit
more consistence, a slight decrease in ambiguity, to give us a pityfully small
bit of a feeling, that, in all this mess, at least our option-parsing follows
some sort of "standard", which isn't even one, considering the countless tools
that now or in the future use a different syntax for command-line options?

But second, and much more important: breaking a bit of backwards-compatibility
is fine, when it comes to language constructs, when it comes to our precious
little programs. Different libraries, perhaps heavily restructured modules:
that all is fine, we happily cope with the necessary changes, but has anybody
thought of what lives around them, in the dark and sinister background, the
things we rather don't speak of aloud, the things that make this profession
such a nightmare?

I'm talking about build systems, my friends. And not those ridiculous, pathetic
makefiles we write, 20 to 1000 lines big. They are nothing, a piece of cake,
throw-away products, concessions to a model of building software that was
already outdated 50 years ago, yet we still cling to it and speak of "object"
files and static or dynamic linking and shared libraries and dynamic loaders
and all those laughable things, as if our life depends on it. I mean, 
"-headerpad_max_install_names"? Windows manifests? weak symbols? rpaths?
sonames? I mean, think about it, try to get rid of years or decades of
inurement, and look what concepts we use daily, with some mental distance. It's
insane, pathetic, dangerous.

But I digress. What I'm truly talk about is the other side: the arcane, baroque
and lovecraftian build systems that drive embedded- or mobile software
development, the infrastructure that surrounds our precious creations of
algorithmic beauty, utterly ad-hoc and depressingly a-posteriori. And this
includes testing frameworks, deployment systems, continuous delivery, and what
not.

It's not our fault! It's the foulness of the substructure - proprietary
development tools, the insanity of embedded-systems development, marketing and
money-driven deployment crazyness in mobile devices - these are our true enemy,
these are what give rise to elaborate build-systems that sooner or later become
nearly unmaintainable, are next to impossible to debug, without staring for
hours with tired eyes at screenfuls of console-output, trying random changes,
until, finally, the build seems again to work (sort-of), in the hope of just
getting over it, to come back to the actual work, the real problem, to actually
do a bit of programming!

Have you ever tried to shove an external tool into an iOS build? Oh, you know
the feeling that comes up when you try to find the correct build-options in
that funny settings panes in Xcode, those that never do what they seem to do (I
imply you actually found the setting you are looking for, as some "user
experience" designer had his (or her) very own idea of how and where this
setting should be hidden), where googling is more productive than reading the
non-existent, or misleading or just incorrect documentation, or when Xcode
crashes yet once more, and your only way of venting your frustration is by
thinking of the devastating expletives you could enter into the crash dialog
("Send bug report to Apple?" You bet, Asshole!) I'm not going to talk about
Visual Studio - too many have already ranted about it and have given up in
tears, and it also makes no sense to enter into the subject of an android
build, together with some external native libraries and perhaps a
not-so-totally braindead language thrown in, that you would like to integrate
to perhaps write your logic (I'm not saying "business logic", that is just
another term invented by managers playing software architects) into a bloated,
slow and unsatisfying thing called an app. "App" sounds harmless, doesn't it?
well, we know how what it truly means - it means suffering.

Where was I? Anyway, those who haven't experienced this don't know the true
meaning of the word "pain". And when I say pain, imagine what it does to you if
someone comes along, and, for a slight little bit of consistence, or for a
slight decrease in ambiguity, changes the syntax of ALL command line options,
to please his (or her!) perception of "taste", breaking ALL your builds, and
giving you the hearty promise of hours, days or weeks of changing, debugging
and testing those terrible build-systems, those things that you promised not to
touch ever again (they were working, right? you told your boss, who already
stands behind you, "to get on with coding", as all that build-system twiddling
already took much longer that expected.) That, that is pain. It is more than
pain, more painful that pain: it is unnecessary pain.

Imagine again - do you want someone to do that to you? I don't. Such a thought
would give me fantasies, fantasies I can't explain here, as children may be
watching.

So, don't. Thank you.


Good night.


We are all doomed.