Programming languages

[/dev/null]

But, C/C++ is not the end all, because you can write a compiler  to spit out C/C++ code or have a C/C++ compiler translate your programming language to C/C++.  This is being done NOW, by various freeware programming languages.  The ranks of BCX, Euphoria, SpeedBasic, etc.. are only going to increase.

Hm.. what would that be good for? If I want a C/C++ program I would write it in native dialect, instead of having an intermediate compiler create it from BCX, Euphoria, Pascal, ADA, Perl, etc. The only reason to do this is because the languages you mentioned (not ADA, Pascsal) are interpreted and their creators don't want to or are unable to write a compiler for their language.

AND, what's the difference between writing a program in Basic or C? If you know how to program you will be able to use either language, as 85%-90% of the concepts of current procedural programming languages are identical or at least very similar. The difference lies mostly in the library of functions that are provided by your favorite language (string operations, math functions, etc.).

At some point, an easy programming language will use a C/C++ compiler/decompiler.  I do not think this is too far off into the future.  Also, the "me too" factor will only add to the number of projects and programming languages that will be able to do this. 

What will be an easy programming language? How would you measure that? C and C++ ARE very easy, so how much easier can a language become?

If you want a "new" language, then take a look at erlang (www.erlang.org). It's been used by at least one large telco to write reliable systems/programs for their switching equipment. But be warned: Erlang is just another procedural language.

At the point that some version of basic or new language is easier and faster to code in than C/C++ and can compile/decompile to it than many people ARE going to defect.  Yes, C/C++ will still be around, but its popularity will severely decrease.  That "new" language, will be "all the rage".

Can you please give an example what you mean by "easier and faster to code"? I realy don't get the point.

If the programming language is easier to learn, easier to understand, faster to code in, etc... this is not a "bad" thing, but a good thing.  Its like the difference between walking and using a bike or car.  Yeah, you could walk around and code slowly, but why do that when you can get complicated programs finished easier and faster?

That's a good example. Everyone can walk without special training and practice. BUT, if someone just starts using a bike he will not be able to drive as fast as somebody with years of experience. It's the same with programming. You can't be a good programmer without any experience, no matter how good, easys to learn or fast to code your new killer language will be. Going back to your example, it doesn't help you to buy a ultra fast bike as a beginner. You will still be slow!

