Unicon users were recently asked to provide feedback on whether they are
happy with the language or not. The following testimonials are unedited
except to remove mail headers to protect authors from spambots.
To add your testimony to this list, or edit/replace your testimony,
you can send e-mail to jeffery with the subject line:
"I am HAPPY with Unicon because..." or "I am UNHAPPY with Unicon because...".
I am happy with Unicon because it adds object-oriented (OO) extensions
to the Icon Programming Language, an established cross-platform language
with a rich library of reusable code. These extensions are necessary to
make Icon competitive with other popular languages that have well
developed libraries and boast object-oriented features, such as PERL,
Python, and Ruby.
I am ecstatic with Icon and Unicon because they provide for both
generators and failure as a normal part of computation. Failure, IMHO,
is more straightforward than exception handling. (Python now has
"generators" - and cites Icon as the inspiration for inclusion of that
feature - but Python generators bear greater similarity to Icon
co-expressions than Icon generators.)
Richard H. McCullough
I am HAPPY with Unicon because
it is a modern, high-level language which is easy to program, and
provides the functions I need to implement my Knowledge Explorer
e.g. associative tables, lists, sets, records.
Knowledge Explorer is written entirely in Unicon -- approx. 35,000
knowledge := man do identify od existent done
knowledge haspart proposition list
Alan B. Saichek
I am HAPPY with Unicon because
Unicon has helped me be a more productive contributor to my current
company's success and to ensure my continued employment during a time of
I have been writing code in Icon to increase my productivity in software
quality engineering positions I have held since shortly after the Red Book
Unicon enabled me to quickly learn how to introduce a TCP connection and use
select() to implement, in less than a day, an extremely useful application
to control and debug one of our products.
I had been only vaguely aware of select() and dreaded writing C code or Perl
to implement my idea.
My first implementation used the original Drones POSIX Interface and its
one-page documentation. (Thanks, Rev!)
I have since installed and used the Unicon Beta on Linux and Windows and
enjoy reading "Programming with Unicon" to learn OOP and good programming
methodology and new language features.
I have also joined the new #unicon IRC channel to discuss ways I may learn
and possibly contribute to replacing the WinCap BMP routines in Unicon.
I am particulary excited about embedded Unicon, and hope to contribute code
to accelerate that effort.
Thanks so very much to all for this work.
Alan B Saichek
Unicon as a programming language has been most useful across a number of
project involving a) very large file processing and b) rapid application
development for projects requiring text processing, Internet access to
remote databases, and rapid GUI development. Where data size cannot be
anticipated, e.g., very long lines from external sources, dictionaries
with an unknown number of entries, Unicon programming is trivially easy
Phillip L. Thomas
Specialized Information Services
National Library of Medicine
I am HAPPY with Unicon because...
- 1) Text filtering language
- I use Icon pretty much daily. I'm fluent in standard Unix tools
such as bash/awk/grep/sed, but Icon has them all beat as a
scanning language. Quite often I need to search log files (output
of our radios) for some off-beat convoluted pattern that
awk/grep/sed just can't do. Icon is much better suited for these
kind of programs.
- 2) Integration with the Unix environment
- Icon is fun language, and a nice replacement for awk/grep/sed, but
Unicon with its integration with tcp/udp, select, reading
directories, etc., is terrific. Thank you very much for coming up
with those concepts. I've used it as a driving program (over both
udp and tcp) connected to our radios (an external device),
connected to a flight simulator, and connected to numerous other
devices that are accessed over a network.
- 3) Other languages have minimal data structures
- Most of our programming is in C. Quite often, I need a list of
objects. In C, it is (as you know) a royal pain to declare a
structure with a pointer to itself, and malloc them, free them,
and walk the chain. Why can't a language just have a 'list'
datatype, and be done with it? Why can't a language provide the
constructs we all need, instead of providing nearly-assembly-
language constructs and letting us develop the rest ourselves?
- 4) Run-time environment
- Icon is not currently in our main-line product, but peripheral
tools that are currently in Java are getting re-written into Icon
because the Java .jar files are modest in size, but require a HUGE
run-time environment (30MB) to be installed on the target system.
Both Icon/Unicon and Java are multi-platform, so they are even on
this point. Also, the windowing mechanism is multi-platform,
which is another plus for Icon.
I've convinced others in our group that Unicon should be the
language of choice based on the size of the run-time system that
needs to be installed (30MB vs. none).
- 5) It is integrated into other GNU tools
- There are add-in modules for other Unix tools (because
I've written them).
Which makes it nice to edit & print Icon programs. (I think emacs
has an Icon syntax mode also.)
- - vim syntax rules for Icon (which are included in Bram
Moolenaar's vim standard distribution). (BTW, I need to
update these for Unicon.)
- - enscript pretty-print rules (a while ago I mailed these rules to
the alleged maintainer of enscript, but heard nothing back.)
- 6) Pattern matching
- Icon has useful pattern matching constructs that are not found in
other languages, or, if scanning functions are available in other
languages, they are are too awkward or tedious to use.
I am *HAPPY* with Unicon because it is multi-platform high-level language.
I used it on several different applications. From web based solutions to
system administration utilities. It is the perfect too for prototyping
because it offers powerful data structures that would be tedious to
implement and use on different languages. I also enjoy the ODBC interface
which I used to write database applications both on Windows and Unix.
I am looking forward to see a scripting version of the language which
would really simplify the development of system administration tools.
Graduate student - University of Texas at San Antonio
Senior Network Engineer - dNovus/Research Dynamics, Inc.