choosing versioning software - system

I work on windows and I need a very simple version track software to be able to check in/out a folder project, no matter what's inside. I downloaded few programs, but most of them are very complicated, team work, cloud, thousands of options, etc.
I need some simple version track of my files, locally. Can you recommend me something useful?

i'd recommend using simpy rar with datetime. Or as an option - just parameter to update archive instead of creating new one

There are a number of reasons why version control software have the number of options that they do, without understanding the basics of how the particular version control system that you are trying to use functions these options can seem overwhelming. To be able to use version control you will have to put in a little bit of effort to understand how it works. That being said I find that Bazaar from Canonical makes a pretty good introduction to version control for beginners. It has a pretty nice download page for various platforms and comes with a GUI client and comes with beginner friendly documentation.
However, having used other version control systems I personally don't like to use Bazaar. The choice of version control system should not make a difference if you are only looking to use it yourself and don't need any of the more advanced features. If you are willing to invest some more time however, I would recommend trying Mercurial it has some documentation for beginners and a fairly nice beginner friendly GUI for Windows in the form of EasyMercurial.

Related

How to create an online rebol console?

Where can I find the code for creating an online rebol console like the one here ?
http://tryrebol.esperconsultancy.nl/
Update: for the sandbox system on the server, can't Rebol manage it itself with some security wrapper and its security options ?
As for console itself, I don't know Ruby so I don't want to use TryRuby and why would I need it ? Can't I mimic Rebol console itself by "remoting" it somehow ? Why RT or Esper Consultancy can't make an opensource version ? There's no value in keeping it closed source. Rebol needs to prove it's more open than in the past.
In my opinion, you should aim higher with something like the already open-sourced Try Ruby. You'd type in expressions and it would guide you. Their showcase site is at tryruby.org and is fairly slick.
I modified TryRuby to work with Rebol and it wound up looking like this:
But I'm not going to run it on my server because I didn't want to belabor the necessary sandboxing/etc. or protections against someone running an infinite loop. I can give you what I've got so far if you want it.
I started a tutorial script here that no one seemed interested in helping me with, so I wandered off to other tasks:
http://www.rebol.net/wiki/Interactive_tutorial_script
I'm not sure what exactly you want. You mention you want a remote REBOL shell instead of a tutoring setup, but that's what the Try REBOL site is. There are several reasons it's not open source:
It's in heavy development. I'm currently changing the code regularly.
So it's not in a release state. Preparing it for release, documenting and publishing it would take a lot of extra work, as with most projects.
It's written in my CMS that's also in heavy development. Even if the Try REBOL site were open source, it wouldn't run. The CMS is not planned to be open sourced soon.
It's not meant as a generic REBOL remoting tool, but as a one-off demo site. If that site is running, what's the use of more of them?
As others have answered, there are many generic solutions for remoting that you could use. Also, most parts of the Try REBOL site are readily available as open source:
Syllable Server, produced and published by us.
The Cheyenne web server.
The HTML source of the web client can be viewed, including my simple JavaScript command service bus.
Syllable Server is an essential part of the site, as the sandboxing is not done with REBOL facilities (except some extra limits in the R3 backend), but with standard Linux facilities.
A truly air tight (do I mean silica tight?) sandbox is close to impossible with R2.
R3 (still in alpha) is looking a lot more promising. The deep technical discussions in flight right now (see Cure code and AltME/REBOL3 Proposals regarding unwinds and protect and even occasionally mentioning sandboxes should lead to an excellent sandbox capability.
Right now, the big advance R3 has that makes Kaj's tryREBOL possible is R3's secure policy settings which make it possible (with some careful wrapper code) to construct an alpha/demo sandbox.
To answer your precise question("where can I find code...", you could try asking Kaj for his :)
I'm new to StackOverflow. I'm not sure if this is going to end up as a reply to your comment, or as a new answer.
The somewhat common idea that any project can be open sourced and contributed to by others is a naive view. In the case of my Try REBOL site, it makes no sense. It's not just in heavy development; it's written in a CMS that's also in heavy development. Basically noone could contribute to it at this point, because I'm the only one who knows my CMS. Or in any case its newest features, which I develop by developing Try REBOL, and other example sites. So developing Try REBOL means developing the CMS at the same time, and by definition, I'm the only one who can do that.
More generally, my projects are bleeding edge, innovative technology with a strong vision. The vision is mine, and to teach it to others, I have to build it to show how I intended it to work. So there's a catch 22: to enable others to contribute, I have to finish my projects first, because people typically don't understand them until I show them how they work.
There certainly are other projects where mass contribution makes more sense. Still, only the top projects get the contributors. We found that out the hard way. We created Syllable Desktop and Syllable Server with surrounding infrastructure for contributions. These are fairly classic, well understood operating systems that many people could work on in parallel. However, despite years of begging, we get very few contributions.
So, if you feel a burning need to contribute to our projects, please pick one of the many tasks in Syllable to execute. :-)