Limnor and Imitate are here NOW.  There is also a number of other codeless programs out there (but I don't like them).  Does the user care if you spent 6 weeks

I don't really know limnor, but have I just checked their "math example". Well, for me it is looks very complicated to create even a simple porgram. You need to know a lot of internals to get this to work. So, where is the advantage of limnor? It is a lot of work to learn C/C++ BUT it is NOT less work to learn limnor. You learn just other things, like where to click, which objects to create, etc...

working with Visual Studio to make your .net project or used Limnor to spit it out in 6 days?  Why not use Imitate to spit out Java code even faster?  Those codeless programs make it easier and faster to develop programs NOW.  The number of such programs will only increase in the future.

I doubt that you are able to create equally complex programms with limnor and C++. As far as I understand it, limnor is created for a very special class of problems (simple GUI applications), but will fail for a lot of other things. And that's the experience scientists made with any other pure visual programming languages during the last few years. At some point it simply gets too complex to solve certain problem classes with visual programming languages. The matter is constantly evolving and I'm sure there will be some pseudo automatic systems that can create reasonable code sometime in the future. But I beleive that will not happen in the next 5 years.

High Level Assembly is here NOW and version 2.0 is getting closer to its release date.  That means an Assembly language with the power to also use syntax of "higher level languages" as well.  HLA can and will also be used to make compilers and create new "higher level" languages.

HLA? I thought you are looking for an easier to learn and faster to code language. HLA is still assembly, no matter how much "high level" statements HLA gives to the programmer. Have you actually ever programmed in assembly? Well I did "some" programms and I tell it's for sure not easier than C/C++.

There is nothing wrong with programming languages focusing on Rapid Application Development, easy of use, decreased learning time, etc...  In fact, what is the point of AutoIt? 

That's absolutely true. Nothing wrong with RAD. That's the reason why I user perl and recently also AutoIT for windows environments and GUI development.

Why not just code in Assembly?  If somebody takes 6 months to program something in Assembly that he could of used a higher level language to create in 6 weeks or 6 days, does that make him a genius or somebody just torturing himself?

Erm.. I thought you like HLA. Well, HLA IS assembly....

Cheers

Kurt

[Insolence]

All these RAD tools look the SAME, they hardly have a niche. I mean who's going to sit down and learn the entire IDE, and then have it overcome by another one of the dozens of RAD projects? You can just learn C/C++/C# (or hire someone else to do it) and never have to worry about that. Even if a new language comes along and slaps all of these in the face, you'll be ready.

You understand the basic syntax and you've learned how to use the API from the base up. You can switch IDE's and languages like nothing, which is the problem with these little-niche programs.

Also, I have an example:

DreamWeaver, supposed to make developing websites faster. I can develop a website easily two to ten times faster than my teacher, and more attractively too. This is because of my experience and flexibility. As soon as he has to learn how to 'add flash buttons', for example, he's going to have to find a tutorial somewhere and hope for the best. I, on the other hand, can easily learn to add buttons. At most I'll have to google the embed tag, it's a bit hard to remember all the variables along with it, because I know the language.

If you ask me I think VB is the way to go for RAD, although I don't like it at all. I've seen some good stuff come out of it, and I trust it for the most part.

Edited August 5, 2005 by Insolence

[autoitNOW]

Hm.. what would that be good for? If I want a C/C++ program I would write it in native dialect, instead of having an intermediate compiler create it from BCX, Euphoria, Pascal, ADA, Perl, etc.  The only reason to do this is because the languages you mentioned (not ADA, Pascsal) are interpreted and their creators don't want to or are unable to write a compiler for their language.

AND, what's the difference between writing a program in Basic or C? If you know how to program you will be able to use either language, as 85%-90% of the concepts of current procedural programming languages are identical or at least very similar. The difference lies mostly in the library of functions that are provided by your favorite language (string operations, math functions, etc.).

What will be an easy programming language? How would you measure that? C and C++ ARE very easy, so how much easier can a language become?

If you want a "new" language, then take a look at erlang (www.erlang.org). It's been used by at least one large telco to write reliable systems/programs for their switching equipment. But be warned: Erlang is just another procedural language.

Can you please give an example what you mean by "easier and faster to code"? I realy don't get the point.

That's a good example. Everyone can walk without special training and practice. BUT, if someone just starts using a bike he will not be able to drive as fast as somebody with years of experience. It's the same with programming. You can't be a good programmer without any experience, no matter how good, easys to learn or fast to code your new killer language will be. Going back to your example, it doesn't help you to buy a ultra fast bike as a beginner. You will still be slow!

I don't really know limnor, but have I just checked their "math example". Well, for me it is looks very complicated to create even a simple porgram. You need to know a lot of internals to get this to work. So, where is the advantage of limnor? It is a lot of work to learn C/C++ BUT it is NOT less work to learn limnor. You learn just other things, like where to click, which objects to create, etc...

I doubt that you are able to create equally complex programms with limnor and C++. As far as I understand it, limnor is created for a very special class of problems (simple GUI applications), but will fail for a lot of other things. And that's the experience scientists made with any other pure visual programming languages during the last few years.

At some point it simply gets too complex to solve certain problem classes with visual programming languages. The matter is constantly evolving and I'm sure there will be some pseudo automatic systems that can create reasonable code sometime in the future. But I beleive that will not happen in the next 5 years.

HLA? I thought you are looking for an easier to learn and faster to code language. HLA is still assembly, no matter how much "high level" statements HLA gives to the programmer. Have you actually ever programmed in assembly? Well I did "some" programms and I tell it's for sure not easier than C/C++.

That's absolutely true. Nothing wrong with RAD. That's the reason why I user perl and  recently also AutoIT for windows environments and GUI development.

Erm.. I thought you like HLA. Well, HLA IS assembly.... 

Cheers

Kurt

<{POST_SNAPBACK}>

Euphoria's creator has a link and a blow by blow on why Euphoria (an interpreter) is an BETTER and in many areas a more advantageous language than C++. Read here- http://www.rapideuphoria.com/c.htm

Euphoria, BCX, etc... exist because there ARE MANY people that do NOT like C/C++ as a programing language and for various reasons. You should not CONFUSE people being FORCED to deal with C/C++ with TRUE LOVE for C/C++. Many people HATE C/C++, but have to use it, so they do.

A major point is that this "hate" that people have for C/C++ will mean they will find ways to bypass C/C++, by making programs that can compile to it and decompile it. Others will simply avoid it all together, since after all its all about the MACHINE CODE in the final analysis.

By the way, Pascal is a compiled language and is not interpreted. Arguably, just about anything that you can do with C++, you can do with Pascal.

Many people will argue with you that there are some huge differences between programming in C and C++, and even more so between languages like Pascal, Basic, JAVA, etc... versus C++. So saying something like jumping between Basic and C++ is "that easy" is silly. Again, you will come back to the whole preference argument. There are many people that want little to nothing to do with C and C++, and prefer other languages. This is part of the reason why so many other languages exist out there besides C/C++, though C/C++ are "glue" languages for creating many OSes. On the flip, there are people that love all the weirdness about C and C++.

The obvious "middle ground" for many people is to make interpreters so they can program in an easier language and then compile their code into C/C++. Now WHY is that??? Don't blame me or be so angry with me.... I'm not making all these interpreters and new programming languages.

What is AutoIT doing really??? Think about it. If you love C/C++ so much than why even bother with dealing with or creating a different language to do the same things you could have done with C/C++. Obviously, C/C++ is difficult, inefficient (in comparison), creates more lines of code for many programming tasks thus "shortcuts" are needed to deal with the problems.

Now advance the concept of AutoIT further. There are going to people that say, why not easier, faster, and/or more efficient. Eventually, you start talking about coding for GUI apps, etc... eventually, you have to start talking about codeless or eliminating the amount of code necessary to do something.

I don't really know limnor, but have I just checked their "math example". Well, for me it is looks very complicated to create even a simple program. You need to know a lot of internals to get this to work. So, where is the advantage of limnor? It is a lot of work to learn C/C++ BUT it is NOT less work to learn limnor. You learn just other things, like where to click, which objects to create, etc...

I doubt that you are able to create equally complex programs with limnor and C++. As far as I understand it, limnor is created for a very special class of problems (simple GUI applications), but will fail for a lot of other things. And that's the experience scientists made with any other pure visual programming languages during the last few years.

I totally disagree with you. Limnor excels at building medium size applications, complex applications, at having you avoid dealing with code (if you don't want to), and at being easier to understand how to resolve problems.

I use Limnor. At an equal level of programming experience and depending on the programming task, in many cases Limnor will WIN, over traditional methods. You do NOT have to deal and manage 1,000, 5,000, or 10,000 lines of code in Limnor. If you took two newbies in programming and ask them to make a complex program, than the Limnor newbie is going to win. Furthermore, Limnor's method is different than other codeless programs or the codeless features in Visual Studio. Limnor is like using lego blocks or blocks of code to construct a finished program. It also allows you to create performers (think of them as modules or like AutoIT UDFs) to extend the ability of the language. You can create those performers in almost any programming language that you like... including C++. Therefore, like AutoIT, Limnor is about being a shortcut to achieve programming tasks.

Limnor also has a huge potential to be adapted by many companies as their "pet" programming language to create applications. Not because Limnor is the most complex and technically superior language, but because it does Rapid Application Development very well. RAD is important too.

Of course I do agree with your point about the importance of experience and this can make a HUGE difference. But again, the reason why programs like AutoIT or Limnor are around is because you have to manage LESS CODE and deal with LESS complexity. Limnor is FASTER at building programs at a certain size and complexity.

I estimate that Limnor advantage kicks IN from 100 to 200 lines of code, if you used a traditional programming language as a guide. AutoIT is FASTER at building programs at a certain size and complexity. From my experience, I put this at LESS than 100 lines of code and especially if you are making NON-GUI apps (which is why I still use and like AutoIT). Estimating efficiency is harder when you use AutoIT to make GUI apps, and I will just tell you point blank that its easier to make GUI apps and database based applications in Limnor.

People are BUILDING COMPLEX programs with Limnor all of the time and even more... are SELLING THEM and using them commercially. There is a lot of Limnor made apps "sneaking" around. People don't usually get Limnor for a "hobby", they get it to make applications as fast and easy as possible.

Codeless, is not implemented as the complete absence of code, by the way.

Limnor also allows you to directly add VB and C# code. If you want to hand code, to add various features than you can. If you want to see the more advanced version of Limnor than go here- http://limnorcommunity.jrwebb.net/news.php instead of the regular site.

Besides the new developer site, Longflow/Limnor has a lot of behind the scenes development on new performers that might surprise a lot of people when they are released.

As for my opinion, when you deal with a programming language above assembly than its really matter of preference. My preference is for developing small to medium sized applications as fast, easy, and efficiently as possible. I will use "whatever" to do that. Be it AutoIT, Limnor, or Euphoria... I don't believe in complexity, unless it is necessary. If the problem can't be solved in any other way, than I'm all for complexity and I will swim in even extreme complexity until the problem is solved. I just don't believe that complexity to the point of near incomprehension should be design goal for a programming language or something a programmers in that language should brag and feel good about.

I mentioned HLA because it is actually no more complex than C/C++ or Pascal if you want it to be. I've even debated the issue with the creator of the program... HLA higher level syntax was purposely made for C/C++ and Pascal programmers to use HLA as quickly as possible. You do not have to use its lower level Assembly functionality until you want to or are ready to. As an Assembly language, HLA is extremely powerful and can do things that you can not do in C/C++ and/or can create smaller/faster code (especially the upcoming version 2.0). As I mentioned, HLA also has the potential as an excellent programming language to create other languages with.

Overall, I'm saying that there are real alternatives out there and more are coming.

Edited August 5, 2005 by autoitNOW

[condoman]

To add a different spin to this issue you should know that some really big applications do not use these languages directly anyway.

I work in a large company that has hundreds of copies of VS (Visual Studio), but does no coding at all. All the developers work in Computer Associates AllFusionGen (about $12,000 per seat) which will generate code using VS. The client components are generated with VB or VC, the mid tier parts with VC and the mainframe parts are COBOL. Sometimes they are web applications that are generated and sometimes they are client server.

The beauty of this type of development is not in the code but the maintenance of it. Everything is maintained at the business rules level using the proprietary language of AllFusionGen. Changing technologies like to Java is a matter of purchasing a new code generation module. Of course you won't be able to craft a nifty tight routine that will squeeze the best performance out of the platform, but that is not what you are being paid to do.

The best language is the one that will solve the problem at hand. If you like to play with languages as a hobby that is one thing, but earning a living often means something else dictates your choices.

[/dev/null]

Euphoria's creator has a link and a blow by blow on why Euphoria (an interpreter) is an BETTER and in many areas a more advantageous language than C++. Read here- http://www.rapideuphoria.com/c.htm

Hm.. does not convince me. Especially:

--> "# because you are tired of having the machine "lock up", or your program come crashing down in flames with no indication of what the error was"

My answer: If you implement proper error checking this will not happen. If you don't, you deserve what you get.

--> "because your program should not be allowed to overwrite random areas in memory via "wild" pointers"

My answer: Well, you don't have to do that if you don't know how. It's like the old doctor joke: patient: If I do this it hurts. doctor: Then don't do that!

--> "because one time you had this weird bug, where you called a function, that didn't actually return a value, but instead fell off the end and some random garbage was "returned""

My answer: Well, you better know your code or the library you are using. If I pull the brakes on my bike, should I wonder that it does not move??

--> " because portability is not as easy to achieve as it should be"

My answer: Well, is it with Euphoria? Can I run my Euphoria programms on AS/400, AIX, Solaris, MAC OS X, FreeBSD, and many others?

--> "# because you hate it when your program starts working just because you added a debug print statement or compiled with the debug option"

My answer: Good code does not do that.

--> "because you'd rather be running your program, than wading through several hundred pages of documentation to decide what compiler and linker options you need"

My answer: Well, how often do you figure out how your compiler works. I do it once, write a makefile and forget about the rest.

--> "# because very few of your programs have to squeeze every cycle of performance out of your machine. The speed difference between Euphoria and C/C++ is not that great, especially when you use the Euphoria to C Translator. Try some benchmark tests. We bet you'll be surprised!"

My answer: I thought C/C++ is bad? Why rely on a Euphoria to C compiler and wading through several hundred pages of documentation to decide what compiler and linker options you need

--> "because you'd rather not clutter up your hard disk with .obj and .exe files"

My answer: Oh come on. Instead of *.exe I will clutter it with *.whatever. Lame argument.

A major point is that this "hate" that people have for C/C++ will mean they will find ways to bypass C/C++, by making programs that can compile to it and decompile it. Others will simply avoid it all together, since after all its all about the MACHINE CODE in the final analysis.

I really don't get your argument. This whole compile/decompile argumentation is nuisance.

By the way, Pascal is a compiled language and is not interpreted.

I know, that's the reason I wrote: (not Ada,Pascal).

Arguably, just about anything that you can do with C++, you can do with Pascal.

That's true. I did not say that there is anything you can only do with C++, as this would be complete rubbish.

JAVA, etc... versus C++. So saying something like jumping between Basic and C++ is "that easy" is silly.

Well, it's only silly, if you have not enough programming experience. Otherwise it is no problem at all.

The obvious "middle ground" for many people is to make interpreters so they can program in an easier language and then compile their code into C/C++. Now

An interpreter has nothing to do with an easier language! I think your mixing up some things now.

WHY is that??? Don't blame me or be so angry with me.... I'm not making all these interpreters and new programming languages.

I don't and I'm not even a C/C++ envangelist. Actually I don't care what language people use to get their job done.

What is AutoIT doing really??? Think about it. If you love C/C++ so much than why even bother with dealing with or creating a different language to do the same things you could have done with C/C++. Obviously, C/C++ is difficult, inefficient (in comparison), creates more lines of code for many programming tasks thus "shortcuts" are needed to deal with the problems.

You don't get the point. AutoIT and many othe RAD languages are better suited tosolve a special problem than other languages that's the reason why people use them. It's not a BETTER LANGUAGE contest.

I use Limnor. At an equal level of programming experience and depending on the programming task, in many cases Limnor will WIN, over traditional methods. You do NOT have to deal and manage 1,000, 5,000, or 10,000 lines of code in Limnor.

Yes, but then youll have to deal with 1000 "masks" and "objects" (I don't know the exact name in limnor). Where is this any better. Did you actually create a large limnor application, comparable to a 15.000 lines C/C++ programm? If so, and you tell me it's not equally complex to maintain that application I won't believe you.

If you took two newbies in programming and ask them to make a complex program, than the Limnor newbie is going to win. Furthermore, Limnor's method is different

That's for sure true. But I'm talking about larger applications and experienced programmers, not beginners that have virtually no knowledge. For such people, limnor or any other "visual" programming environment might be better.

People are BUILDING COMPLEX programs with Limnor all of the time and even more... are SELLING THEM and using them commercially. There is a lot of Limnor

Can you name three commercial applications that are built with limnor?

EDIT: BTW, what was the largest application you created with limnor?

Cheers

Kurt

Edited August 6, 2005 by /dev/null

[Valik]

Many people will argue with you that there are some huge differences between programming in C and C++, and even more so between languages like Pascal, Basic, JAVA, etc... versus C++. So saying something like jumping between Basic and C++ is "that easy" is silly. Again, you will come back to the whole preference argument. There are many people that want little to nothing to do with C and C++, and prefer other languages. This is part of the reason why so many other languages exist out there besides C/C++, though C/C++ are "glue" languages for creating many OSes. On the flip, there are people that love all the weirdness about C and C++.

This paragraph shows just how little you do know about this stuff. With the exception of of Forth, all the languages I know or can read are very similar in concept design even if they are dissimilar syntactically.

Learning a new language is trivial. Its mostly just learning new syntax and libraries. Programming concepts carry over unless there is a fundamental shift in paradigms between what is known and what is new. All of the languages I know are procedural, or at least offer the ability to write procedural code. C++, of course, is object-oriented in addition to its procedural C roots.

I have no problem sitting down figuring out or writing in a new language I've never used before so long as I can find references to the basics of the language such as syntax, keyword and operators. Its nothing to learn those things. As long as that language's paradigms match something I can readily recognize, I'm good to go. I use Forth again as an example of the opposite. It uses reverse polish notation and I hate it. Its a fundamental shift in design.

I find your statements ludicrous when you say, "<insert language/concept> is here NOW". Well, if its here now, where is it? These things may be "here" but they haven't "arrived".

I don't care what gets you off with programming languages. Use a language of the day for all I care, but please do not go off spouting uninformed and wishful thinking predictions of the future of the programming scene. Reciting bullet-points from a feature list is no substitute for having real knowledge on the subject. I can't tell you the number of times in the software world and read a bullet-point and thought, "Oh, that sounds cool" only to be deflated because the feature was:

• Poorly implemented.
• Wrong is its behavior compared to description.
• Completely missing.

Kurt gives a perfect example quoting those BS points. Just because the author says something doesn't make it reality. I can say from experience that its very easy to get grandiose ideas and have the implementations fall short or never materialize. That happens to every programmer on virtually every project at one point or another. The main thing is how much PR do you try to drum up about it before it fails.

[autoitNOW]

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.

Edited August 6, 2005 by autoitNOW

[/dev/null]

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.

Well, people spend money for junk food and drugs as well. As long as you don't know the motivation of those people you cannot speculate that they do it because it's wise or because the goods they buy are better than others. Your statement implies, that they would not spend money for Limnor, Euphoria, Imitate, etc. if that was crap. Well maybe it is crap and those people just don't realize it. As I said, as long as you don't know their motivation this is all speculation.

For HLA, that "defender" would be Randall Hyde (I think he is a nice guy) rhyde@cs.ucr.edu .

There is no need for a defender here. HLA is just pure assembly with some high level additions to make it easier to begin with. Nothing special here.

Overall, I see nothing wrong with trying out different approaches and languages and then deciding what is right for you.

Absolutely correct. I was saying that from the beginning. I just felt uncomfortable with your attempt to declare Limnor et al as the only possible future.

BTW: There are some questions you did not answer yet, and I'm really curious....

1.) Have you actually programmed in HLA?

2.) Can you name three commercial applications that use limnor?

You told us there are companies using it in commercial application NOW! So, where are they?

3.) What was the largest application you ever built with limnor?

