Other day I wanted to keep an eye on Volcano Katla. So, being a non-programmer, I wrote a few lines of code in AHK. In a few minutes I could monitor the magnitude of earthquakes and send the higher ones to my cell phone via email. (not being home most of each day.)
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?
Chris Mallet, Jon Bennit, au2
Started by
LarryC
, Apr 11 2012 08:12 PM
33 replies to this topic
#2
jethrow
-
- Fellows
-
- 2589 posts
Posted 11 April 2012 - 08:50 PM
Concerning the concepts in the Tutorial and Overview & the Tutorial for Newbies (excluding #12 & 13), could you please expand on how AutoHotkey_L is intimidating?... AHK-L presents itself as intimidating ...
#3
LarryC
LarryC
-
- Guests
Posted 11 April 2012 - 10:47 PM
Objects, DLL calls, hex, is intimidating. That is for programmers.
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.
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.
#4
jethrow
-
- Fellows
-
- 2589 posts
Posted 11 April 2012 - 11:09 PM
I believe the request was misunderstood - so let me rephrase. When it comes to the simple concepts (such as with creating a hotkey/hotstring, creating & running a script, activating a window, using variables, etc ...) in AHK, could you elaborate on how AutoHotkey_L is intimidating. Of course DllCalls are intimidating, but I'm talking in terms of noobie tasks - how is AutoHotkey_L any more intimidating that AutoHotkey?
#5
tank
-
- Members
- 4134 posts
Posted 11 April 2012 - 11:09 PM
AHK has hex and dll call since nearly the BG
#6
LarryC
LarryC
-
- Guests
Posted 12 April 2012 - 01:29 PM
AHK_L is very, very scary stuff, DLL, objects, arrays.etc
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.
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.
#7
jethrow
-
- Fellows
-
- 2589 posts
Posted 12 April 2012 - 01:48 PM
You are avoiding the request, and in an ignorant way I might add (see tank's post).
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:
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.
#8
Guests
-
- Guests
Posted 12 April 2012 - 01:55 PM
@jethrow: I think what LarryC means is this:
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)
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)
#10
jethrow
-
- Fellows
-
- 2589 posts
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.
#11
Guests
-
- Guests
Posted 12 April 2012 - 02:13 PM
Indeed jethrow, if <!-- m -->http://l.autohotkey.net/<!-- m --> started with the same bullet list as the old AutoHotkey page (with AutoHotkey you can expand text, click buttons etc) and then followed by "AutoHotkey_L includes a number of bug fixes and additional features expert users may find interesting like ... (then the objects etc list)" it wouldn't look as intimidating. The L page simply lacks an introduction as to what AutoHotkey is.
#12
Relayer
-
- Members
- 105 posts
Posted 04 May 2012 - 02:33 PM
I would like to bring the discussion back to a point the original post was making, that AHK gives access to windows PRODUCTIVITY for the non-programmer. There is plenty of other threads to discuss the difference between basic and _L.
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.
my $0.02
Relayer
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.
my $0.02
Relayer
#13
LarryC
LarryC
-
- Guests
Posted 04 May 2012 - 03:33 PM
Thank you Relayer and Guest:
You have explained better than me.
You have explained better than me.
#14
tank
-
- Members
- 4134 posts
Posted 04 May 2012 - 04:52 PM
It exists because Chris stopped developing AHK and someone else had to. without source control a fork was necesary.
Why
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
[rant]
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]
Why
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
[rant]
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]
#15
LarryC
LarryC
-
- Guests
Posted 04 May 2012 - 07:08 PM
Ok tank. Your main point seems to be, we need to continue on with AHK_L because
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.
Relayer wrote:
.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.
Relayer wrote:
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
