The secret to writing code quickly is two fold:
- Plan before you code
- Have an IDE with decent code completion
3 Likes
- Have an IDE that can keep up with a 2 finger typist!
I really can not type and am a 2 finger typistā¦ and the ONLY app I have ever used that could not keep up with my typing at times is the IDE (at least 2019r1.1)ā¦
And I am on a pretty beefy iMac (2019 3.6GHz I9 40GB RAM Radeon Pro Vega 48 8GB)!!!
-Karen
2 Likes
Iām a quick (not fast) 10 finger typist, and canāt recall every out-typing the IDE
I just use Siri to speak my code and manage 200 words a minute!
ā¦ of course it takes me ten minutes to correct all the mistakes ā¦ stupid auto-correct 
1 Like
Yes, it does make coding quicker. It probably only saves a few seconds a few times per hour, so itās barely measurable in terms of clock time, but it makes the process feel faster, or at least easier.
At least the way I code, when Iām unpacking some data (JSON, a database record, whatever), I often find myself doing something like
name = dict.Value("name")
age = dict.Value("age")
and then realizing, oh, I havenāt declared these variables yet, so I have to back up and go insert a couple of lines and type
dim name as string
dim age as integer
Then find my place again and keep going.
This is almost always completely unnecessary busy work. These are just disposable local variables, they donāt need to be verbosely declared that way.
name := dict.Value("name")
age := dict.Value("age")
works fine and doesnāt require me to either anticipate every variable Iāll need or backtrack to declare them.
It just makes the process a little bit smoother.
It also makes reading code quicker, and as the adage goes, we spend more time reading code than writing it.
There is some potential for ambiguity when reading code with type inference, e.g., in the example above, you may not know offhand whether age is an integer or, for some reason, a double, or a string, but in my experience you usually donāt need to know for sure, and if you do or youāre just curious, you can usually figure it out immediately by looking at how the variable gets used. About 95-98% of the time the data type is either obvious or you donāt actually need to know exactly, so reading through lines of explicit dim statements is just wasted effort and gets in the way. In the few cases where it might be important to specify/document the data type, go ahead, dim yourself a variable.
Again, the actual time difference isnāt huge, but it sure feels better to write and read code in languages that donāt force you to verbosely explain things that donāt need explaining.
insert ?
why not just convert those lines into
dim name as string = dict.Value("name")
dim age as integer = dict.Value("age")
and carry on ?
more just curious than anything
type inference for age might result in it being a string (really depends on what dict.value could figure out since its all variants in xojo
1 Like
why not just convert those lines into
dim name as string = dict.Value(ānameā)
dim age as integer = dict.Value(āageā)
and carry on ?
Yes, Iāll often do it that way too. My shortened example elided the fact that I often have multiple variables to declare, so I end up doing them in one line, like dim name, title, address as string. Either way itās still back-tracking and extra typing.
type inference for age might result in it being a string (really depends on what dict.value could figure out since its all variants in xojo
Good point. In this example, the dictionary is coming from JSON, where at least in my experience an integer in JSON is reliably parsed into an integer (albeit a variant) in the dictionary and extracted from the dictionary into an integer variable, but Xojoās use of variants does create some issues.
Integers and strings are not a big deal for me.
Iām fine with:
Dim n as Integer = 45
Typing Dim n = 45 Isnāt explicit enough to determine the proper type for n. In āold skoolā coding, you could do this:
Dim n = 45! and the ! would tell the compiler itās an integer, or # a double, etc.
My big thing is classes.
Dim MyInstance as MyClass = New MyClass
This is overly-verbose and unecessary. If the stuff on the right side of the equals returns a single type, then the type declaration should be unnecessary, as it is in .NET. e.g.
Dim MyInstance = New MyClass
.NET takes it even a step further by allowing initialization values in the declaration:
Dim MyInstance = New MyClass {Name="Bob", Age=45}
I like those kind of shortcuts because thereās no ambiguity.
1 Like
NET takes it even a step further by allowing initialization values in the declaration:
Dim MyInstance = New MyClass {Name=āBobā, Age=45}I like those kind of shortcuts because thereās no ambiguity.
Yeah, I like that a lot.
Dim MyInstance as New MyClass
the only extraneous word here seems to be āDimā
this is kind of like a constructor - just named params (which I think would be useful as heck)
@Karen: Iām a very very fast 10 finger typist. And not once I outtyped the IDE. Not even on slow hardware.
@samRowlands: I hate learning new interfaces. For instance, the ribbons from Office always confused me. API 2 isnāt too bad to learn and retain. Yes, itās mostly silly. But Iāve got it now. The only problem I have is when using Thomas Tempelmanns implementation of NSTableView. That one uses the old API and I donāt remember the method names anymore. I donāt understand the lazyness of Xojo. Was it really so hard to make documentation method 1 is now method 2?
Nope - that tells itās a variable and not a constant.
Right - Iād do this this way
MyInstance as New MyClass
const MyInstance as New MyClass // although this is invalid in Xojo but you get the ide
@Karen: Iām a very very fast 10 finger typist. And not once I outtyped the IDE. Not even on slow hardware.
All I can say is it feels like Iām typing in molasses in the IDE code editorā¦
I deleted my copy of 2019R1.1 and downloaded a fresh copy and it is still the same.
Maybe it has to do with the 27" retina screen on the iMac, even though I have a decent graphics card?
Iām on 10.14.6 BTW
-Karen
Thanks - I should not post late at night ā¦ 
dont apologize
sometimes the conversation alone is enlightening since it shows others how weāre thinking about approaching such issues
We have the same problem.
2019r1.1 is just about usable but 2019r2 onwards is twice as slow and is unusable. I can repeat the problem on 3 different Macs I have access to so I know itās not a problem with my Mac.
As far as I can tell, the problem is related to auto complete and the number of plugins installed. Earlier versions of the IDE can cope with the same plugins so god knows how they managed to make it this slow.
By the way, if you find that clicking items in the navigator or selecting objects in the window is slow, try hiding the toolbar. I get the impression that the IDE keeps on rebuilding the toolbar from scratch which adds a noticeable delay.
Not sure I agree. MyInstance is not created as a type of āNew MyClassā, which is the way that reads. unless somehow instantiating MyClass results in returning a type rather than an instance. (Which might be possible, I donāt knowā¦)
MyInstance is being created as type MyClass and then being assigned the value (or address if you want to get picky) of a new instance of the type MyClass.
Thatās why Dim MyInstance = New MyClass makes sense, IMHO.
I have 19 total. A subset of the Einhugur Plugins + MBSChartDirector
I would have posted the list but ā¦
While IDE will present a list of the installed plugins in a listbox, unfortunately they have the listbox set to single selection so you canāt just select all and copy the list!
That is unfortunateā¦ and would be very easy to changeā¦ Donāt know why they set it to single!
-Karen