You told us, that limnor kicks in at 100-200 lines of code. Well in my eyes, a medium sized application starts at 10.000 - 15.000 lines of code. Have you done such an application in both limnor and any procedural language? If not, where did you get the information that limnor is better?

Thanks in advance!

Cheers

Kurt

Edited August 6, 2005 by /dev/null

[Guest Xenchou]

This is one of the oldest debates when it comes to programming, which language is best.

Simply put, none of them are, they all have strengths and weaknesses. The reason there are so many languages out there is because they all serve a different purpose, and meet different needs.

The fastest and most powerful language hands down is assembly. Every executable is compiled assembly, so every other language compiles into it, hence anything any other language can do assembly can do as well. The speed comes in from the fact that you control absolutely every aspect of the way your program works you can write it with no overhead.

Take for example AutoIt (since this is the site for AutoIt). When you compile the script it creates an .exe file, which is compiled assembly, so anything you do in AutoIt you can do in assembly. If you wanted to find, for example, if a file is more than a year old with AutoIt you would use the function FileGetTime, which returns an array of 6 variables with the year, month, day, hour, minute, second of the file, then you have to use the _DateDiff function to find the difference between now and then down to the second. Because AutoIt doesnt know what you need the information for it calculates the time difference down to the second, which adds a lot of overhead and slows down the process, perhaps only by nano-seconds, but if you did it a lot and with the overhead of all the other functions it adds up. However if you wrote your own assembly functions then you would just write it to stop calculating after the year and save yourself CPU cycles.