Why use an IDE? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
This may be too opinionated, but what I'm trying to understand why some companies mandate the use of an IDE. In college all I used was vim, although on occasion I used netbeans for use with Java. Netbeans was nice because it did code completion and had some nice templates for configuration of some the stranger services I tried.
Now that my friends are working at big companies, they are telling me that they are required to use eclipse or visual studio, but no one can seem to give a good reason why.
Can someone explain to me why companies force their developers into restricted development environments?
IDE vs Notepad
I've written code in lots of different IDEs and occasionally in notepad. You may totally love notepad, but at some point using notepad is industrial sabatoge, kind of like hiring a gardener who shows up with a spoon instead of a shovel and a thimble instead of a bucket. (But who knows, maybe the most beautiful garden can be made with a spoon and a thimble, but it sure isn't going to be fast)
IDE A vs IDE B
Some IDE's have team and management features. For example, in Visual Studio, there is a screen that finds all the TODO: lines in source code. This allows for a different workflow that may or may not exist in other IDEs. Ditto for source control integration, static code analysis, etc.
IDE old vs IDE new
Big organizations are slow to change. Not really a programming related problem.
Because companies standardize on tools, as well as platforms--if your choice of tools is in conflict with their standards then you can either object, silently use your tool, or use the required tool.
All three are valid; provided your alternative doesn't cause other team-members issues, and provided that you have a valid argument to make (not just whining).
For example: I develop in Visual Studio 2008 as required by work, but use VS2010 whenever possible. Solutions/Projects saved in 2010 can't be opened in 2008 without some manual finagling--so I can't use the tool of my choice because it would cause friction for other developers. We also are required to produce code according to documented standards which are enforced by Resharper and StyleCop--if I switched to a different IDE I would have more difficulty in ensuring the code I produced was up to our standards.
If you're good at using vim and know everything there is to know about it, then there is no reason to switch to an IDE. That said, many IDEs will have lots of useful features that come standard. Maintaining an install of Eclipse is a lot easier than maintaining an install of Vim with plugins X, Y, and Z in order to simulate the same capabilities.
IntelliSense is incredibly useful. I realize that vim has all sorts of auto-completion, but it doesn't give me a list of overloaded methods and argument hints.
Multiple panes to provide class hierarchies/outlines, API reference, console output, etc.. can provide you more information than is available in just multiple text buffers. Yes, I know that you have the quickfix window, but sometimes it's just not enough.
Compile as you type. This doesn't quite work for C++, but is really nice in Java and C#. As soon as I type a line, I'll get feedback on correctness. I'm not arrogant enough as a programmer to assume that I never make syntax errors, or type errors, or forget to have a try/catch, or... (the list goes on)
And the most important of all...
Integrated Debuggers. Double click to set a break point, right click on a variable to set a watch, have a separate pane for changing values on the fly, detailed exception handling all within the same program.
I love vim, and will use it for simple things, or when I want to run a macro, or am stuck with C code. But for more complicated tasks, I'll fire up Eclipse/Visual Studio/Wing.
Sufficiently bad developers are greatly assisted by the adoption of an appropriately-configured IDE. It takes a lot of extra time to help each snowflake through his own custom development environment; if somebody doesn't have the chops to maintain their own dev environment independently, it gets very expensive to support them.
Corporate IT shops are very bad at telling the difference between "sufficiently bad" and "sufficiently good" developers. So they just make everybody do the same thing.
Disclaimer: I use Eclipse and love it.
Theoretically, it would decrease the amount of training needed to get an unexperienced developer to deal with the problems of a particular IDE if all the team uses that one tool.
Anyway, most of the top companies don't force developers to use some specific IDE for now...
I agree with this last way of thinking: You don't need your team to master one particular tool, having team knowledge in many will improve your likelyhood to know better ways to solve a particular roblems.
For me, I use Visual Studio with ReSharper. I cannot be nearly as productive (in .Net) without it. At least, nobody has ever shown me a way to be more productive... Vim, that is great. You can run Vim inside of Visual Studio + R# and get all the niceties that the IDE provides, like code navigation, code completion and refactoring.
Same reason we use a hammer to nail things instead of rocks. It's a better tool.
Now if you are asking why you are forced to use a specific IDE over another, well that's a different topic.
A place that uses .NET will use Visual Studio 99% of the time, at least that's what I've seen. And I haven't found anything out there that is better than Visual Studio for writing .NET applications.
There is much more than code completion into an IDE:
debugging facilities
XML validation
management of servers
automatic imports
syntax checking
graphical modeling
support of popular technologies like Hibernate, TestNG or Spring
integration of source code management
indexing of file names for quick opening
follow "links" in code: implementation, declaration
integration of source code control
searching for classes or methods
code formatting
process monitoring
one click/button debugging/building
method/variable/field/... renaming
etc
Nothing to do with incompetence from the programmers. Anybody would be A LOT less productive using vim for developing a big Java EE application.
How big were you projects at college? A couple of classes in a couple of files? Or rather a couple of hundreds of classes in a couple of hundreds of files?
Today I had the "honor" of looking at a file in a rather large project where the programmer opted to use vi (yes vi, not vim) and a handcrafted commandline compiler call (no make). The file contained on function spanning about 900 lines with a series of if-else-if-else-constructs (because that way you have all your code in one place!!!!!!). Macho-Programmer at his finest.
OK there are very good reasons for enforcing a particular toolset within a production environment:
Companies want to standardize everything so that if an employee leaves they can replace that person with minimal effort.
Commercial IDEs provide a complex enough environment to support a single interface for a variety of development needs and supporting varying levels of code access. For instance the same file-set could be used by the developer, by non-programmers (graphics designers etc.) and document writers.
Combine this with integrated version control and code management without the need of someone learning a particular version control system, all of a sudden IDEs start to look nicer and nicer.
It also streamlines maintenance of build systems in a multi-homed environment.
IDEs are easier to give tutorials to via phone or video, and probably come with those.
etc. etc. and so forth.
The business decision making behind enforcing a standardized environment goes beyond the preference of a single programmer or for that matter perhaps the understanding of the programming team.
Using an IDE helps an employee to work with huge projects with minimal training. Learn a few key combos - and you will comfortably work with multi-thousand-file project in Eclipse, IDE handles most of the work for you under the hood. Just imagine how many years of learning it takes to feel comfortable developing such projects in Vim.
Besides, with an IDE it is easy to support common coding standards across the entire team: just set a couple of options and an IDE will force you to write code in a standardized way.
Plus, IDE gives a few added bonuses like refactoring tools (especially good in Eclipse), integrated debugging (especially good in Visual Studio), intellisense, integrated unit tests, integrated version control system etc.
The advantages and disadvantages of using an IDE also greatly depends on the development platform. Some platforms are geared towards the use of IDEs, others are not. As a rule of thumb, you should use IDE for Java and .Net development (unless you're extremely advanced); you should not use IDE for ruby, python, perl, LISP etc development (unless you're extremely new to these languages and associated frameworks).
Features like these aren't available in vim:
Refactoring
Integrated debuggers
Knowing your code base as an integrated whole (e.g., change a Java class name; have the change reflected in a Spring XML configuration)
Being able to run an app server right inside the IDE so you can deploy and debug your code.
Those are the reasons I choose IntelliJ. I could go back to sticks and bones, but I'd be a lot less productive.
As said before, the question about using an IDE is basicaly productivity. However there is some questions that should be considered by the company when choosing a specific IDE. that includes:
Company culture
Standardize use of tool, making it accessible for all developers. That easies training, reduces costs and improve the speed of learn curve.
Requirements from specific contract. As an example, there are some development packages that are fully supported (i.e. plugins) by some IDE and not by anothers. So, if you are working with the support contract you will want to work with the supported IDE. A concrete example is when you are working with not common OS like VxWorks, where you can work with the Workbench (that truely is an eclipse with lot of specific plugins for eclipse).
Company policy (and also I include the restriction on company budget)
Documentation relating to the IDE
Comunity (A strong one can contribute and develop still further the IDE and help you with your doubts)
Installed Base (no one wants to be the only human to use that IDE on the world)
Support from manufacturers (an IDE about to be discontinued probably will not be a good option)
Requirements from the IDE. (i.e. cross platform or hardware requirements that are incompatible with some machines of the company)
Of course, there is a lot more. However, I think that this short list help you to see that there is some decisions that are not so easy to take, when we are talking about money and some greater companies.
And if you start using your own IDE think what mess will be when another developer start doing maintenance into your code. How do you think will the application be signed at the version manager ? Now think about a company with 30+ developers each using its own IDE (each with its own configuration files, version and all that stuff)...
http://xkcd.com/378/
Real programmers use the best tools available to get the job done. Some companies have licenses for tools but there's nothing saying you can't license/use another IDE and then just have the other IDE open to copy/paste what you've done in your local IDE.
The question is a bit open-ended, perhaps you can make it community wiki...
As you point out, the IDE can be useful, or even a must have, for some operations, like refactoring, or even project exploring: I use Eclipse at my work, on Java projects, and I find very useful to get a list of all occurrences of the usage of a public method or a class in a project. Likely, I appreciate to be able to rename it from where it is defined, and having all these occurrences automatically updated.
The fact I have the JavaDoc displayed when hovering over a name is very nice too. Like autocompletion, jump to a class name, etc.
And, of course, debugging facilities...
Now, usage of Eclipse isn't mandatory in our shop! Some years ago, some people used the Delphi IDE (forgot its name), I tried NetBeans, etc. But I think we de facto standardized on Eclipse, but it was a natural evolution rather than a company policy. And we often just open files in a text editor when we need a quick update...

