Visual Csharp or autoit?

[acidman]

Autoit is good well actually very great. but the question I have is, is it worth my time rather getting to know visual c# or should I stick with autoit, autoit has quite a few limitations, visual c# has much more functions... but am I using autoit in the right way or is vc# just better??

Because I know what to do with my life now, programming is what I consist of and Developing full on software is what im going to make a living of, so is vc# Better in this case or what?

Edited March 8, 2012 by ac1dm4nner

[Valik]

Because I know what to do with my life now, programming is what I consist of and Developing full on software is what im going to make a living of...

You claim you are going to make a living "developing full on software" yet you feel the need to ask us which language is better for a non-specific task? I think on a scale of one to ready to make a living you are somewhere around chickens.

[danielkza]

C# was meant from the start to be general-purpose language, well suited for most types of projects of all sizes. AutoIt, on the other hand, is much more specific in it's goal as an automation and scripting language. That distinction accounts for the many differences between them, and you should keep that in mind when deciding which language to use for an specific task. But in general, I would say that C# is a more modern language, much better suited for any project beyond of a reasonable size, and you'll find orders of magnitude more opportunities for work using it than you would with AutoIt.

Even if that was not the case, I'd still say you should learn C# (or any analogue) anyway due to it being mainly an object-oriented, strongly-and-statically typed language, while AutoIt is purely procedural and dynamic language. If you want to become a better programmer you should familiarize yourself with all the existing approaches to programming, and use that knowledge to write better code in whatever language you'll be using for a particular project. When you understand the underlying concepts picking up new languages is much easier, a matter of learning the syntax, conventions and libraries. C#, for instance, is considered "Microsoft's Java". Most of the practices and overarching notions are common to both languages. So by learning either of them, you can apply much of your newly-gathered experience to the other.

Even an AutoIt project can benefit from some of the tenants of Object-Oriented Programming, like encapsulation, separation of concerns and polymorphism, despite them not being directly expressed in the language syntax. You should never restrict yourself to a single language. The range of problems that a programmer / software engineer / computer scientist / etc can tackle is too large for a single toolset or paradigm to cover satisfactorily.

Edited March 9, 2012 by danielkza

[jchd]

I'd add that before looking too closely at programming languages themselves, there are basic knowledges you need whatever your choices are. Understanding algorithms, fundamental data structures and their vertues/weaknesses is a good start that will help you in all cases.

For instance, an invariant is an invariant irrespective of the context.

[DelStone]

I have found that it can be sometimes frustrating using Autoit given it is quite new and it is not that widespread. When you hit problems and issues, sometimes solutions can be thin on the ground - or if you want to use APIs, other more established languages can get you up and running a little more quickly... as most companies don't seem to consider Autoit at all in their interfaces when they provide examples of code.

Finally if you need to employ someone on a larger project, it can be difficult finding someone with Autoit skills - also an issue when it comes to finding work as most clients tend to want developments in java, c#, vb etc my £0.02 worth...

[BrewManNH]

I have found that it can be sometimes frustrating using Autoit given it is quite new and it is not that widespread. When you hit problems and issues, sometimes solutions can be thin on the ground - or if you want to use APIs, other more established languages can get you up and running a little more quickly... as most companies don't seem to consider Autoit at all in their interfaces when they provide examples of code.

You do realize this is mostly BS right?

AutoIt in its various versions has been around since 1999, about the same time C# was created.

There are a lot of places using AutoIt3, look at the thread AutoIt sightings in Chat to see examples of where it's being used.

They usually don't provide Delphi or Python examples either, does that make them any less valid?

The support for AutoIt is very good, there's this forum and several others in other languages that support it extensively, usually by the users with a lot of help from the Devs. It is a bit like Linux support, it's free so you get out of it what you put into it.

[DelStone]

Thanks for your kind comment - but I did post my personal experience and not "a wiki article" style factual statement. The earliest stuff I saw on it was 2004 which made it newish for me - even 1999 is newish when you compare it to stuff like C which I have worked with.

If you look at some of my queries and the lack of solutions in any of the forums or the net or responses, you may find that "sometimes solutions can be thin on the ground" is quite accurate.

Maybe you want to look at well known interfaces like Facebook's Graph API which provides examples in php or java but nothing in Autoit (or as you rightly say python etc) - it does prove my point "as most companies don't seem to consider Autoit at all in their interfaces when they provide examples of code." and "if you want to use APIs, other more established languages can get you up and running a little more quickly" whereby Java would get you up and running more quickly - the API/UDF etc would have to be developed pretty much from scratch as noone has done it in Autoit.

All in all, I'm not sure what definition you use of "mostly" however I would contend that "mostly" my comment holds true

[BrewManNH]

Thanks for your kind comment - but I did post my personal experience and not "a wiki article" style factual statement. The earliest stuff I saw on it was 2004 which made it newish for me - even 1999 is newish when you compare it to stuff like C which I have worked with.

