Chris Mallet, Jon Bennit, au2
Posted 11 April 2012 - 08:12 PM
I had long since abandoned any hope of a future for AHK Basic, I had wrote it off, then out of the blue, appears this, by Poly "Chris gave me his comprehensive test suite of scripts that has over 11,000 lines of code to identify any breakage", what the hell!!
I believe AHK has strong potential, not yet realized. The new Webpages are exciting.
I know less about marketing (if that is a goal?) than programming, but AHK could be marketed or targeted to the ordinary average Joe.
AHK Basic could fill that niche.
There would must be a ratio of thousand, perhaps, tens of thousands to one, of Wannabe programmers to real programmers.
Do not underestimate the power of these wannabe`s if for no other reason than their mass.
Chris's insight may be to realize that potential.
Simply, IMO, there is not another program as powerful as AHK Basic. It's power lies in its "simplicity".
VBA, forget it, too involved for the average Joe. WinBatch, cost's, AHK-L presents itself as intimidating, and AutoIt is not as simple.
I submit to you, AHK as a whole (AHK_l and basic) will be far better off working together as a team. What's that saying, the sum of their parts is greater than their sum individually.
Basic could be a like a farm team for MLB, source for AHK_L players, if you will.
I cannot understand why they both cannot live together, complimenting each other.
If AHK Basic is abandoned, could history repeat itself? Could another programmer do to for AHK Basic, what Chris did for au2?
Posted 11 April 2012 - 10:47 PM
AHK Basic works for non-programmers.
Potato farmers or the average Joe need a quick script they can produce themselves without reading anything too involved, just do it.
With AHK Basic, it is the only program that comes close to that.
Thank you very much but some of us do not want tutorials, or read manuals. Your tutorials may be excellent, no doubt, and good for those that have the time and energy. That contributes greatly to AHK.
Others have work to do. Learning programming has to wait until we find the time away from our own careers.
Posted 11 April 2012 - 11:09 PM
Posted 12 April 2012 - 01:29 PM
A new guy will avoid that like a plague, without looking.
My question is, could history repeat itself?
If AHK Basic is abandoned, (like Jon Bennett abandoned AU2, and Chris then stepped up to the plate,) would someone else step up and implement a new scripting language similar to AHK Basic for newbies.? If so, would that not be a loss for AHK_L?
Just suggesting, if u like AHK_L then AHK Basic is your friend, not a foe.
Posted 12 April 2012 - 01:48 PM
The point of my request is to show this: AutoHotkey_L may be intimidating because we focus on how it is different that AutoHotkey. These differences may contain some advanced features. However, in actuallity, AutoHotkey_L & AutoHotkey are prolly about 90-95% the same. If AutoHotkey_L were the primary version, it would be no more intimidating that AutoHotkey is now.
Also, keep in mind how complex it is to create arrays using AutoHotkey:
... and please don't try to state that pseudo-arrays are less intimidating that real arrays. Folks have been creating libraries to imitate arrays/objects for years -- meaning that this is sought after functionallity, particularly after you realize why it's useful.
A concept related to arrays is the use of NumPut() and NumGet() to store/retrieve a collection of numbers in binary format ... "Scripting.Dictionary" is an operating system feature that has more capabilities and flexibility than AutoHotkey's pseudo-arrays.
Posted 12 April 2012 - 01:55 PM
Look at <!-- m -->http://l.autohotkey.net/<!-- m --> what is your first impression?
Unless you already are familiar with the easy side of AutoHotkey it looks like something very complicated, the first words:
- Objects (extensible associative arrays).
- Interactive debugging features, when used with a compatible debugging client.
- Significant functionality developed by other community members:
Native 64-bit support by fincs.
Native COM support by Sean.
Native Unicode support by jackieku.
Support for various text encodings.
New DllCall arg types for portability.
Object-oriented file I/O.
I'd run like hell too!
(no offense meant of course, but if the above page is your FIRST introduction to AutoHotkey then it is very likely non-programmers will simply leave the page very quickly)
Posted 12 April 2012 - 02:00 PM
Exactly - thank you for showing what I was getting at:
Unless you already are familiar with the easy side of AutoHotkey it [AutoHotkey_L] looks like something very complicated ...
AutoHotkey_L may be intimidating because we focus on how it is different than AutoHotkey. These differences may contain some advanced features. However, in actuallity, AutoHotkey_L & AutoHotkey are prolly about 90-95% the same. If AutoHotkey_L were the primary version, it would be no more intimidating that AutoHotkey is now.
Posted 12 April 2012 - 02:13 PM
Posted 04 May 2012 - 02:33 PM
Having said that, I am an engineer but not a professional programmer. I searched for years to find utilities that could relieve me from the mundane aspects of using a computer and speed my way to a result. For a while, I was writing scripts in C but they were hard to debug and the write-compile-test loop was tedious. AHK was the best I found. Since then I have written many scripts and have come to depend on them very much. But, in hindsight, it was a challenge to learn the various ways of doing things, e.g. "if ()" vs. "if blah,blah" and when to use %var%. So, in that regard I think there could be room for improvement to make it even more natural and consistent for the non-programmer.
The beauty of AHK (basic is all I've used) is that as soon as my skill gets to a point where I want more functionality, boom! the capability is there. And, the forum is indispensable for learning new techniques. I also know that if I want to make the investment and even have more capability, I can choose to bite the weenie and move to something like _L.
So, the crux of the discussion should be "what is the value proposition" of AHK be it basic or _L. What sets it apart from other solutions? What is its reason for existing? What is its value for continued development. There will always be differing opinions but perhaps a clearly defined statement of purpose would help define its boundaries.
I also see no reason why there cannot be offshoots with their own set of followers. If the value of any given branch is clear to a critical mass of users, it can l survive even if it becomes incompatible with its siblings.
Posted 04 May 2012 - 03:33 PM
You have explained better than me.
Posted 04 May 2012 - 04:52 PM
Bug fixes while only a few existed with basic they werent being addressed any longer
Arrays. the Forums screamed for them for years and years.
Easier than the COM.ahk library based automation of numerous non easy to automate applications Such as Attatchmate, IE,Office, WMI,...... There were are remain serious gaps in what AHK can do well without those advancements. It was particularly harder to take code examples from other languages and go to com_invoke(.... syntax
Improvements to regex
Improvements to Gui(names and embeded controls just to name a few)
unicode and 64bit OS support. yes there are a ton of people who dont need it but there are a ton more that do. additional data types for DLL calls in 64bit OS were expressly necesary
Better clearer extensible file support. before this opening once and navigating a large file was impossible without complex dll calls
I do not aggree that objects and classes offer improvement. and i do aggree that most OO programers would find this implementation a bit insulting. However i suppose Objects as they are really amount to nothing more than a natural extension of Arrays. Classes have no place in a Nooby scripting audience. Inheritance is a complicated enough subject for experienced formaly educated programmers.
and it doesnt seem to work in any traditional sense in _L[\rant]
Posted 04 May 2012 - 07:08 PM
stopped developing AHK
Okay, sounds reasonable. Supposing we say, your logic is absolutely correct. Let's say for the moment, you are 100% right. Suppose we could continue on with AHK_L, get Lexicos back by any means, begging, whatever. Continue developing AHK_L like you suggest. Still why cannot we have both AHK basic AND AHK_L? GM has Chevrolet and Cadillacs in the same family. The sum of the two together, may be greater than the sum of the two separate. I foresee a separate AHK_L as it is, anyhow. Lexicos has spent too much time and energy, just to walk away.
I also see no reason why there cannot be offshoots with their own set of followers. If the value of any given branch is clear to a critical mass of users, it can l survive even if it becomes incompatible with its siblings