Editing IDL (programming language) (section)

==Problems==
{{original research|section|date=August 2014}}
Some of these features, which make IDL very simple to use interactively, also cause difficulties when building large programs. The single namespace is particularly problematic; for example, language updates that include new built-in functions have on occasion invalidated large scientific libraries.<ref>{{cite web|last1=Fanning|first1=David|title=Program Naming Conflicts in IDL 8|url=https://www.idlcoyote.com/ng_tips/idl8_name_conflicts.html|access-date=30 September 2014|archive-url=https://web.archive.org/web/20140306211336/http://www.idlcoyote.com/ng_tips/idl8_name_conflicts.html|archive-date=6 March 2014|url-status=dead}}</ref>

Arrays are passed by reference, and this mechanism is an advertised feature of the language to pass data back out of a subroutine – in contrast, array slices are copied before being passed, so that data modifications do not flow back into array ranges (after the subroutine exits), violating the [[principle of least surprise]].

Many historical irregularities survive from the early heritage of the language, requiring individual workarounds by the programmer. As an example:

* Array indexing and subroutine entry can both be carried out with exactly the same syntax (parentheses); this ambiguity, coupled with the single namespace for all variables and subroutines, can cause code to stop working when newly defined subroutines or language extensions conflict with local variable names. IDL programmers can avoid many of these problems by using square brackets for array indexing, thereby avoiding conflicts with function names which use parentheses.

The preceding issue can be alleviated using this compiler option:

 COMPILE_OPT STRICTARR

[[ITT Visual Information Solutions|ITT Visual Information Solutions (ITT VIS)]], the developers of IDL, have taken explicit steps to prevent [[bytecode]] compatibility with other environments. Files containing compiled routines use a binary tagged-data-structure format that has not been officially published but has been investigated and documented by users<ref>{{Cite web| last = Markwardt | first = Craig
| title = Unofficial Format Specification of the IDL "SAVE" File
| date = 2011-12-21
| url = http://www.physics.wisc.edu/~craigm/idl/savefmt/
| access-date = 2013-02-13}}</ref> but also contain the following notice as ASCII text embedded within each saved file: 

<blockquote> IDL Save/Restore files embody unpublished proprietary information about the IDL program. Reverse engineering of this file is therefore forbidden under the terms of the IDL End User License Agreement (IDL EULA). All IDL users are required to read and agree to the terms of the IDL EULA at the time that they install IDL. Software that reads or writes files in the IDL Save/Restore format must have a license from NV5 Geospatial Solutions, Inc. explicitly granting the right to do so. In this case, the license will be included with the software for your inspection. Please report software that does not have such a license to your account manager or sales representative.</blockquote>

{{As of|2023|8}}, the statement has not been tested in a court of law.
Also, that provision of the IDL EULA has no effect in Australia, as a result of sections [http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47d.html 47D] and [http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/s47h.html 47H] of that country's Copyright Act.