Now, that said, assembly has a LOT of weaknesses as well. It is hard to write, difficult to debug, takes hundreds of lines to do the simplest tasks, and is not portable between different platforms and OSs most of the time. Simply put, you would spend months writing a small application that would only work on some computers.

This is why unless you are doing a very specific job you probably wouldnt use assembly even though it is the best for speed and capability, most companies that really need the speed will just do some inline assembly for routines that get used very frequently and need the speed/power, but the rest of the program in something else.

The weaknesses that assembly had are what spurred the development of other languages, such as C, COBOL, Pascal, Python, Basic, LOGO, and on and on and on. These languages were all designed to make programming easier and less trouble for users, and the source code could be taken from one system to another and compiled there and it would work with only minor modifications. Each group behind each language had a different reason for making that language, and it was developed to fill a void, much like AutoIt was developed to fill a void.

So the question should not so much be what language is best, but what language is best for me or my situation. Myself and am an IS/IT professional, with the task of taking care of various systems. I have worked in several industries, including computer gaming, and I can say without a doubt that none of them fit every application.

In the past two months alone I have written several short programs in AutoIt, C, VB, PERL, Javascript, and KSH. To drive the point home a little more, let me tell you about a recent project I was asked to come up with a solution for. The HR department has a program they use for payroll, and vacation time, and so on. As the company grew it became harder and harder for the HR department to process all the vacation time people were requesting, along with request from people who needed to know how much they had left and so forth.