Not trying to start a flame war, but 1999 is 13 years ago, that's a lifetime in the software world. As I stated, C# was released in 1999 or 2000, not 100% sure which, same age so is C# quite new too?

If you look at some of my queries and the lack of solutions in any of the forums or the net or responses, you may find that "sometimes solutions can be thin on the ground" is quite accurate.

Depends on what you're trying to do, what it is might be impossible in AutoIt which would get you no answers. It might be impossible in any number of languages to do what you're asking I don't know because I haven't researched what you've asked in the past. Most questions that are asked that can be answered are answered as long as they don't violate this forum's rules. I've seen some users here go far above and beyond telling someone to RTFM (and most of the time the person asking the question should have before asking a simple question) and creating a whole script for them to demonstrate how to do it, or writes the whole script for the person asking.

Maybe you want to look at well known interfaces like Facebook's Graph API which provides examples in php or java but nothing in Autoit (or as you rightly say python etc) - it does prove my point "as most companies don't seem to consider Autoit at all in their interfaces when they provide examples of code." and "if you want to use APIs, other more established languages can get you up and running a little more quickly" whereby Java would get you up and running more quickly - the API/UDF etc would have to be developed pretty much from scratch as noone has done it in Autoit.

All in all, I'm not sure what definition you use of "mostly" however I would contend that "mostly" my comment holds true

There may not be snippets made for AutoIt to use an API, but there's usually someone here who has a way of interpreting the code they do show and converting it to AutoIt. Most of the time, someone already has done the wrapper code for it and it's sitting in the Example Scripts section hidden away on page 3400.

[DelStone]

Not trying to start a flame war, but 1999 is 13 years ago, that's a lifetime in the software world. As I stated, C# was released in 1999 or 2000, not 100% sure which, same age so is C# quite new too?

I know people who have spent a lifetime in software - 13 years is not a lifetime. They go back to COBOL and VDUs and punched cards. C# is quite new. C is not imo.

Depends on what you're trying to do, what it is might be impossible in AutoIt which would get you no answers.

What I am doing or asking is achievable and not impossible. The problem often is the breadth of experience collectively does not exist as it does with other languages - where one can often post problems and others have come across them too so can provide a solution from experience... that happens here at times, but often not. Which takes us back to my previous comment.

There may not be snippets made for AutoIt to use an API, but there's usually someone here who has a way of interpreting the code they do show and converting it to AutoIt. Most of the time, someone already has done the wrapper code for it and it's sitting in the Example Scripts section hidden away on page 3400.

Maybe - but in this instance, I'm 99.999% sure there is no UDF or snippets created for the Graph API when I looked some months back and I did trawl through the example scripts (some good stuff in there!) - as such, I've had to create a set from scratch. Had I used a different language (silly me for not doing so!) this aspect of the project would have been speeded up...

[DelStone]

Don't get me wrong - I like Autoit and find it easy to use, a good community, helpful admins and great to teach newbies how to program. I'd hate to have to teach most other languages and platforms. However I pointed out some shortcomings, which no doubt would also exist if I had to do a similar exercise for pretty much any other development lang / platform...

[Mat]

You are asking for "Breadth of Experience", on a forum attended by the people who write the language... How much more experience would you like? You are right that there won't be wrappers for all libraries on demand though.

The best thing to do is to know enough languages to a good enough standard that you can pick and choose dependent on the problem at hand. I do this already with AutoIt, C# and C. Between those three I always have an easy choice of which to pick to make my life easier in the long run. Don't discount AutoIt so quickly though. Just because you know other, more mainstream, languages, doesn't take away the great things AutoIt has going for it.

[DelStone]

It's difficult for a small number to achieve "collective" breadth of experience in relation to different problems, uses and applications of a general language Mat. I'm not knocking any of the developers - they are v impressive from what I've seen of their stuff - the point however is about the broader experiences, insights and perspectives a larger collective can bring as opposed to a smaller collective...

[JohnOne]

What I hear when I read you posts is that not as many people use Autoit as they do C# or C.

That's a no brainer.

But if you are talking about APIs then you can usually see from a c or vb example how to implement

it in Autoit.

two people at the same level of knowledge in their respective languages would wrap an API

with the same degree of ease or difficulty.

it seems you are using those sort of comments that cannot be argued with (I cant remember the name for them).

[DW1]

I would say start with AutoIt. Lots of friendly help available here.

Nothing is stopping you from learning additional languages in the future.

I found AutoIt really easy to work with when I first started out with it, which is why I liked it. But if you are like me, as you start to dive in to more complex projects, you post questions on this forums and start finding that AutoIt can do a LOT more than you (I) initially thought. That's really what I like about AutoIt; somebody completely new to scripting can create an application rather quickly considering the learning curve of most languages, yet once you dive in to it, you will find it is capable of very complex, advanced, operations (might not be the word I'm looking for).

