(no subject)
Software development Jargon of course includes all the stuff related to SW techniques, tools, concepts, but there's probably even more project-specific jargon in any project. Names of the components being implemented, project milestones, abstraction concepts, tasks (yes, there are "jobs" that exist within one project only) etc. all contribute to the project jargon.
I'm now talking about neither of those jargon types, but about the more humorous results of the heavy abstraction.
Every modern SW has layers after layers of abstractions. Someone implementing user interface is not directly telling which kind of signal should be sent to the monitor, but (s)he considers everything as widgets (buttons, input fields, text labels). There can be dozens of SW layers transforming one abstraction to another until the "text label" turned to "text at specific window" turned to "text at specific location on screen" turned to "font definition" turned to "specific font" turned to "image" ... appears on screen, or abstraction of that (some layers abstracted away the difference between RGB monitor and Braille reader anyway) Of course nothing is as straightforward as that example but abstractions form complicated web.
There's two specific recursive concepts continuosly making misuderstanding things a bit too likely.
First thing is enable/disable functionality. When that goes to layer after layer we have to talk about things like "enabling disabling of option to disable the ..." (actual quote -> "option to disable the" means UI option to turn of an feature, but which we wanted sometimes not to give to the user (thus "disabling" from the UI), but only in specific cases (where 'enabling'))
Yes, there's a risk of confusion and mistakes when a tired persons play around with the "disabling enabling of option to disable.." vs "enabling disabling of option to disable..." and their fundamental differences.
Second one is 'default'. I use freeciv's datafile search mechanism as an example.
User can set FREECIV_DATA_PATH to point to the data file locations. If not given, the freeciv wrapper script defaults to constructing it itself. If wrapper script is not used, freeciv installation uses its internal default. This default can be given when freeciv is built, defaulting to value constructed automatically. The automatically constructed value depends on environment, but in most cases it uses the default from freeciv source code. Value in source code is either dynamically constructed, or failing that defaults to value of deprecated FREECIV_PATH. If FREECIV_PATH is not defined either, it uses the hardcoded default. In theory the hardcoded value depends on the source code copy in question, but one in master copy is the default. Of course, this is only freeciv project part of this. Downstream may add layers above this.
Anyway, ignoring the downstream projects part, default default default default default default default is
"." PATH_SEPARATOR "data" PATH_SEPARATOR "~/.freeciv/" DATASUBDIR"." PATH_SEPARATOR "data" PATH_SEPARATOR "~/.freeciv/" DATASUBDIR
where PATH_SEPARATOR is ":" and DATASUBDIR freeciv version (defaulting to "dev") by default.
I'm now talking about neither of those jargon types, but about the more humorous results of the heavy abstraction.
Every modern SW has layers after layers of abstractions. Someone implementing user interface is not directly telling which kind of signal should be sent to the monitor, but (s)he considers everything as widgets (buttons, input fields, text labels). There can be dozens of SW layers transforming one abstraction to another until the "text label" turned to "text at specific window" turned to "text at specific location on screen" turned to "font definition" turned to "specific font" turned to "image" ... appears on screen, or abstraction of that (some layers abstracted away the difference between RGB monitor and Braille reader anyway) Of course nothing is as straightforward as that example but abstractions form complicated web.
There's two specific recursive concepts continuosly making misuderstanding things a bit too likely.
First thing is enable/disable functionality. When that goes to layer after layer we have to talk about things like "enabling disabling of option to disable the ..." (actual quote -> "option to disable the" means UI option to turn of an feature, but which we wanted sometimes not to give to the user (thus "disabling" from the UI), but only in specific cases (where 'enabling'))
Yes, there's a risk of confusion and mistakes when a tired persons play around with the "disabling enabling of option to disable.." vs "enabling disabling of option to disable..." and their fundamental differences.
Second one is 'default'. I use freeciv's datafile search mechanism as an example.
User can set FREECIV_DATA_PATH to point to the data file locations. If not given, the freeciv wrapper script defaults to constructing it itself. If wrapper script is not used, freeciv installation uses its internal default. This default can be given when freeciv is built, defaulting to value constructed automatically. The automatically constructed value depends on environment, but in most cases it uses the default from freeciv source code. Value in source code is either dynamically constructed, or failing that defaults to value of deprecated FREECIV_PATH. If FREECIV_PATH is not defined either, it uses the hardcoded default. In theory the hardcoded value depends on the source code copy in question, but one in master copy is the default. Of course, this is only freeciv project part of this. Downstream may add layers above this.
Anyway, ignoring the downstream projects part, default default default default default default default is
"." PATH_SEPARATOR "data" PATH_SEPARATOR "~/.freeciv/" DATASUBDIR"." PATH_SEPARATOR "data" PATH_SEPARATOR "~/.freeciv/" DATASUBDIR
where PATH_SEPARATOR is ":" and DATASUBDIR freeciv version (defaulting to "dev") by default.