The data from this application was in a HUGE binary data file, and we had to have limited access to it for several hundred people. After discussing the problems we decided the best way to allow people to access the data was through a single website.

The website itself was written in PERL, which managed the accounts of people, showing them how much time off they had, and allowed them to request days off on a calendar.

Then the HR department used an AutoIt application for the front end/GUI to manage importing and exporting data from their system to the websites. The AutoIt was a quick and easy way to develop a nice GUI that could be easily changed and updated, which is why it was selected for the job.

The AutoIt application then called a series of programs written in C which managed the translation and filtering of data between the large binary data used by the HR system, and the text database used by the PERL system, as C has better speed and capability.

The whole system took about 2 days to write, test, and deploy, because we used the better language for each of the different tasks.

The point is that there is no best language, simply a better language for what you are trying to do.

P.S. In all the posts I never saw a mention of Objective C, a sort of hybrid between C and C++. Personally I really like it, seems a lot cleaner, and with all the OOP abilities as well.

[layer]

Not sure that when you compile your AutoIt scripts it is compiled assembly. I think it has an interperater. :">

[Valik]

Not sure that when you compile your AutoIt scripts it is compiled assembly. I think it has an interperater. :">

<{POST_SNAPBACK}>

layer, I've told you this before. If you don't know about a subject, don't talk about it.