Which TextEditor is easiest to customize for a new scripting language?

It's been more than an year that i'm developing a new scripting language with its own grammar rules and constructs.
I'd like to give the users of this language some minimalistic ide to work with, but i don't want/have time to make one from scratch so i'd like to take one already existing (it has to run on Linux platforms natively, so no windows-only editors plz) and customize it.
Well, which one is the easiest to customize without changing the source code and recompiling it, maybe even with plugin support?
Thank you.
UPDATE
I don't need to know which editor is the best for you, i need to know which one is the easiest to customize AND, most of it, which one has the most complete documentation about new language customization.
Ex: SciTE is good, but its documentation about custom grammars is really poor.
Have you looked into Scintilla/SciTE? I think it gets used often for this sort of thing. It's very lightweight, but from what I understand, is easy to add functionality to. It's not really an IDE, but it's more of a text-editor component that you could use as the basis for a simple IDE. I've used SciTE, which is a sort of demo text editor of Scintilla's capabilities. It's simple, but also quite fast and responsive.
I suppose another option would be to write plugins for existing IDEs such as Eclipse or Netbeans. Both of these IDEs support many languages just through 3rd-party plugins. Going this route means you don't need to build a complete UI, just the components needed to make your language work.
The downside of building plugins for an extendable IDE (such as NetBeans or Eclipse) is that you are at the mercy of the IDE developers. If they change the way the platform works, you must ensure that your plugins still work with the new versions. Sometimes this can become a major problem.
All of these options should work on Linux as well as Windows.
This sounds like a very ambitious project and I wish you luck.
I don't use linux too often, I use a Mac and my favorite text editor is called TextMate because it has snippets, code completion, and a whole mess of other features. The closest thing to it that I've found on linux is called Scribes.
There's always Emacs or Vim (I lean towards Vim, but that's just my opinion :) ). Neither are IDEs per se, but both are very extensible and it shouldn't be too hard to create settings for each that will aid people writing scripts in your language.