In less words, and more sense; AutoIt is easy to pick up for an amateur/new script writer while still offering the power advanced users will need.

Edited March 10, 2012 by danwilli

[danielkza]

One of the things I do not like about AutoIt (I do like much about it though) is that it is not a language that encourages writing concise, well structured and encapsulated code. The lack of syntactic support for things like arbitrary data structures, exception handling and modularization makes it harder to write maintainable projects beyond a small size.

A very illustrative example, that often shows up in my code and that makes writing 'bad' code much more tempting, is passing of state to functions meant to operate on data, an object-like pattern if you'd rather call it that. The problem is not that AutoIt is purely procedural: it's not very hard, for example, to write a set of functions in C that manipulate a pre-defined data structure that is possibly opaque to the client. But that coupled with the lack of support for custom datatypes forces you to write things like these to try to inject a modicum of sanity into your code:

Global Enum $Application_Folder = 0, _
            $Application_Executable, _
            $Application_IconFile, _
            $Application_IconIndex, _
            $Application_End

Func Application_Create()
    Local $Application[$Application_End]
    # ...
    Return $Application
EndFunc

Func Application_DoStuff(ByRef $Application, $Data)
    If Ubound($Application, 1) < $Application_End Then Return SetError(1, 0, False)

    Local $Folder = $Application[$Application_Folder]
    Local $IconFile = $Application[$Application_IconFile]
    # ...
EndFunc

If you choose to keep the elements in your pseudo-datatype opaque you need to provide your own acessor functions. If you don't you pretty much eschewed any guarantee of encapsulation, since you were forced to give out implementations details. Using a global array accessed by opaque handles helps only partially, with the cost of possibly introducing a relevant deal of complexity in managing insertion, search and resizing, and possibly severely reducing flexibility by making the code non-reentrant.

Such characteristics make using AutoIt for large projects very uninteresting from a maintenance and code quality standpoint. In a nutshell, you can write great code in AutoIt, but it won't make it easy on you. And even knowledgeable programmers are prone to writing 'bad' code if pushed enough.

[Shaggi]

One of the things I do not like about AutoIt (I do like much about it though) is that it is not a language that encourages writing concise, well structured and encapsulated code. The lack of syntactic support for things like arbitrary data structures, exception handling and modularization makes it harder to write maintainable projects beyond a small size.

A very illustrative example, that often shows up in my code and that makes writing 'bad' code much more tempting, is passing of state to functions meant to operate on data, an object-like pattern if you'd rather call it that. The problem is not that AutoIt is purely procedural: it's not very hard, for example, to write a set of functions in C that manipulate a pre-defined data structure that is possibly opaque to the client. But that coupled with the lack of support for custom datatypes forces you to write things like these to try to inject a modicum of sanity into your code:

Global Enum $Application_Folder = 0, _
            $Application_Executable, _
            $Application_IconFile, _
            $Application_IconIndex, _
            $Application_End

Func Application_Create()
    Local $Application[$Application_End]
    # ...
    Return $Application
EndFunc

Func Application_DoStuff(ByRef $Application, $Data)
    If Ubound($Application, 1) < $Application_End Then Return SetError(1, 0, False)

    Local $Folder = $Application[$Application_Folder]
    Local $IconFile = $Application[$Application_IconFile]
    # ...
EndFunc

If you choose to keep the elements in your pseudo-datatype opaque you need to provide your own acessor functions. If you don't you pretty much eschewed any guarantee of encapsulation, since you were forced to give out implementations details. Using a global array accessed by opaque handles helps only partially, with the cost of possibly introducing a relevant deal of complexity in managing insertion, search and resizing, and possibly severely reducing flexibility by making the code non-reentrant.

Such characteristics make using AutoIt for large projects very uninteresting from a maintenance and code quality standpoint. In a nutshell, you can write great code in AutoIt, but it won't make it easy on you. And even knowledgeable programmers are prone to writing 'bad' code if pushed enough.

This. Whats more is that if you choose to do it "object" oriented, you quickly get stopped as no functionality for mimicking inheritence or objects inside objects, as arrays can't hold anything abstract without retrival of said creates a copy. Better containers would help.

But on the other hand, when these critiques of Autoit flows out, people usually defend autoit with being an windows-only automation scripting language. So, use it like so, and learn a structured language for anything bigger. Will help you in the long run.

Edited March 11, 2012 by Shaggi

[acidman]

Ok so I started with a small scripting langauge many may know called autohotkey, it was good for a while but it had too many limitation, then I discovered autoit.

These two languages has taught me a lot... I'm really still a noob but for some reason I can figure out syntax quite easily, I've mastered autoit quite a bit i'd say but not as much as I should And I Agree, yes it's good to start autoit when learning to program, but I went through csharp and its way more advanced in the aspect of functions, like you dont have find custom udfs to implement a function not included in autoit. But I say thanks to autoit it has taught me well.. basically all that I know thta'll help me with c#