When Apple went from Carbon to Cocoa, the offered their developers no such
migration utility (to my knowledge at least). What they DID do is inform people
well in advance of depricating Carbon that the time was coming where adherence
to Cocoa would be mandatory, and they offered frameworks and p
Whenever you deprecate code you may be destroying
someone’s life’s coding work. There should always be
at least a rock solid migration utility offered that will
make any such deprecations completely smooth,
and painless for anyone who has to make the changes.
Just my 2 cents for the day. ;-)
Ric
Mark Wieder wrote:
> A good question to ask here might be "what are the pain points of the
> language as it now exists?"
For me performance is a pain point. If I can demonstrate LC is at least
on par with other scripting languages I get a foot in the door. But in
server work performance count
Hence my original statement about the xTalk language trying to be English like.
(Back then I don't think Hypercard was multi-language).
Bob S
> On Mar 30, 2018, at 10:53 , Mikey via use-livecode
> wrote:
>
> When I was thinking about unquoted literals I was thinking about string
> literals
When I was thinking about unquoted literals I was thinking about string
literals, something like
put one into counter
Or
put one into two
Numeric literals don’t offend the senses:
put 1 into counter
In the case of property assignments I could be persuaded either way: that
there is a global co
We have computers automate these processes, but always with a human ready to
intervene. The computer will act based upon the inputs it receives. If the
inputs go wrong, you may have an exceptional diagnostic routine running to
detect it and act accordingly, but only a human can make a judgement
That's pretty much my point of view - the compiler should keep you out of
trouble but not get in the way.
Colours are the same case as left in the context of textAlign. If we reserved
all lowercase alphabetic identifiers, so your vars had to contain an uppercase
letter or non letter character t
I think we are not seeing the elephant in the room here. Programming languages
work because a great deal of effort has been exherted defining what we MEAN
when we SAY something to the computer. In fact the whole process of writing
software is precicely that of removing all ambiguity. It's true t
On 03/30/2018 08:56 AM, Mark Waddingham via use-livecode wrote:
I'd suggest that the language doesn't matter - so 'natural language like' would
perhaps be a better term but even then is that really what we mean?
A good question to ask here might be "what are the pain points of the
language a
An important question to ask here is 'what do we mean by English-like'?
I'd suggest that the language doesn't matter - so 'natural language like' would
perhaps be a better term but even then is that really what we mean?
There's no inherent difference (formally at least) between a programming
la
I agree. The goal was to make computing as english like as possible, but the
take away to that great experiment is that one can only go so far. People
interpret what a person may mean. Computers do not have that luxury. Still
xTalk is a magnificient accomplishment.
Bob S
> On Mar 29, 2018, a
On Mar 29, 2018, at 10:34 PM, Mike Kerner via use-livecode
wrote:
>
> I don't want to pretend to be an expert on the topic of writing compilers,
> since I only ever wrote two, both under the watchful obsession of a
> professor, and my lex and parse code were not optimal in either case. In
> gen
I don't want to pretend to be an expert on the topic of writing compilers,
since I only ever wrote two, both under the watchful obsession of a
professor, and my lex and parse code were not optimal in either case. In
general, they were some of the easiest pieces of large code I ever wrote
because t
On 2018-03-28 15:45, Mike Kerner via use-livecode wrote:
Heck no. I spend way too much time in environments that were written
to
make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.
Heh - I'm not sure that the necessity to predeclare things in
Right. It's the beauty of LC. You choose to declare, I choose to not
declare. Can you imagine how annoying it would be whenever you send a text
that included jargon and your phone autocorrected it for you because it
didn't know what you meant? Or when your voice assistant didn't understand
you
The C key will copy what you have selected, if you hold down the ctrl or cmd
key when you type it. Similarly, the V key will put what you copied where the
cursor is, and will even replace whatever you have selected! ;-)
Bob S
> On Mar 28, 2018, at 06:52 , Alex Tweedly via use-livecode
> wrot
On 28/03/2018 14:45, Mike Kerner via use-livecode wrote:
Heck no. I spend way too much time in environments that were written to
make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.
Yeah - why are those variables declared all together, way up at t
Heck no. I spend way too much time in environments that were written to
make the complier-writer's job easier and have 50-100 lines of headers.
It's annoying to the extreme.
Nothing makes code less readable than re-using i, j, k, l, and m because
you don't feel like using a readable loop counter
On 03/27/2018 06:56 AM, Mike Kerner via use-livecode wrote:
Has anyone written a script to go through a stack and xref the variables?
Yeah, but I didn't find it of much use. Unless you're using a lot of
global variables or constants, why would this be useful?
..and notice that this task bec
Has anyone written a script to go through a stack and xref the variables?
--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, "This is good."
20 matches
Mail list logo
