[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Desired Lua Features
- From: KHMan <keinhong@...>
- Date: Mon, 29 Jan 2018 10:09:53 +0800
On 1/29/2018 5:59 AM, Sean Conner wrote:
It was thus said that the Great KHMan once stated:
[snip snip snip]
[snip snip snip]
I'm trying to think when else I did that, and while I'm sure I *have*,
nothing comes to mind immediately.
That said, I was reminded of this article:
In the blog post, the author was also searching for words to
describe this switch/case thing, as I was when trying to put this
phenomenon to words. He used 'intent', that we are handing over
code generation to the compiler to optimize the thing, so that we
can clearly focus on our intent in the switch code.
In a scripting language however, performance is less of a
priority, because we have existing arguments that switch/case
constructs can easily be coded by things like if-then-elseif
strings, it's not needed, blah blah. We already have a lot of
technical arguments, so what is the underlying non-technical issue
that prompts the desire for switch/case?
IMHO, in the case of a scripting language, we have consciously or
unconciously desired to structure information (code) in a certain
way that humans often found useful and efficient (the time-table
analogy). We wanted it presented in a certain way, so that the
structured information can be most useful to the coder.
It's a bit like syntactic sugar. It's not like we decry syntactic
sugar as bad or unnecessary because syntactic sugar can help
present a thing more clearly, because it more closely matches
things everybody knows, e.g. math norms.
Sorry if anyone on the list thinks that this seems like more like
hand-waving psychology mumbo-jumbo. But past discussions have got
nowhere with technical arguments. We often forget the wetware
inside our skulls -- it's an important part of the coding process
too. Should the brain comply obediently to language
specifications, or should we help the brain to clearly express our
intent. That is why we structure information, we lay out code in
certain ways, etc. (Also, read Jakob Nielsen.)
 Check the archives for there is a lot of good material here. Lots
of food for thought.
Kein-Hong Man (esq.)