At a high level, AutoIt interprets a script which causes it to invoke various C++ functions. These C++ functions then invoke code written in C++, C or in some rare cases inline assembly (All supported by the C++ compiler, of course). However, what Xenchou said is correct; in reality this is all just machine code which is easily translatable back "up" to assembly.

[layer]

layer, I've told you this before.  If you don't know about a subject, don't talk about it. 

At a high level, AutoIt interprets a script which causes it to invoke various C++ functions.  These C++ functions then invoke code written in C++, C or in some rare cases inline assembly (All supported by the C++ compiler, of course).  However, what Xenchou said is correct; in reality this is all just machine code which is easily translatable back "up" to assembly.

<{POST_SNAPBACK}>

Valik,

I talk about anything I want. It's my right. And I'm using from what I've heard in the past. You know if I didin't post this, you would have told the other guy before me he was wrong But your life goal is to proove me wrong...

Edited August 8, 2005 by layer

[autoitNOW]

Well, people spend money for junk food and drugs as well. As long as you don't know the motivation of those people you cannot speculate that they do it because it's wise or  because the goods they buy are better than others. Your statement implies, that they would not spend money for Limnor, Euphoria, Imitate, etc. if that was crap. Well maybe it is crap and those people just don't realize it. As I said, as long as you don't know their motivation this is all speculation.

