Re: MacSoup + MBP - numeric keypad = irritation!

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

zoara <me18@xxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

Stefan's hard-coded ones (like F for follow-up)
can't be changed by the user.

Ah - you mean that you call software encoding `hard encoding' if it's
not readily accessible to the end user?

That's standard programmer's parlance. Well, "hard coding" rather than
"hard encoding", at least (just to avoid confusion).

Uhuh. Bollocks is standard parlance amongst people who spout bollocks,
I'm sure.

Um?


Why should I worry about idiots who cannot think clearly?

I didn't say you had to; I was just explaining what Jan (and almost
every other programmer) means when he says hard-coded.


`Hard coding' - if it means anything at all - is analogous to `hard
wiring' as in ` here lieth the actual lumps of copper and they're fixed
in place rather than being able to be modified using software'.

`Hard coding' is a contradiction in terms - unless you're talking about
some sort of ROM setup.

Only if you're ultra-literal about the English language. There's plenty
of terms that don't make literal sense, but they're understood by the
majority to mean something other than a literal interpretation.

As to the term "hard-coding", I suspect that there are two possible
etymologies; one being that back in the day, when you wrote code
containing fixed parameters, you would literally make hard, physical
copies of that embedded data (eg on punchcards). The other possible
explanation is that the terms share a common root with hardware and
software, but are otherwise unrelated; hard-coded values are simply more
fixed and less malleable than soft-coded values (like rock is harder
than jelly).


Basically, if something is not configurable (eg the location where the
software saves output files) then it is considered 'hard-coded'.

By whom, exactly?

How many programmers are there on the planet? By that many people, minus
a couple of dozen. JFGI - it's the first hit on Google.


Something can be considered 'configurable' if it can be changed by the
user by tweaking a setting (obvious or hidden), or changed by the
programmer without recompiling the code.

Any code can be so changed - if it's not stored on read-only media.

Not easily; not without recompiling the code.


So, in this context, "hard coded" means that the F for followup can only
(readily) be changed by recompiling the code;

But you're lying (and yes, this is a deliberate falsehood I've spotted):
it means `F for followup can only be changed by recompiling the code'.

You've tried to pull a fast one by placing that word `readily' in the
sentence.

Yes, that's right, I'm out to lie and deceive you. That's the only
reason I'm here.

Oh, hold on, no I'm not. I'm just explaining what hard-coding means. I
put the word 'readily' in because that's what hard coding is; you *can*
adjust values, even code, without recompiling, but it's hard work. So,
if a value is hard-coded, it cannot readily be changed without
recompiling. Those values that are not hard-coded can be changed easily;
that's the point of not hard-coding them.

Go ask a programmer.

But `readily' is not what it's about: if the code can be
changed using non-destructive processes, it's not `hard' coding. It can
be so changed, so it's soft coding just like everything else in RAM and
on disc.

I have spoken to hundreds of programmers (and read things from many
times that on the web) in my time. I have been a programmer for about
eighteen years now (wow, that long?). I have not heard that definition
of hard-coding before, but if that's how you want to define it, then be
like Humpty and define it as you like. Just don't expect to be able to
communicate about the subject with programmers.

By the way, what term *would* you use to describe the difference between
a value which is compiled into the code, and a value which was easily
reconfigurable without recompilation? Just curious, because I use the
term often and can't imagine having to say that sentence each time I
wanted to discuss it.


other applications use a
soft approach for their keyboard shortcuts, meaning if you really want
to, you can edit them. Poke around in the Keyboard and Mouse
Preferences; look at Keyboard Shortcuts, click the plus icon at the
bottom-left of the list, open the "All Applications" dropdown, and note
that MacSOUP doesn't show up in the list of apps with editable keyboard
shortcuts.


What a strange mis-use of language - suggesting that something's fixed
in hardware purely because it's software, but readily modifiable by the
end user.

Hardware? No-one mentioned hardware.

`Hard coding' is `hard wiring' if you think about it. Or have you never
programmed something *really* primitive?

It depends on your definition of the terms. That's what's under
discussion here.


Hard coding as a term derives from `hard wiring'. If it's `hard' in
such terms, it's `fixed in hardware'. That's what phrases like that
mean.

Cite?

Anyway, regardless of the etymology, the current meaning is "a
compiled-in value". Nothing to do with hardware.


Hard-coding is a standard, well-understood programming term.

Is it now?

Pick a programmer at random. Ask them. Repeat a thousand times.


