autoitNOW

Sorry, but I just had to state an opinion about this. Gerome, this "lack of security" also has a flip side. Many legit people will not want to use your wonderful scripting language because there is NO way that they can secure code that might have vital, sensitive, important, etc... company information. Anybody could just come along and decompile a FBSL .exe and do whatever they want. This concept of "no secure compiling" is like a "huge back door". This also relates to the issue that FBSL can not be used commercially. With AutoIt, there is at least the possibility that if the user sticks with the language long enough that he can make some useful apps and sell them. I think this "hope" allows users to feel secure that they can STAY with AutoIt, and will not be forced to learn other languages for commercial development (though different languages are right for different tasks). At the very least, the user knows he/she can secure their scripts from others copying them or protect personal information. Another point is that "script kiddies" can use JScript, VBscript (and yes there are programs that allow you to compile them into .exes, ( exescript- http://www.hide-folder.com/overview/hf_7.html or VBS2EXE- http://www.enkeladress.com/vbs2exe.htm )). They can use Python, Perl, Ruby, Euphoria, AutoIt, etc... There are already so many options for script kiddies to choose from. I'm quite sure that there are very, very few script kiddies that feel "deprived" or sad that they can't use FBSL, when they have so many other options. FBSL is a great language and you can do great things with, but somehow it seems that its "hurting" itself at the same time and has fewer users than it could/should. Sorry, just my opinion. Anyway, great editor.

Forgive me for commenting... but I do think the Hotkey and FileInstall concept is a good idea. Afterall, if the source code was also in the compiled .exe, than what difference does it make if the program was cracked? A cracked program will reveal secrets regardless... The author of the compiled .exe could create a special hotkey, password, and add extra encryption, etc... to extract his source code from the .exe if needed, lost, etc.... The only thing about this, is that it would need to be a recommended method or perhaps put in the help file. Otherwise, many users would not know about this, lose their source code and then request help and a decompiler anyway. Security would be an issue for anybody selling programs that were compiled with AutoIt or an AutoIt program that contains sensitive company or personal information. At the same time, these "personal" security issues have to be balanced by the fact that various people will/are writing malware with AutoIt and anti-virus/anti-trojan software makers are going to pick up on this. Its very interesting to me, how AutoIt can balance "personal security" versus reducing AutoIt made malware. Another important counter-point, is what to do if a consultant or programmer was paid and created a program using AutoIt for a particular company? If the programmer leaves on "bad terms", dies, etc.., but the company paid for the program, than how do they get the source code? I think the hotkey and fileinstall concept would be equal to using an AutoIt decompiler. The programmer should leave the hotkey, password, encryption, etc... combination to open the .exe and extract the source code with the company. Before the programmer leaves or at the completion of the project, the company should test the extraction method. If the programmer did not, than this would not be much different from he/she not giving the password to decompile the program with the AutoIt decompiler. It just seems to me, that the AutoIt decompiler is an "extra tool" for certain people to use to crack AutoIt programs. Its as if, Jon and the AutoIt team, were giving such people a "head start". With the hotkey and fileinstall concept, it seems that there would be a bunch of variables and variations on this method that would create problems for somebody trying to crack AutoIt programs that the author or company is using in their business and does not want cracked. If the author wants their AutoIt program to be open source, than they would provide the source. If the author closes the source, than obviously they have various reasons for doing so.

Don't forget Japanese. There were some translation scripts like this in VB, Perl, and C some years back. Kana2roma http://www.excel.studio-kazu.jp/DL/kana2roma.bas http://ftp.monash.edu.au/pub/nihongo/kana2rom.zip http://openlab.jp/skk/skk/tools/convert2sk...te/kana2roma.pl http://ftp.cc.monash.edu.au/pub/nihongo/cjkvconv.pl (East Asian code sets)

Well... "Time will tell". I do respect you Valik, but I find it laughable that you, of all people, may think you are free of "zealousness". My point was to show other viable alternatives and to remind some of us that things change and it may be good to consider or factor this in when we are talking about the future and/or careers. As you can tell by the post count and my history of NOT insulting or discouraging users that I'm usually quite content to observe more than get involved. But there are times that I'm so saddened by the "usual" spewings of the "status quo", unimaginative "robotics", and plain snobbishness or snobbish beliefs of what is the "right path" that I feel compelled to suggest that there are other directions and paths that can be taken. Also, you can always ignore me and I can ignore you, thus you will not have to suffer so. But, if you feel compelled to comment because somebody has a difference of opinion than the blame or suffering can't obviously all be placed on the person posting.

And you... you are not? Am I really, or am I just making a valid point? http://www.viksoe.dk/code/asmil.htm (this is not even recent... and talking about self extinction...well I'm sure he knows it will not be the Assembler programmers...but imagine .NET people that really want to go in that "reverse" direction...) I'm saying that a "revolution or evolution" has already begun, whether you, I, or anybody else acknowledges it. I'm just thinking it would be sad to get left behind. Anyway... I guess everybody has their perspective.

Oh by the way... Another visual codeless programming language should be added to the list: Tersus ( http://www.tersus.org/ ) Uses Java, like Imitate, but it is free, open-source, and will run on both Windows and Linux (well very soon... is using Java afterall). In addition to Tersus, I forgot to mention another codeless programming language called Synopsis ( http://www.codemorphis.com/index.php?cid=0 ), which is .NET based like Limnor. But I don't personally like Synopsis over reliance on its flow chart method as it creates "visual overload" and can be slow. Overall, I think Limnor is the better codeless language out of them all as you can use it to do things like make DLLs now, create free performers (from dlls and used by Limnor), trade libraries and performers for free among users (though you pay for the main program), you can manually/hand-code/add VB.NET and C# code (the old fashion way) too, and is about to come out with a bunch of "value-add" performers (though users can make their own) that should prove really interesting. Codeless and auto generating of code is coming... Interestingly, what will happen when you can have Assembly language "translated" into MSIL/CIL (.NET intermediate language) or Java Bytecode? The "flow" does not have to be in one direction. All you "hardcore" programmers should know what I'm talking about. That day is not all that far off either.

What do you mean by this? Select "Downloads" and then go to "Full Setup Downloads". You will see files for Windows 98/ME/NT. I will have to say that Windows 98 is a bit outdated though... ( http://www.microsoft.com/windows98/default.asp )

Hey, just playing, so don't take everything we are typing so seriously. I even liked that movie clip that /dev/null posted. What program language that you use is up to you. Free choice... Also, Limnor is a .NET language (and can even be used for scripting and it has just released a tool for making DLLs and Limnor Performers). Anyway, as a .NET language it all gets converted to MSIL/CIL (need an obfuscator, like with Java, to prevent the the "flow" from being bi-directional). C#, C++.NET, Limnor, VB.NET, Perl.NET, Forth.NET, etc... get converted to MSIL/CIL. With .NET the language choice is more about preference than about one being all that more powerful or better than the other. On the "lighter side" and special update... Java fundamentalist programmers will not give up their jihad against other programming languages and the "great satan" (also known as M$) until the rest of the world is all "Javafied". Interestingly, there are reports that the great "Sun clan" is financing the Java bombardment and encouraging hate speech towards M$. "Its 10:00 AM, have you done some "Java" today?"

Java users = Jihad against C++ and all that is holy. Java and C++ users acknowledge various connections, but war is often inevitable and unavoidable. Assembly is like speaking about monkeys, evolution, or DNA. Talk of it can be tolerated at times, but its not the holy tongue, and excessive mention of it can be like the sin of having impure thoughts. There is a compromise, by the way, like the concept of "intelligent design". The great programmer created Assembly, on his way to creating the blessed language which is C++. Mucking about with Assembly, is like committing unnatural acts or using fetal tissue. Now that there is C++, all must acknowledge its superiority.

First, second, and third: Excerpt from the C++ bible... "On the third iteration the great programmer in the sky typed, "Let there be code", and so it was.... " Oh great /dev/null, thou art all knowing and there can be no others that are wiser, save the other blessed disciples of C++. Oh great priest of C++, /dev/null , forgive my sins and the blasphemy below: 1. When did you code any projects for me or by my request? When? (arrgghhh... that will be 100 hail Marys) 2. At this time, I don't usually use AutoIT for building GUI applications, but for manipulating existing GUIs or as a non-GUI script (Arrrghhhhh..Arghhhh... that will be 300 hail Marys). 3. Limnor has an IDE, so there is no need for me to re-create one for my projects. (Forgive me, for I have typed the name of the Antichrist... ARRRRHHH....ARRRGGHHHHHHH.... that will be 10 lashes of the whip and 1000 hail Marys).

Anti C++ talk is blasphemy and don't you sinners forget it. C++.NET and C# are also the tools of the great satan ( Micro$oft ) to trick you into using .NET. .NET = .SIN, CODELESS based .NET tools = definite SIN, that MONO project for Linux and MACs (and others like it) = Judas, MSIL/CIL ( "Hell spawned" Intermediate Language ) = 666, and designers of .NET = Antichrist . All those other programming languages that have "converted" and created derivatives that work with .NET bear the "marks" of the beast ($ or Micro$oft). By the way, any other language that is not "blessed" by pure C++ is SIN. But "C" is to "C++" as "Judaism" is to "Christianity", thus its use means thou are only partially damned. Objective-C (Obj-C and whatever...) use is like being a misguided Mormon (according to the church of C++ doctrine). Excerpts from the church of C++ bible, "For whomever worship blessed C++ shall have a language which will last forever." "If thou are C++, than thou are righteous and thus can regard all other languages with contempt." "Codeless is another name for Antichrist" "The programming language Forth (click Forth to be transported) burns in the hottest fires of programming Hell" "To speak of Java is sacrilegious." "To utter the word "Assembly" is like swearing. A sin, nevertheless, though considered a small one." All that is not thee one and only "truth" (C++ of course) or a blessed derivative of the sacred language is SIN. Save your programmed souls and repent!!!!

AutoITNOW: Yeah, People have their point of view and I think this debate is not going to change people that have invested years into one way of thinking. Unlike yourself, I think Valik understood what I meant. I'm a technical user that needs to get certain projects done or resolve certain problems. My focus is on getting RESULTS easily and/or quickly, more than the "method" or defending any programming language. A company CEO, IT Manager, company executive, often could care less what programming language is used, if it SOLVES their problem in a cost effective way. They also will fall a sleep on the debate of VBScript versus JScript versus Perl or the debate on C++ versus .NET versus Pascal versus Assembly. Myself and others need to RESOLVE problems makes our view no less or no more valid than any professional programmers. The point of programming languages is not to "worship" them, but to get certain tasks done. You don't have to be a professional programmer to realize that the bottom line is often problem resolution, speed, ease, money, and time. In many cases, but not every case, whatever can help me get the job done with the least amount of trouble is what I'm going to use. Its one of the reasons why I like AutoIT, as well as Limnor. From that perspective and as a user of a programming language, I (and various others) are going to have a different point of view than a professional programmer. Nevertheless, the view of NON-professional programmers, NEW programmers, or Part-time programmers are equally important and even effect the popularity of a programming language. Somebody may be the biggest advocate for using only Assembly, but it does not mean people that are new or part-time programmers will want to follow in his/her footsteps and deal with THOUSANDS of lines of code or do things the "hard way". That was not the point and you know it. I was answering your question about Limnor programmers needing to rely on C++ people to make performers and DLLs. The answer is NO, Limnor programmers don't need to rely on C++ or C#. DLLs and Limnor Performers can be created in numerous other programming languages besides C++, like various versions of Basic or Euphoria. Furthermore, Longflow is coming out with ActiveX DLLs for Limnor, so the Limnor users can make their own DLLs to exchange with each other or other .NET languages. What language you make DLLs in may be based on your preference and you do not have to use C++. Limnor users can CALL DLLs from Limnor, so they can just look around for DLLs made by others and use those (like in AutoIT). Again, you are trying to be funny. You claimed that Limnor was good for little more than making "Kiosks". The "sample applications" demonstrate that you are very wrong, but you persist. You obviously, are still blinded by your bias that you don't realize what you are typing. Limnor can be used for both making DESKTOP Applications AND Applications INSTALLED FROM a CD-ROM. The Desktop/CD-Rom option allows you to this and its purpose is also for how you will INSTALL and distribute your program. The Kiosk option, is for those that are making Kiosks. Limnor is, by the way, one of the world's top application for making Kiosks because it is so EASY to do so(read the press clipings and ratings). As for the number of Limnor users at its site, the website opened in late June. Therefore Limnor's portal/developer website has been open for LESS than 2 MONTHS. Before, Longflow answered users question by e-mail, and STILL DO. The purpose of the additional Limnor website is to start a user Limnor Developer group, allow more advanced Limnor users to test Betas, to allow user to exchange Performers, and to exchange info. I have made programs with Limnor and so have a number of my friends. They have sold those programs for money or use them at their company. I'm not about to get more personal than that. Who else is using Limnor or WHO is using AutoIT is should not be the only criteria for judging the worth and merit of Limor or AutoIT anyway. As for the number of companies or making certain programs in Limnor, that is info. that you can get from LongFlow. You can e-mail Limnor support or (better yet) post your challenge on the Limnor website. Another point is that Limnor actually helps teach and/or generate interest in C# and VB.NET. I find it interesting that you are attacking Limnor for being a not widely accepted language, but are an AUTOIT user. Who accepts and uses the AutoIT language??? Limnor's debugger, error logs, and certain performers show C#/VB.NET code or can make use of C#/VB.NET code. Say what you will about .NET, but its a more widely accepted and used language than AutoIT is. Furthermore, there are projects to port .NET to Linux and MACs, and Limnor programs will run on those OSes too. If you are so good at using C++ than why even bother with AutoIT. If you say you use AutoIT for "ease of use" , to save time, reduce the amount of code you have to write or troubleshoot than you are simply repeating many of the same arguments that can be used for codeless programming languages like Limnor and Imitate. Lastly, if you don't like Limnor than fine, but it does not take away that others find it useful and there are even things that AutoIT "developers" can learn from it. Valik... If the performer is there than yes it will be a happy programming day, if not than all will not be so easy. Unlike what was implied by Dev/null/Kurt, there are a LOT of Limnor performers... for Databases, Arrays, Strings, Logic expressions (also logic expression functionality like IF Then Else is built in to Action and Action Lists), Charts, DLL Caller, Files, FTP, smartcards, etc... The performers are often multi-functional and usually do more than just one simple task, but can be called to do a whole bunch of tasks. Most of the functionality of the Limnor program is the performers themselves. Limnor, can be seen a framework to connect the different performers. How to create what you don't have is a question that would come up for only a small percentage of Limnor users. Let me remind you though, that there are already so many performers that in 95% of the cases they will do anything users at that level will need to do. The situation is similar to that of AutoIT, with the new performers/new features (like UDFs, etc...) are usually going to be used by a small percentage of Power Users. A Limnor user would probably start looking for a DLL that somebody else made, like for many AutoIT users, before thinking about making their own. If the performer does not do what you need, than you can code directly in C# or VB.NET. I think Limnor users would more naturally go in that programming direction because Limnor is .NET based. If for some reason you wanted to create a performer for others to use or for other in your company, than you can use any programming language that can make DLLs. The Software Development Kit (SDK) is free and can be downloaded from Limnors Portal website. The SDK tells you and gives examples on how to turn your DLL into a Limnor Performer. I think the overall net gain is ease of use for certain more complicated GUI based programming tasks. This is why I came up with the 100 to 200 lines of code example. If you just want to put out an easy non-gui based tasks, that is only 25 lines of code than few things would be better than AutoIT. On the other hand IF you are making a quasi-complex GUI based program that interacts with a database and you are a part-time programmer than that is where Limnor would really shine (and that would be the one I would choose). AutoIT could emulate various features of Limnor or Imitate (for Java) if it had a more developed IDE and focused on Autocode generation for assigning event/actions to controls, but that does not seem to be anybody's focus at this time. Overall, its really a question of convenience and preference.

You know as well as I do that you don't have to be the "world's best" programmer to follow logical trends and come to a conclusion. Based on your argument, /dev/null/Kurt, you would have to be a Boxer in order to coach Boxing or train Boxers. What you will actually find in reality, is that coaches and training is another skill set, just like being able to predict trends. Have you ever heard of a the stock market??? Being the best mechanic, does not mean you know how to make money, invent the kind of machines that you are working on, etc... Furthermore its only a prediction and if you disagree than fine but like I stated, "time will tell". I'm only giving you an approximation of the lines of code. Limnor and C++ or C# are two different programming methods, so its extremely difficult to go beyond a guess. With Limnor, your are NOT forced to use C# or VB.NET. I can tell you have not really used the program and I think you don't like "codeless" so you may have developed some bias against it that makes it hard for you to want to understand it. I wonder if you use tool like AutoBuilder, AU3recorder, etc... that autogenerate code for you in AutoIT or do you just type all the code one command at a time. There are actually a lot of performers, you have to download the program and use it to know this. Limnor users do NOT have to rely on C# or C++ programmers. Limnor can use nearly ANY programming language that is able to make DLLs. So Limnor can use VB.NET, different version of Basic, Euphoria, etc.... What is required is that you know how to make a DLL in a programming language. Limnor can also CALL DLLs, like AutoIT. Limnor users can get around having to make DLLs by loading and saving Limnor libraries between them. Similar to AutoIT UDFs, you can import someone else's library into your project and use it for your program. Longflow is also working on a project in which Limnor users can make ActiveX DLLs, like those in Visual Basic (A similar project for AutoIT, may be beneficial for AutoIT users). These Limnor ActiveX DLLs can only be used and exchanged among Limnor users, but they will be very helpful. Furthermore, Limnor has released its SDK (Software Development Kit) for FREE. This is to open the development of performers for the Limnor language and allow free ones to made and exchanged. Limnor is also used far beyond just presentations or Kiosks. If you actually used Limnor you would know what I mean . Limnor also has bunch of example application s at http://www.limnor.com/ then select "downloads" and then "sample applications " Limnor is also an excellent programming language for those that use and make database application, use MS Access, or make applications with Excel. Even more, a Limnor automation performer is rumored to be in the works as well. You stated that you use AutoIT and Perl for Rapid Application Development, because doing the same thing in C++ would be slow. Well, you have just proved part of my whole point. People would use programming languages like Limnor or Imitate (for Java) because they are easier to learn, easier to manage, or its faster to create certain types of programs. Furthermore, you can add in C# or VB.NET code whenever you need to. The type of tasks that you can use codeless languages for will INCREASE in the future, not decrease. I did not say C++ or Assembly would just blow away, but people will find easier methods to do things and ways to bypass having to create a program by creating 20,000 lines of code one command at a time.

I have programmed a bit in Limnor, HLA, and Euphoria. I've bring up only the programming languages that I've some experience in using. But, I"m NOT a professional programmer, I did NOT study programming in college, nor is programming my job and I suspect this is the case for the vast majority of AutoIT, Limnor, etc... users. Furthermore, programming a "medium size" application with 10,000 to 15,000 lines of code in Assembly, C, C++, or even Basic is NOT something that I would want to do, unless I had to. This is WHY, I use programming languages like Limnor, Euphoria, and AutoIT (why are you using AutoIt and not C++???) and this is why so many script languages exist. I'm not into torturing myself or S&M and so are a lot of other people. The largest program that I have wrote in Limnor was about 4,000 lines of code and I estimated this by using a disassembler and checking out the generated pseudo code. Limnor can assign "Actions" and "Action Lists" to GUI controls (a similar approach that I have advocated be done with AutoIT) and MUCH more. By the way, you can add C# and/or VB.NET code to your program too, so your are not forced to just do everything visually. Each Action or Action list can be composed of dozens to hundreds of lines of code in an equivalent .NET program. The neat list of actions and action lists can be further organized by giving them good meaningful names and placed into groups. You can also visually see the logic of your code by using its rudimentary flowchart, which is called Page Map/Application Map. Limnor's approach means that instead of managing thousands of lines of code, you are managing dozens of Action Lists. By the way, the concept of actions assigned to controls is very EASY to teach to non-programmers and part-time programmers. Furthermore, you spend less time on syntax checking and debugging. But if you need to use the debugger, Limnor has that too. The performers (somewhat like AutoIT UDFs) are designed to work together and the code has been tested. In Limnor, things work or they don't, so you are involved in much less troubleshooting. My answer about using Limnor or AutoIT at 100 to 200 lines of code is based on my experience. You may have a different experience or point of view. That is fine. The best way to answer your other questions about the success of Limnor is to go to their websites (did you do that?), download the program and use it (if you want), or e-mail them. I do NOT work for Longflow. If you think Limnor is "junk" than fine, but there are many people AND companies that disagree with you, like using Limnor, and see its growing potential. If you need to know all the people and companies that use Limnor, before you download and try it, than that is your problem. My MAIN point is that there are different approaches to programming and I strongly believe that codeless, auto code generation, compilers that can "translate" from an easier programming language to C/C++, etc... is the future. If you think the future is people and companies typing 15,000 lines of code at one command at at time in C++ than me and you disagree. That is no problem, because we are all entitled to our opinion and only time will be the true "judge" no matter what we type here.

I think Rapid Application Development is not just a "programming language concept" that you write on a whiteboard, but a problem in which various languages are poorly to better suited to resolve. RAD is also a huge business problem as well and many companies are looking for good solutions. Why are people willing to perhaps pay $12,000 (wow...if they pay that much...) a seat for something like AllFusion Gen http://www3.ca.com/Solutions/Product.asp?ID=256 , when there is Visual Studio and all those other programming languages? Something closer to AutoIT, why will people pay so much for AutoMate (which is mostly codeless, but can use Basic) http://www.networkautomation.com/automate/...dirfrom=unisyn& when there is AutoIT or C++ around. RAD has to be a design goal of a programming language in order for it to be addressed adequately. Designing for RAD can lead down the path of faster, more efficient, easier, etc.... Not designing for RAD can arguably lead down the path of difficult to learn, eccentric, etc... You may design a language that is the most efficient in terms of size of code, execution speed, and can be technically superior to all other languages but if its difficult to use, hard to learn, impractical, etc... than people may defect or prefer a different language. I think RAD is in the middle of that decision on how useful a language will be to many people. How many people are going to use a technically superior language that is hard to learn and produces apps slowly versus a technically inferior language that is easy to learn and produces similar apps quickly? Is just another question, among many that will make this argument go round and round. Also, the tools that come with the programming language are important too. What makes "AutoIT" are tools like AutoITMacroGenerator, AU3recorder, AutoBuilder, etc.... These types of tools AUTO Generate code, in concept this is not too different than what the codeless people are doing with their program's IDE. The difference is that with auto code generation, you can go and edit the code in a program like SciTe. This is perhabs a path that AutoIT should explore more, as it can be argued that auto code generation can be the best of BOTH worlds (code and codeless) combined. Without such auto generating code tools, would AutoIt be so popular??? I argue that it would NOT. In the same way one programming language may be superior to another, but the less technically advanced language may provide numerous "ease of use" tools that move users to decide on using it. This may work in reverse too, where the more complicated programming language offers better TOOLs like a better IDE, so that this becomes a factor on what users decide to use. You can add all kinds of advanced commands and syntax in the programming language for elite users, but if your help guides, IDE, or your language lack tools to exploit these advance commands than many other users may not get any benefit out of the language's "technical superiority". Losing sight of the user interfaces, tools, and IDEs for creating applications by that programming language is an issue like RAD is. People are looking for and "paying through the nose" for "ease of use tools" and RAD. When it comes to Limnor, Euphoria, Imitate, etc... people are spending good money on those programs. Why is that??? Why don't they just use C++ or Assembly, code every line, or make their own programs? I think the answer is RAD and "Ease of use" Tools. This need for RAD and "Ease of use" will continue to "fuel" more and more development in those programs. As for the other stuff, at this point, I would say it is time to "agree" that we "disagree". Nothing wrong with that. Obviously, we can't "force" everyone to see the world from our own perspective. So we each will have to search for our own "truth". Time will be the true "judge" in all of this. Time will eventually shed more light on what directions programming in the future will go and the future of codeless, automation and/or programming languages adding more automation features, AutoIt, C/C++, .NET, HLA, etc... will be revealed as well. As for Limnor, I think the best "defender" of the language would be David Ge (I think he does a great job answering questions). You could contact info@limnor.com or support@limnor.com and they/he will give a blow by blow in the most excruciating detail. If you so desire, you could also post comments at their brand new developer site ( http://limnorcommunity.jrwebb.net/news.php ), where David Ge often frequents. For HLA, that "defender" would be Randall Hyde (I think he is a nice guy) rhyde@cs.ucr.edu . For Euphoria, they have their forum and be prepared for "hardcore" Euphoria users ( http://www.rapideuphoria.com/listserv.htm ). Overall, I see nothing wrong with trying out different approaches and languages and then deciding what is right for you.