There is no need for a defender here. HLA is just pure assembly with some high level additions to make it easier to begin with. Nothing special here.

Absolutely correct. I was saying that from the beginning. I just felt uncomfortable with your attempt to declare Limnor et al as the only possible future.

BTW: There are some questions you did not answer yet, and I'm really curious....

1.) Have you actually programmed in HLA?

2.) Can you name three commercial applications that use limnor?

You told us there are companies using it in commercial application NOW! So, where are they?

3.) What was the largest application you ever built with limnor?

You told us, that limnor kicks in at 100-200 lines of code. Well in my eyes, a medium sized application starts at 10.000 - 15.000 lines of code. Have you done such an application in both limnor and any procedural language? If not, where did you get the information that limnor is better?

Thanks in advance!

Cheers

Kurt

<{POST_SNAPBACK}>

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.

Edited August 8, 2005 by autoitNOW

[Guest Xenchou]

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.

<{POST_SNAPBACK}>

Just a small note, I would be very surprised if the system generated C code, which in turn is going to be converted to assembly when it is compiled. Seems like a long process to provide the same result. It would be best just to compile it straight to an executable (in other words, assembly).

But even if it did do the C first step, that makes it less powerful and slower than native C/C++ code, simply because of the same reason I gave before for the difference between the assembly and AutoIt when getting the time of a file, you are adding extra, unneeded fluff on top of it.