Ask any
programmer with more than a month or so worth of experience working with
other programmers.

And you claim to have the one single defintion of the word that is
universally accepted as the one true definition, that has never had
anyone argue about it and has never shifted in its meaning and never
will so shift?

Please don't put words in my mouth.


So it's current programming jargon in the circles you operate in, is it?
Well, okay - but what does it mean?

See the post you just followed up to, or any of the other downthread
responses to your post with Message-ID:
<1ie4dcy.1w6t04k8gwf9kN%real-address-in-sig@xxxxxxxxxxxxxxx>


btw, I don't pay much attention to what programmers use by way of
language

Evidently.

If you don't, then how can you argue the meaning of hard-coding? Where
else, outside of programming, would the term be used?


- it changes all the time,

As does all language. See the American "I could care less" idiom, for
example, or the dropping of the apostrophe in "shan't". It's just
quicker in programming, and that's because the pace of change is faster
in that field (and other technical fields) than the average.


and most programmers are famously
incapable of rational thinking or understanding of reality.

Sorry? Cite? Where did this come from?


What a word
means in programmers' jargon today will have changed by this time next
year - or so it seems, for the most part.

It's not that fast. Otherwise how would one communicate? New terms are
invented reasonably rapidly, but older terms don't change meaning so
much.


I have trouble with many programmers - they seem to live in some strange
parallel world that I really cannot figure out at all.

I'd have put you down as a programming type, actually. At least, before
this thread.


It's also something known to be avoided where
possible. It bears no relation to the "hard" in "hardware". Think more
"set in stone".

Quite - `hard' as in `hardware'. Set in stone. Set in stone - sounds
like hardware to me.

*rolls eyes*

So everything set in stone is literally engraved into a rock? No. It's
another one of those times where English stops being literal.

"We're not changing the office dress policy."
"So I can't come to work naked?"
"No, the policy is set in stone."

The policy cannot be changed in the same way hard-coded values cannot be
changed. Neither involves rocks, or hardware.


`Hard coding' is related to the term `hard wiring', which is exactly the
`hard' in `hardware',

Cite?

What about "hard" being inflexible, and "soft" being malleable? Because
that's the difference between values that are hard-coded and not.


so I have to tell you that you are utterly wrong on this point.

I expected nothing less, to be honest.

-zoara-


--
"Ignorance more frequently begets confidence than does knowledge."
- Charles Darwin
.

Relevant Pages

  • Re: What will many cores mean to future Windows releases?
    ... Obviously the hardware might be indeterminant --that would be the normal 'cross-platform' use case. ... But I would rather see an inline operation or compiler switches that would allow you to set or monitor the operations without a JIT compile each time the process ran. ... VMs have their purposes, but optimization is better determined at coding time when you know where the code is going to be deployed, rather than leaving it to be determined at runtime. ... The run time then chooses the algorithm and number of processors to devote to the task, so it's rather like an SQL 'ORDER BY' clause--the programmer specifies what the results need to look like, and the implementation details--being fairly mechanical once the business logic is understood--are handled by the compiler and runtime. ...
    (borland.public.delphi.non-technical)
  • Re: Cohens paper on byte order
    ... AES implementation myself, let me hypothetically ... assume that I am the programmer responsible for AES ... has a number of different hardware and that I don't ... I know that no conversion is needed. ...
    (sci.crypt)
  • Re: Can anyone tell me what hw is and what sw is? Re: Asian trio in deal to replace Windows
    ... ;BECAUSE EVEN THE HARDWARE HAS SOME ... INTERMEDIARY REGISTERS THAT THE ... ;ASSEMBLY PROGRAMMER CAN NOT SEE! ... RST, ...
    (soc.culture.china)
  • Re: why does tar close stdout and stderr right before exit?
    ... :>: programmer screwed up in a different way? ... :> The signals you mention are raised by the OS in response to hardware ... why isn't it similarly OK for library functions to do so? ... We get these signals not as a means to detect errors but simply because ...
    (comp.unix.programmer)
  • Re: hardware errors, do C and Forth need different things in hardware?
    ... do what the comment says or it is a bug that *always* needs fixing ... maybe even needing hardware traps?" ... Any functioning C compiler will generate code that does exactly what it says. ... Your code is clearly a bug in *some* cases, but since C can't tell if this is a bug or the actual intent of the programmer, C will faithfully compile the code to do what the programmer wants-- just like Forth. ...
    (comp.lang.forth)