Best IDE/Editor for ColdFusion? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am just starting at a job in which I will be using a lot of ColdFusion. What is the best IDE/Editor to use?
I'd like to provide my personal reasoning behind why you might choose any of these editors (at least the ones I'm familiar with). Just saying "use this, use that" is not at all helpful. To large degree, the question is wrong. There's rarely a "best IDE" for a language; rather, there are multiple environments, each suiting particular needs. Here goes:
1) Dreamweaver
Why you would use it: its history as a designer tool makes it much easier for "non-coder" types to start cranking out websites. If you're a solo developer building a lot of "Tom's Corner Store" type of sites, even if they require some CF Coding (mailing list, subscribers, current specials, light content management, etc), its design tools, "template" features, and ease-of-deployment (ftp) make it an attractive choice. It has good-enough code coloring and code completion for the built-in CF tags and functions. It can interrogate user-defined functions in the same page. It has excellent CSS support. You can find a wealth of extensions, too. It's pretty stable and, in my experience, hasn't been very "crashy". It will do a fair amount of code generation for you as well (whether that code is "good" is debatable). All in all Dreamweaver is incredible software for web site designers.
Why you wouldn't use it: It is not free, and it is certainly not a "coder's editor". While it provides for extensions, they're typically interface-focused (javascript validation, etc), unlike say Eclipse plugins, which can run the gamut. For large projects, it simply does not have the code navigation features that many coders come to expect. It's web-focused. So if you're a polyglot, or even just like to dabble in compiled languages (java, etc), then you'll need to keep another editor on hand for those tasks.... you won't be able to do it all in one place. ColdFusion unit testing support is nonexistent in Dreamweaver. There is no step debugging for ColdFusion.
2) CFEclipse plugged into Eclipse.
Why you'd use it: CFEclipse is going on 6 years old now and has matured significantly. It's been quite stable for the last few years and most crashiness has been due to Eclipse itself and not CFEclipse (which was not true in the early days). Recently CFEclipse has seen an infusion of fresh blood and features are being added to make coding in it even more productive. It contains a wealth of keyboard shortcuts, many of the toolbar features people love from ColdFusion Studio days, and Eclipse's in-built code navigation features (namely, Ctrl-Shift-R for finding files quickly).
It has content assist for native CF Tags and functions, and some support for in-page variables, though that's never worked all that well. It does not support in-page functions, nor does it provide native true component insight (i.e. insight into components that you write and use in other code). It will support component insight to some extent with Dictionaries, but even then, it requires a lot of work on the part of the dictionary creator. Most people find dictionaries too much work to maintain, in my experience.
The lastest version of CFEclipse contains the best CFML formatting you'll find.
For me, "method explorer" and "Snip Tree View" -- particularly keyboard shortcuts for inserting snippets -- have been big productivity boosters.
If you work with ColdSpring, ModelGlue, Mach-II, ColdBox, and other frameworks with xml configuration files, CFEclipse's Framework Explorer is brilliant.
Because it's a plugin to Eclipse, you can do everything else you'd want to do in Eclipse. You wanna code java? You can. You want webservice support? you got that. You want to do step debugging, you can do so with the free Adobe-provided extensions for Eclipse.
The large plugin ecosystem is one of the most attractive features of Eclipse, and you shouldn't discount this when deciding on an editor. For example, I would not want to work without Mylyn, which integrates with issue tracking and in my experience has transformed the way I work, much for the better.
Eclipse's version control system support is excellent as well. Subversion is well supported; there's a VSS plugin; and recently a git plugin (if not two) has been accepted into the Eclipse foundation so we'll see native git support very soon (you can get it now with a plugin).
Eclipse's ANT support is excellent.
You can easily plug the MXUnit Eclipse plugin into Eclipse for unit testing your CFML (full disclosure: I contribute to MXUnit).
Finally, I have full confidence that the folks working on CFEclipse -- Denny, Mark, Jim, Peter, et al. -- will continue to work toward keeping CFEclipse as the best open source CFML IDE available. These are some of the brightest minds in the ColdFusion community and are passionate about their mission. If you choose to use CFEclipse, you are not choosing to use an IDE that will be supplanted by ColdFusion Builder. This project is in good hands.
Why you wouldn't use it: it's a code IDE, not a design tool like Dreamweaver. It's not perfect... code assist can be too aggressive in its suggestions. Eclipse itself, especially when you pile it up with all kinds of plugins, can get unstable on lesser machines. Finally, people who don't like the "Project" view of the world often have complaints about it because they're used to working directly with the file system view of the world. Its deployment support is nowhere near as simple as Dreamweaver, though you can find plugins that get close.
3) ColdFusion Builder
Why you'd use it: all of what I said previously about Eclipse itself applies to CFBuilder when used as a plugin to Eclipse. I cannot speak to the Standalone version because as of this writing, it still doesn't support plugins very well. This will most surely be fixed by the time it is released, but I don't want to speculate on what the Standalone may or may not do.
One of CFBuilder's big draws is "Extensions". These are a way to plug in CFML code into your editor. It's hard to describe, so I'd suggest googling for "ColdFusion Builder Extensions", and you'll most likely be amazed. Adobe's Terry Ryan has created "Apptacular" for scaffolding applications from a database, and Brian Rinaldi has a series of posts on building CFBuilder extensions. These are huge and will prove themselves to be a developer's best friend after CFBuilder is released.
CFBuilder's deployment support is, in my opinion, on par with if not superior to Dreamweaver's.
CFBuilder does not require an additional plugin to do step debugging. Just hit the debug button and off you go.
CFBuilder contains true component insight, meaning that it can introspect components you write and provide ctrl-space content assist. It can be wonky, however, and does require some configuration. But please remember that as of now, CFBuilder is still in beta. My best guess is that it'll be at least a few versions until all the kinks are worked out of this feature. Still, it's a big productivity and learning booster to get content assist on your own components.
CFBuilder provides a "Servers" view for stopping/starting your CF Server. It's built on Aptana and so contains the Aptana "tail log" view, which is great for watching log files. Just like CFEclipse, it has a Snip Tree View.
The CFBuilder "vision" is led by Adobe's Adam Lehman. He's passionate about CF and is a force of nature. I have great hopes for CFBuilder because of Adam's leadership.
Why you wouldn't use it:
For one, it won't be free. Noone outside Adobe knows yet how much it will cost, however. "Extensions" and the deployment features alone may be worth the price. Time will tell.
Because it's an Adobe product, I think it's reasonable to assume that releases will come as frequently as most Adobe products, which means... not very often. While CFEclipse deploys rather frequently lately -- and makes available a "nightly" site for the brave -- CFBuilder will most likely not do such daring-do. CFEclipse can afford to make potentially unstable builds available to the public, while it is perhaps not in Adobe's best interests to do so with CFBuilder.
Finally, it's still in Beta and might not be released for some time. If you get it now and start using it, remember that. In my experience, debugging is wonky, content assist sometimes works, sometimes doesn't, and a lot of people have experience crashiness. It's free beta software... you're getting what you pay for. But know that the more you work with this beta release, and particularly if you provide feedback via the public bug database, the better off all of us will be if it provides a best of breed editor for CFML.
Personally:
At home, when I do "designer" work, I use Dreamweaver when I feel that its Templates will help me build a site as quickly as possible. For existing side projects which require maintenance coding and easy deployments, I use ColdFusion builder.
At work, where I do almost no design work, CFEclipse has been my IDE since 2006. I've begun using ColdFusion builder a lot, though currently I split my time between CFBuilder and CFEclipse. One reason is that as of this writing, CFEclipse is more stable (i.e. it doesn't crash and I don't lose work). I fully expect stability problems to be mitigated by the time CFBuilder costs money.
Both CFBuilder and CFEclipse have public bug databases. CFEclipse has a well-attended public mailing list, and if you have questions, you'll get answers quickly. I cannot yet speak to the speed with which CFBuilder questions are answered.
Finally, for "coders", it's my experience that once you invest the time in learning the tools and shortcuts, Eclipse provides superior productivity compared with designer tools like Dreamweaver. For cranking out a designed site, a designer tool like Dreamweaver confers significant advantages.
The answer to the best ColdFusion IDE isn't an answer, but a question: "What are you trying to do with ColdFusion?" The answer to that question will lead you to an IDE that suits your needs for a particular project. Different circumstances or projects may lead you to a different tool which better suits your needs.
Notepad++ with CF syntax highlighting.
For free: Eclipse with CFEclipes plugin
For cost: If you're a developer, use Coldfusion Builder, if you're a front end designer Dreamweaver edits Coldfusion pretty well. I use it quite often.
I have heavily used Dreamweaver, CFeclipse with eclipse and now Coldfusion Builder. What I found is this:
1) Dreamweaver is only good for the few times you have to do some wysiwyg wizardry. The newer versions do have SVN integration so you might be able to get away with using it. I did use it for a few years on windows.
2) CFEclipse + Eclipse - Generally the standard of what' sbeen used for a while. Runs well, once you add in the Adobe dictionary files and subclipse, you have a good environment
3) Coldfusion Builder - This is Adobe's version of CFeclipse. It's still pretty new and getting to later beta. I switched to it about 6 months ago and haven't looked back. It's got a lot of wizards, including the ability to write your own plugins in CFML that will run right inside CFbuilder. It's free right now on beta but will likely be pretty cheap like the first flex builder that came out.
My Choice: Coldfusion Builder. It doesn't mean the others aren't capable, but you'll spend the least amoutn of time getting setup and maintaining your plugins, etc.
Since I had paid for and used Dreamweaver for a lot of years (Eclipse was generally sluggish sometimes on PCs' a while back until the excess of ram + cpu today), spending to have an adobe maintained copy of eclipse is okay with me. The wizards available in CFbuilder, especially for flex are excellent.
Hope that helps, good luck and share what you ended up picking and why!
For anyone who might stumble here from Google, you should also take a look at Sublime Text coupled with the ColdFusion package.
If you are familiar with Eclipse I would recommend Eclipse with coldfusion plugin.
http://www.cfeclipse.org/
Some use Eclipse, some use ColdFusion Builder, some use emacs or TextMate or vim. I use vim.
It doesn't take much time to try out an IDE or editor. Give them all a shot and stick with the one you like most.
The best IDE is ColdFusion Builder. It allows RDS, In Line Debugging, Extensions (written in ColdFusion!), Code Generation, Refactoring, supports JavaScript, CSS and HTML and so much more. It is currently in beta and should be released in production sometime this year.
CFEclipse is a great IDE for CFML and is the right choice if you are writing CFML for the open source engines. It is free and like most open-source free products it can do almost anything Builder can do if you invest the time to install the additional plugins (like Aptana) and tweak your setup just right.
I use both. At work, we use Builder. At home, I use CFEclipse.
Welcome to the CFML community!
Notepad++. Light and easy to use.
I'll vote for jEdit. While it doesn't offer great ColdFusion support beyond syntax highlighting, and therefore probably isn't great for learning ColdFusion, its flexibility in working with other languages (which seems to happen fairly often while working on the web), powerful macros, plug-in support, proper text wrapping, and loads of other features, make it the editor to which I always end up returning after trying out the "next best thing".
CFEclipse appears to be the most popular. Adobe has a beta of ColdFusion Builder (also based on Eclipse) but when I tried it a few months ago it was still buggy.
Personally I use TextMate (OS X) a pretty bare bones text editor.
I have used textpad, for 6 years, still a solid app, provides syntax coloring/highlighting, regular expressions support. Can easily search inside any file, through tons of folders/subfolders.
Just a fast loading, easy to use, tool.
Also has macros, and macro programming...
http://www.texptad.com
I'd like to throw E TextEditor for the Windows users in here as well. Its similar to sublime but it does have its advantages. E is more or less Textmate for windows and will allow you to run the cftextmate bundles. In addition to being lightweight and extremely fast you get the huge Textmate community developing bundles, color schemes, and other community driven content.
Some of the highlights of E is that it will allow you to open a directory and treat it directory as a project. Hitting Shift-Ctrl T will allow you to browse all the files in your project in a flattened hierarchy which allows you to find files extremely fast.

Has Lua a future as a general-purpose scripting language?

As already discussed in "Lua as a general-purpose scripting language?" Lua currently probably isn't the best scripting language for the desktop environment.
But what do you think about the future? Will Lua get so popular that there will soon be enough libraries to be able to use it like Python, Ruby or something similar?
Or will it simply stay in it's WoW niche and that's it?
I think it has a great future, a lot of projects are starting to adopt it for it's simplicity and usefulness.
Example: Awesome WM (Window Manager)
The project recently released version 3, incorporating a new configuration system completely written in Lua. Allowing you to literally write your configuration file as a program, loops, booleans, data structures.
Personally I love the syntax and the flexibility of such a system, I think it has great potential.
I wouldn't be surprised if it became more popular in the future.
Brian G
I suppose the answer starts with 'It depends how you want to use it...'.
If you're writing the common business app (fetch the data from the database, display the data in a web page or window, save the data to the database), Lua already has what you need.
The Kepler Project contains goodies for web development. Check out their modules to see some of the available libraries - there's network, MVC, DBMS access, XML, zip, WSAPI, docs...
As an example web app, check out Sputnik.
For desktop UI, there's wxLua - Lua hooks for wxWidgets.
ORM is conspicuously missing but that didn't stop people from developing in other languages before ORM was available.
If you're looking for specialized libraries - scientific, multimedia , security - don't count Lua out before you check LuaForge.
When it comes down to it, there's nothing in Lua's design that prevents general purpose use. It just happens to be small, fast, and easy to embed... so people do.
Uh? I would say instead WoW is a niche in the Lua ecosystem... The world of Lua doesn't revolve around WoW, there are lot of applications, some big like Adobe Lightroom (to take a non game), using Lua.
Lua is initially a scripting language, in the initial sense, ie. made to be embedded in an application to script it. But it is also designed as an extensible language, so we will see progressively more and more bindings of various libraries for various purposes.
But you will never get an official big distribution with batteries included, like Python or Perl, because it is just not the philosophy of the authors.
Which doesn't prevent other people to make distributions including lot of features out of the box (for Windows, particularly, where it is difficult to build the softwares).
Lot of people already use it for general system-level scripting, desktop applications, and such anyway.
There are more and more libraries for Lua.
If you are a Windows user, have look at Lua for Windows. It comes with "batteries included" (wxLua, LuaCURL, LuaUnit, getopt, LuaXML, LPeg...).
Very usefull!
It's 2017, 9 years after this question was first asked, and lua is now being heavily used in the field of machine learning due to the Torch library.
I really like it as an embedded language. It's small, very easy to use and embed and mostly does what I need right out of the box. It's also similar enough to most languages that it has never really been an issue for me. I also like how easy it is to redefine and add base functions and keywords to the language to suit whatever needs my application has.
I have used it in the WoW area but I've also found it useful as a generic scripting language for a number of different applications I've worked on, including as a type of database trigger. I like Ruby and Python and other more full-featured scripting languages but they're not nearly as convenient for embedding in small applications to give users more options for customizing their environments.
being comfortable as a shell language has nothing to do with being a great general purpose language.
i, for one, don't use it embedded in other applications; i write my applications in Lua, and anything 'extra' is a special-purpose library, either in Lua or in C.
Also, being 'popular' isn't so important. in the Lua-users list periodically someone appears that says "Lua won't be popular unless it does X!", and the usual answer is either: "great!, write it!", or "already discussed and rejected".
I think the great feature of Lua is, that it is very easily extensible. It is very easy to add the Lua interpreter to a program of your own (e.g. one written in C, C++ or Obj-C) and with just a few lines of code, you can give Lua access to any system resource you can think of. E.g. Lua offers no function to do xxx. Write one and make it available to Lua. But it's also possible the other way round. Write your own Lua extension in a language of your choice (one that is compilable), compile it into a native library, load the library within Lua and you can use the function.
That said, Lua might not be the best choice as a standalone crossplatform language. But Lua is a great language to add scripting support to your application in a crossplatform manner (if your app is crossplatform, the better!). I think Lua will have a future and I think you can expect that this language will constantly gain popularity in the long run.
Warhammer Online, and World of Warcraft use it for their addon language I believe.
I think it's hot! I'm just no good at it!
Well, greetings from 2022.
It is already a general purpose language. Today you can even serve pages using OpenResty, extend games, read databases or create scripts as shellscript replacements.
There are a plenty of libraries "modules" for Lua, many ways to achieve what you are wanting and Lua 5.4 is even faster.
The "extendable and extensive" nature of Lua, accostumed people to think it should only be used as plugin or extension. In Linux, by example, you can shebang a file with lua-any, make it executable and run like any system script. Or you can make a folder app like Python or virtualenv using Lupe. Lua 5.3 also gained impressive performance improvements.
Also there are many good tools like IUP to create native windows in Lua for Mac, BSD, Linux and Windows and side environments like Terra that lets you use Lua with its counterpart Terra and write compiled programs. Lua now, is more than a extension language, it has its own universe.