The only way to avoid doing extra stuff that your program doesnt really need to do (again in my example of calculating the file time down to a second when you only need the year) is to get closer to assembly, not further away. The codeless idea may work for some application, that are not too large and can handle slower code.

But again, this all goes back to using the write language for the job. If you want the speed and power use assembly or a C language. If you want something easy (all be it a little sloppy) then use the codeless solution, and if you want something quick and simple then a scripting language like AutoIt.

None of them are wrong, just different.

[Valik]

Valik,

I talk about anything I want. It's my right.

While this is true, one should at least have the dignity to not talk out one's ass about subjects one doesn't know anything about.

And I'm using from what I've heard in the past.

I have the feeling that what you did not understand what you heard and have thus inferred the wrong thing from it. It should of been quite apparent from Xenchou's post that no matter how you get there, pretty much every program is translatable to assembly.

You know if I didin't post this, you would have told the other guy before me he was wrong

Why would I tell somebody who is right that they are wrong assuming I am aware that what they say is correct?

But your life goal is to proove me wrong...

If you would think and ensure that you actually know something on a subject before you open your mouth, this would not be a problem. It grows old after awhile seeing you butt into conversations you are not qualified to be anything more than an attentive listener (reader) to.

Also, just so you can have some sort of an idea just how many times you speak without understanding, I only call you on about one in five times which is a modest number. If I spent all my time calling you out on the number of times you've said something completely ignorant then I wouldn't have much time left to do anything else. Eventually I hope you'll either get the point and stop talking about things you don't understand or you'll get tired of me haranguing you and stop talking about things you don't understand. I'm sure after you read this, though, you'll have the stereotypical obstinate reaction and continue making yourself look like an idiot to the valid partakers in conversation, but as you say, that is your prerogative.

[layer]

I have the feeling that what you did not understand what you heard and have thus inferred the wrong thing from it.  It should of been quite apparent from Xenchou's post that no matter how you get there, pretty much every program is translatable to assembly.

<{POST_SNAPBACK}>

I know that every program can be translated into assembly, but I think that he said the compiled .EXE's are translated into assembly by the AutoIt compiler, which I belive is wrong... Or, I belive this is wrong based on what people have said from that past.

[Valik]

I know that every program can be translated into assembly, but I think that he said the compiled .EXE's are translated into assembly by the AutoIt compiler, which I belive is wrong... Or, I belive this is wrong based on what people have said from that past.

<{POST_SNAPBACK}>

Xenchou said:

When you compile the script it creates an .exe file, which is compiled assembly, so anything you do in AutoIt you can do in assembly.

"When you compile the script it creates an .exe file, which is compiled assembly..."

Not:

"When you compile the script it converts it to assembly..."

[layer]

Xenchou said:

"When you compile the script it creates an .exe file, which is compiled assembly..."

Not:

"When you compile the script it converts it to assembly..."

<{POST_SNAPBACK}>

Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

hhhhhhhhh

Move along folks.

[Wus]

For all the debate that is occuring in this thread I would like to say that I am learning alot through it. So it isnt a wasted effort, it is giving me an introduction to many things that have previously been unknown to me.

/me runs away to never post in this thread again

[JSThePatriot]

For all the debate that is occuring in this thread I would like to say that I am learning alot through it.  So it isnt a wasted effort, it is giving me an introduction to many things that have previously been unknown to me.

/me runs away to never post in this thread again

<{POST_SNAPBACK}>

I can agree it wasnt wasted effort. I am always interested in others opinions even if completely bogus. Gives one something to think about and ponder. As well as I also alway enjoy a good debate, even if I am not a part of it.

I have deposited another 2 cents.

JS