Giant Kinetic Robot sculpture from recycled and found materials

Share |

An article From Intructlables.com

This Instructable will take you through some of the steps involved in building the Robot sculpture titled "General Debris". He gets his name from the many salvaged and found objects that he is built from. The General is one of many sculptures that I have made in this fashion over the years. If you would like to see more of them please visit www.nemomatic.com

 

Click here for details and procedure Kinetic Robot

Make a wall avoiding Robot!

Share |

Objective: To create from scratch a working robot that is able to avoid walls and obstacles.
Ever wanted to make a robot that could actually do something, but never had the time or knowledge to do it? Fear no more, this instructable is just for you! I will show you step by step how to make all the necessary parts, and programs to get your very own robot up and running. I was first inspired to build a robot when I was ten, and saw Lost in Space, with that famous B-9 robot, I wanted one! Well six years later I finally built a working robot, its name- Walbot of course!
To find out more...Go to step one.

 

out:{ top: 0.10978520286396182, left: 0.11428571428571428, width: 0.7892857142857143, height: 0.7494033412887828, text:"Picture of my robot Walbot" }

Picture of my robot Walbot

Brandon121233

 

Click Here for more detail and procedure

Make a wall avoiding Robot!

How to Build a Robot - The BeetleBot

Share |

An Robo Prject From

Instructables.com

-------------------------------------------------------

I have been in robotics since I was a kid and I am very passionate by robotics. I learn BEAM robotics around 1997-98 and started building robots for a science faire project call "Insectroides" in 2001. http://robomaniac.solarbotics.net ( they change server and the website links does not work anymore it is on Linux and it is CASE SeNsiTIve! ) here is the old one
http://members.tripod.com/robomaniac_2001/index.htm
One of my many robots was the beetle robot, a VERY simple robot that can avoid obstacles on the floor without ANY silicon chip! ( the red ladybug, second picture, is my FIRST beetlerobot )
the red ladybug use a home made PCB carve with a dremel and two playstation motors with rubber wheel from a walkman!
- NO PROGRAMMING
- NO ELECTRONIC COMPONENT
It use
2 - motors
2 - SPDT switch
1 - AA battery holder
I has 16 years old when my uncle showed me the principal of the SPDT switch ( Simple Pole Double Throw). I then took this idea and incorporated the design into the (world famous) beetle robot :P
Now I am 22 and want to show you step by step instructions how YOU can make this simple robot!
here are some videos of my beetlerobot in action!
The beetlerobot in the video is made using a Printed Circuit Board ( PCB ).
This design will be use if I make a kit one day!
Check them all out here!
http://www.youtube.com/jeromedemers
This Instructable is divided into three parts
- You will learn how to build the robot
- I will explain how the robot works
- I will then teach you how to fix your robot if it does not work ( Debugging )
Don't forget to read the complete tutorial before starting! And remember to wear safety glasses at all time because eye injuries ain't worth the risk! It will happen in a blick of an eye.
Have a great time!
ps- Check out Gareth Branwyn book, I made a one motor walker and he made a complete chapter with my robot!! He send me the book call " Absolute beginner's guide to building robots" A very great book!
Maybe I should write a book...
Jerome Demers aka ROBOMANIAC!
Updated july 2007 - I have added some pictures of the inside of my first beetlerobot. Home made AAA battery holder! I have also added some videos on youtube! http://www.youtube.com/jeromedemers

 

 

Click Here for more Details and method to build The BeetleBot ..

Furby Hijack

Share |

The furby's in-built sensors and actuators:
light sensor,
IR sensor,
IR transmitter,
tongue touch sensor,
belly touch sensor,
microphone,
speaker.
The furby's main (and only) motor was dead, so I added other motors.

 

 

For more Details and procedure to build  plz click Here

Computer in Wrist Watch

Share |

excerpts from ISSCC 2000 conference where the invention was presented

ISSCC: 'Dick Tracy' watch watchers disagree

By Peter Clarke
EE Times
(02/08/00, 9:12 p.m. EST)
 
  SAN FRANCISCO -- Panelists at a Monday evening (Feb. 7) panel session
  at the International Solid State Circuits Conference (ISSCC) here
  failed to agree on when the public will be able to buy a "Dick Tracy"
  style watch for Christmas, with estimates ranging from almost
  immediately to not within the next decade.
 
  Steve Mann, a professor at the University of Toronto, was hailed as
  the father of the wearable computer and the ISSCC's first virtual
  panelist, by moderator Woodward Yang of Harvard University (Cambridge
  Mass.).

...

  Not surprisingly, Mann was generally upbeat at least about the
  technical possibilities of distributed body-worn computing, showing
  that he had already developed a combination wristwatch and imaging
  device that can send and receive video over short distances.

  Meanwhile, in the debate from the floor that followed the panel
  discussion, ideas were thrown up, such as shoes as a mobile phone --
  powered by the mechanical energy of walking, and using the Dick Tracy
  watch as the user interface -- and a more distributed model where
  spectacles are used to provide the visual interface; an ear piece to
  provide audio; and even clothing to provide a key-pad or display.

Definition of programming

Share |

Traits often considered important when deciding whether a language is a programming language:

* Function: A programming language is a language used to write computer programs, which involve a computer performing some kind of computation[3] or algorithm and possibly control external devices such as printers, robots[4], and so on.

* Target: Programming languages differ from natural languages in that natural languages are only used for interaction between people, while programming languages also allow humans to communicate instructions to machines. Some programming languages are used by one device to control another. For example PostScript programs are frequently created by another program to control a computer printer or display.

* Constructs: Programming languages may contain constructs for defining and manipulating data structures or controlling the flow of execution.

* Expressive power: The theory of computation classifies languages by the computations they can express (see Chomsky hierarchy). All Turing complete languages can implement the same set of algorithms. ANSI/ISO SQL and Charity are examples of languages that are not Turing complete yet often called programming languages.[5][6]

Non-computational languages, such as markup languages like HTML or formal grammars like BNF, are usually not considered programming languages. Often a programming language is embedded in the non-computational (host) language.

Programming Languages

Share |

Array languages

See also: :Category:Array_programming_languages

Array programming (also known as vector or multidimensional languages) generalize operations on scalars to apply transparently to vectors, matrices, and higher dimensional arrays.

* A+
* Analytica
* APL
* F
* FISh
* Fortran 90 and later versions
* IDL
* J
* K
* MATLAB
* Octave
* NESL
* Nial
* PDL
* ZPL
* SAC

Aspect-oriented languages

* AspectC++
* AspectJ
* CaesarJ
* Common Lisp
* Compose*
* JAsCo (and AWED)
* ObjectTeams

Assembly languages

See also: :Category:Assembly languages

Assembly languages directly correspond to a machine language (see below) in order to allow machine code instructions to be written in a form understandable by humans. Assembly languages allow programmers to use symbolic addresses which are later converted to absolute addresses by the assembler. Most assemblers also allow for macros and symbolic constants.

* ASEM-51 [1]
* a56 (for Motorola DSP56000 DSPs, DSP56k series)
* AKI (AvtoKod "Inzhener", "Engineer's Autocode" for Minsk family of computers)
* ASCENT (ASsembler for CENTral Processor Unit of Control Data Corporation computer systems pre-COMPASS)
* ASPER (ASsembler for PERipheral Processor Units of Control Data Corporation computer systems pre-COMPASS)
* BAL (Basic AssembLer) - for IBM System/360 and later mainframe systems
* C-- (name used by a few languages that bring C language closer to Assembly)
* COMPASS (COMPrehensive ASSembler)
* D (multiparadigm curly-brace language with built-in inline assembler)
* Emu8086 [2] (x86 assembler and Intel's 8086 microprocessor emulator)
* EDTASM (Microsoft editor/assembler for Motorola 6809 on the Color Computer)
* FAP (FORTRAN Assembly Program, for IBM 709, 7090, 7094 mainframes)
* FASM (Flat Assembler; IA-32, IA-64)
* GAS (GNU Assembler)
* HLA (High Level Assembly)
* HLASM (High Level Assembler, for mainframes)
* Linoleum (for cross platform use)
* MACRO-11 (for DEC PDP-11)
* MACRO-20 (for DEC DECSYSTEM-20)
* MACRO-32 (for DEC VAX)
* MASM (Microsoft Macro Assembler)
* MI (Machine Interface, compile-time intermediate language)
* MIPS ( for MIPS architecture) Microprocessor without Interlocked Pipeline Stages
* Motorolla 68k Assembly ( for Motorola 68k ) Assembly Language for Motorolla 68k family of CPUs
* NASM (Netwide Assembler)
* NEAT (National's Electronic Autocoder Technique), for NCR computers, evolved into NEAT/3
* PAL-III (for DEC PDP-8)
* PASM (for Parrot virtual machine)
* RosAsm (32 bit Assembler; The Bottom Up Assembler)
* Sphinx C-- (mixes Assembly commands with C-like structures)
* SSK (Sistema Simvolicheskogo Kodirovaniya, or "System of symbolic coding") for Minsk family of computers
* TASM (Turbo Assembler, Borland)

Authoring languages

* Bigwig (web design language)
* Coursewriter
* PILOT
* TUTOR

Command line interface languages

Command line interface (CLI) languages are also called batch languages, or job control languages. Examples:

* 4DOS (extended command-line shell for IBM PCs)
* bash (the "Bourne-Again" shell from GNU/FSF)
* Ch (C-compatible shell)
* CHAIN (Datapoint)
* CLIST (MVS Command List)
* csh (C-like shell from Bill Joy at UC Berkeley)
* DCL DIGITAL Command Language - standard CLI language for VMS (DEC, Compaq, HP)
* DOS batch language (standard CLI/batch language for the IBM PC running DR-DOS, MS-DOS, or PC-DOS before Windows)
o EA_QB_Command
* EXEC
* EXEC 2
* JCL (punch card-oriented batch control language for IBM/360 family mainframes)
* ksh (a standard Unix shell, written by David Korn)
* REXX
* sh (the standard Unix shell, written by Stephen Bourne)
* Winbatch (Windows batch file language)
* Windows PowerShell (Microsoft .NET-based CLI)
* zsh (a Unix shell)

Compiled languages

These are languages typically processed by compilers, though theoretically any language can be compiled or interpreted. See also compiled language.

* Ada (multi-purpose language)
* ALGOL (extremely influential language design. The second high level language compiler.)
o SMALL Machine Algol Like Language
* BASIC (some dialects, including the first version of Dartmouth BASIC)
* C (one of the most widely-used procedural programming languages)
* C++
* C# (compiled into Intermediate Language bytecode)
* CLEO (Clear Language for Expressing Orders) used the compiler for the British Leo computers
* CLush (Lush)
* COBOL
* Common Lisp
* Corn
* Curl
* D
* Delphi (Borland's Object Pascal development system)
* DIBOL (Digital Interactive Business Oriented Language)
* Eiffel (object-oriented language developed by Bertrand Meyer)
o Sather
o Ubercode
* Forth (professional systems, like VFX and SwiftForth)
* Fortran (the first high level, compiled, language, from IBM, John Backus, et al)
* Java (originally from Sun Microsystems; usually compiled into JVM bytecode although true native-code compiled versions exist)
* JOVIAL
* Nemerle (compiled into Intermediate Language bytecode)
* Objective-C
* Pascal (most implementations)
* ppC++
* Scheme (some implementations, e.g. Gambit)
* ML
o Standard ML
+ Alice
o Ocaml
* Turing
* Urq
* Visual Basic (from Microsoft)
* Visual Foxpro
* Visual Prolog
* WinDev

Concurrent languages

See also: :Category:Concurrent_programming_languages

Message passing languages provide language constructs for concurrency. The predominant paradigm for concurrency in mainstream languages such as Java is shared memory concurrency based on monitors. Concurrent languages that make use of message passing have generally been inspired by CSP or the π-calculus, but have had little commercial success, except for Ada and Erlang. Ada is a multipurpose language and concurrent programming is only one option available.

* Ada (multi-purpose language)
* Afnix – concurrent access to data is protected automatically (previously called Aleph, but unrelated to Alef)
* Alef – concurrent language with threads and message passing, used for systems programming in early versions of Plan 9 from Bell Labs
* ChucK – domain specific programming language for audio, precise control over concurrency and timing
* Cilk – a concurrent C
* Cω – C Omega, a research language extending C#, uses asynchronous communication
* Concurrent Pascal (by Brinch-Hansen)
* Corn
* Curry
* E – uses promises, ensures deadlocks cannot occur
* Eiffel (through the SCOOP mechanism, Simple Concurrent Object-Oriented Computation)
* Erlang – uses asynchronous message passing with nothing shared
* Java
o Join Java – concurrent language based on Java
o X10
* Join-calculus
* Joule – dataflow language, communicates by message passing
* Limbo – relative of Alef, used for systems programming in Inferno (operating system)
* MultiLisp – Scheme variant extended to support parallelism
* occam – influenced heavily by Communicating Sequential Processes (CSP).
o occam-π – a modern variant of occam, which incorporates ideas from Milner's π-calculus
* Oz – multiparadigm language, supports shared-state and message-passing concurrency, and futures
o Mozart Programming System – multiplatform Oz
* Pict – essentially an executable implementation of Milner's π-calculus
* SALSA – actor language with token-passing, join, and first-class continuations for distributed computing over the Internet
* SR – research language

Curly-bracket languages

See also: :Category:Curly bracket programming languages

The curly bracket programming languages have a syntax that defines statement blocks using the "curly bracket" or "brace" characters { and }. All these languages descend from or are strongly influenced by C. Examples of curly-bracket languages include:

* ABCL/c+
* Alef
o Limbo
* AutoHotkey
* AWK
* BCPL
* C - developed circa 1970 at Bell Labs
* C shell (csh)
* C++
* C#
* Ch - embeddable C/C++ interpreter
* ChucK - audio programming language
* Cilk - concurrent C for multithreaded parallel programming
* Coyote - safer C variant to lower the likelihood of some common errors, e.g., buffer overflows
* Cyclone - safer C variant
* D - C/C++ variant
* DINO
* E
* ECMAScript
o ActionScript
o DMDScript
o E4X
o JavaScript
o JScript
o MDMscript
* Frink
* ICI
* Java
o Groovy
o Join Java
o X10
* LPC
* Nemerle - combines C# and ML features, provides syntax extension capabilities
* Perl
* PHP
* Pico
* Pike
* ppC++
* Suneido
* SuperCollider
* TorqueScript
* UnrealScript
* Windows PowerShell (Microsoft .NET-based CLI)
* Yorick

Dataflow languages

Dataflow languages rely on a (usually visual) representation of the flow of data to specify the program. Frequently used for reacting to discrete events or for processing streams of data. Examples of dataflow languages include:

* Hartmann pipelines
* G (used in LabVIEW)
* Max
* Prograph
* Pure data
* VEE
* VisSim

Data-oriented languages

Data-oriented languages provide powerful ways of searching and manipulating the relations that have been described as entity relationship tables which map one set of things into other sets. Examples of data-oriented languages include:

* Clarion
* Clipper (programming language)
* dBase a relational database access language
* M (an ANSI standard general purpose language with specializations for database work.)
* SPARQL
* SQL
* Tutorial D, see also The Third Manifesto
* Visual Foxpro native rdbms engine, object oriented, functional, RAD
* WebQL

Data-structured languages

See also: :Category:Data-structured programming languages

Data-structured languages are those where logic is structured in ways similar to their data. Such languages are generally well suited to reflection and introspection. There are three main types:

* Array-based
* List-based
* Stack-based

Assembly languages which statically link data inline with instructions can also be considered data-structured, in the most primitive way.

Declarative languages

See also: :Category:Declarative programming languages

Declarative languages describe a problem rather than defining a solution. Declarative programming stands in contrast to imperative programming via imperative programming languages, where serial orders (imperatives) are given to a computer. In addition to the examples given just below, all (pure) functional and logic-based programming languages are also declarative. In fact, "functional" and "logical" constitute the usual subcategories of the declarative category.

* ABSET
* Analytica
* Lustre
* MetaPost
* Prolog
* SQL
* XSL Transformations

Esoteric languages

An esoteric programming language is a programming language designed as a test of the boundaries of computer programming language design, as a proof of concept, or as a joke.

* Befunge
* Brainfuck
* Chef
* FALSE
* INTERCAL
* Shakespeare
* Whitespace
* Malbolge
* Lolcode
* merd

Extension languages

Extension programming languages are languages intended to be embedded into another program and used to harness its features in extension scripts.

* AutoLISP (specific to AutoCAD)
* CAL
* Guile
* Visual Basic for Applications
* Lua

etc.)

* Python (Maya and other 3-D animation packages)
* REXX
* Tcl

Fourth-generation languages

Fourth-generation programming languages are high-level languages built around database systems. They are generally used in commercial environments.

* ABAP
* ADMINS
* BuildProfessional
* CorVision
* CSC's GraphTalk
* Easytrieve report generator (now CA-Easytrieve Plus)
* Focus
* GEMBASE
* Informix-4GL / Aubit-4GL
* LINC
* MAPPER (Unisys/Sperry) now part of BIS
* MARK-IV (Sterling/Informatics) now VISION:BUILDER of CA
* Oracle Express 4GL
* Revolution (not based on a database; still, the goal is to work at a higher level of abstraction than 3GLs)
* SAS
* Today
* Ubercode (VHLL, or very high level language)
* Uniface (programming language)
* Visual DataFlex
* Visual Foxpro

Functional languages

See also: :Category:Functional languages

Functional programming languages define programs and subroutines as mathematical functions. Many so-called functional languages are "impure", containing imperative features. Not surprisingly, many of these languages are tied to mathematical calculation tools. Functional languages include:

* APL
* Charity
* Clean (purely functional)
* CodeSimian
* Curl
* Curry
* Erlang
* F#
* Haskell (purely functional)
o CAL
* J
* Joy
* Kite
* Lisp
o Common Lisp
o Dylan
o Logo
o Scheme
* Lush
* Maple
* Mathematica
* ML
o Standard ML
+ Alice
o Ocaml
* Nemerle
* Opal
* OPS5
* Poplog
* Q
* REFAL
* Spreadsheets

Interactive mode languages

Interactive mode languages act as a kind of shell: expressions or statements can be entered one at a time, and the result of their evaluation is seen immediately.

* BASIC (some dialects)
* Forth
* Haskell (with the GHCi interpreter)
* M (an ANSI standard general purpose language)
* Maple
* ML
* Python
* Ruby (with irb)
* Tcl (with the Tcl shell, tclsh)
* Windows PowerShell (Microsoft .NET-based CLI)

Interpreted languages

Interpreted languages are programming languages which programs may be executed from source code form, by an interpreter.

* APL
* AutoIt scripting language
* BASIC (some dialects)
* CodeSimian
* Databus (later versions added optional compiling)
* Eiffel (via "Melting Ice Technology" in EiffelStudio)
* Forth (interactive shell only; otherwise compiled to native or threaded code)
* Frink
* J
* Lisp (early versions, pre-1962, and some experimental ones; production Lisp systems are compilers, but many of them still provide an interpreter if needed)
* Lua (programming language)
* Lush
* M (an ANSI standard general purpose language)
* Maple
* Pascal (early implementations)
* PostScript
* Python
* REXX
* Spin programming language
* The SDYPAIKSSVDAYSF Programming Language
* TorqueScript
* VBScript
* Windows PowerShell (Microsoft .NET-based CLI)
* Some scripting languages (below)

Iterative languages

Languages built around or offering generators

* Aldor
* Alphard
* CLU
* Eiffel, through "agents"
* Icon
* IPL-v
* Lua
* Lush
* Python
* Sather

List-based languages – LISPs

List-based languages are a type of data-structured language that are based upon the list data structure.

* Joy
* Lisp
o Common Lisp
o Arc
o CodeSimian (like Lisp, but made with Java)
o Dylan
o Scheme
o Logo
* Lush
* Tcl
* TRAC

Little languages

Little languages serve a specialized problem domain.

* apply is a domain-specific language for image processing on parallel and conventional architectures
* awk can serve as a prototyping language for C, because the syntax is similar
* SQL has only a few keywords, and not all the constructs needed for a full programming language

Logic-based languages

See also: :Category:Logic programming languages

Logic-based languages specify a set of attributes that a solution must have, rather than a set of steps to obtain a solution. Examples:

* ALF
* Curry
* Janus
* Leda
* Oz
o Mozart Programming System a multiplatform Oz
* Poplog
* Prolog (formulates data and the program evaluation mechanism as a special form of mathematical logic called Horn logic and a general proving mechanism called logical resolution)
o Mercury (based on Prolog)
o Strawberry Prolog (standard Prolog with some extensions)
o Visual Prolog (object-oriented Prolog extension)
* ROOP

Machine languages

Machine languages are directly executable by a computer's CPU. They are typically formulated as bit patterns, usually represented in octal or hexadecimal. Each group of npatterns (often 1 or more bytes) causes the circuits in the CPU to execute one of the fundamental operations of the hardware. The activation of specific electrical inputs (eg, CPU package pins for microprocessors), and logical settings for CPU state values, control the processor's computation. Individual machine languages are processor specific and are not portable. They are (essentially) always defined by the CPU developer, not by 3rd parties. The symbolic version, the processor's assembly language, is also defined by the developer, in most cases. Since processors come in families which are based on a shared architecture, the same basic assembly language style can often be used for more than one CPU. Each of the following CPUs served as the basis for a family of processors:

* ARM
* Intel 80x86
* IBM 360
* Intel 8008/8080/8085
* MIPS R2000|R3000
* MOS Tech 6502
* Motorola 680x
* Motorola 680x0
* National 32032
* Power Architecture - (POWER and PowerPC)
* StrongARM
* Sun SPARC, UltraSPARC

Macro languages

See also: :Category:Macro programming languages

Macro languages embed small pieces of executable code inside a piece of free-form text.

* C preprocessor
* m4 (originally from AT&T, bundled with Unix)
* PHP
* SMX
* Stage 2

Scripting languages such as Tcl and ECMAScript (ActionScript, DMDScript, E4X, JavaScript, JScript) have been embedded into applications so that they behave like macro languages.

Metaprogramming languages

Metaprogramming is writing of programs that write or manipulate other programs (or themselves) as their data or that do part of the work that is otherwise done at run time during compile time. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually.

* Curl
* Forth
* Lisp
* Maude
* Nemerle
* Python

Multiparadigm languages

Multiparadigm languages support more than one programming paradigm. They allow a program to use more than one programming style. The goal is to allow programmers to use the best tool for a job, admitting that no one paradigm solves all problems in the easiest or most efficient way.

* Ada (concurrent, distributed, generic (template metaprogramming), imperative, object-oriented (class-based))
* ALF (functional, logic)
* APL (functional, imperative)
* BETA (functional, imperative, object-oriented (class-based))
* C++ (generic, imperative, object-oriented (class-based))
* ChucK (imperative, object-oriented, time-based, concurrent, on-the-fly)
* Common Lisp (functional, imperative, object-oriented (class-based), aspect-oriented (user may add further paradigms, e.g., logic))
* Corn (concurrent, generic, imperative, object-oriented (class-based))
* Curl (functional, imperative, object-oriented (class-based), metaprogramming)
* Curry (concurrent, functional, logic)
* D (generic, imperative, object-oriented (class-based))
* Dylan (functional, object-oriented (class-based))
* ECMAScript (functional, imperative, object-oriented (prototype-based))
o ActionScript
o DMDScript
o E4X
o JavaScript
o JScript
* Eiffel (imperative, object-oriented (class-based), generic)
* J (functional, imperative, object-oriented (class-based))
* LabVIEW (dataflow, visual)
* Lasso (macro, object-oriented (prototype-based), procedural, scripting)
* Lava (object-oriented (class-based), visual)
* Leda (functional, imperative, logic, object-oriented (class-based))
* Lua (functional, imperative, object-oriented (prototype-based))
* Maple
* Metaobject protocols (object-oriented (class-based, prototype-based))
* Nemerle (functional, object-oriented (class-based), imperative, metaprogramming)
* Objective Caml (functional, imperative, object-oriented (class-based))
* Oz (functional (evaluation: eager, lazy), logic, constraint, imperative, object-oriented (class-based), concurrent, distributed)
o Mozart Programming System (multiplatform Oz)
* Object Pascal (imperative, object-oriented (class-based))
* Perl (imperative, functional (can't be purely functional), object-oriented, class-oriented, aspect-oriented (through modules))
* PHP (imperative, object-oriented)
* Pliant (functional, imperative, object-oriented (class-based))
* Poplog (functional, imperative, logic)
* ppC++ (imperative, object-oriented (class-based))
* Prograph (dataflow, object-oriented (class-based), visual)
* Python (functional, object-oriented (class-based))
* REBOL (functional, object-oriented (prototype-based))
* ROOP (imperative, logic, object-oriented (class-based), rule-based)
* Ruby (functional, object-oriented (class-based))
* SISAL (concurrent, dataflow, functional)
* Spreadsheets (functional, visual)
* Tcl (functional, imperative, object-oriented (class-based))

Numerical analysis

* Algae
* Seneca an Oberon variant

Non-English-based languages

See also: :Category:Non-English-based programming languages

Non-English-based programming languages do not use English keywords.

* ARLOGO - Arabic
* Chinese BASIC - Chinese
* Fjölnir - Icelandic
* HPL - Hebrew
* Lexico - Spanish
* Rapira - Russian
* Glagol - Russian
* var'aq - Klingon

Object-oriented class-based languages

Class-based Object-oriented programming languages support objects defined by their class. Class definitions include member data. Polymorphic functions parameterized by the class of some of their arguments are typically called methods.

In languages with single dispatch, classes typically also include method definitions. In languages with multiple dispatch, methods are defined by generic functions. There are exceptions where single dispatch methods are generic functions (e.g. Bigloo's object system).

Multiple dispatch

* Common Lisp
* Dylan
* Goo
* Cecil

Single dispatch

* Actor
* Ada 95 (multi-purpose language)
* BETA
* C++
* C#
* Chrome
* ChucK
* ColdFusion
* Corn
* Curl
* D
* Delphi
* ECMAScript (originally from Sun and Netscape)
o ActionScript
o DMDScript
o E4X
o JavaScript
o JScript
o MDMscript
* Eiffel
o Sather
o Ubercode
* F-Script
* Fortran 2003
* Fortress
* J
* Java (closely related to C++, but with built-in garbage collection, removal of unsafe features and some advanced ones, compilation to universally runnable 'bytecode', protective sandbox for security -- originally from Sun Microsystems)
o Groovy
o Join Java
o X10
* Kite
* Lava
* Lua
* Modula-2 (data abstraction, information hiding, strong typing, full modularity -- from N Wirth)
o Modula-3 (added more object oriented features to Modula-2)
o Objective Modula-2 (Modula-2 with Smalltalk message passing, following the Objective-C object model)
* Moto
* Nemerle
* NetRexx
* Oberon-2 (full object orientation equivalence in an original, strongly typed, Wirthian manner)
* Object Pascal
* Object REXX
* Objective-C (a superset of C adding a Smalltalk derived object model and message passing syntax)
* Objective Caml
* Oz
o Mozart Programming System
* Perl 5
* PHP
* Pliant
* PowerBuilder
* ppC++
* Prograph
* Python (object oriented interpretive language)
* Revolution (programmer does not get to pick the objects)
* Ruby (object oriented interpretive language)
* Simula (the first object oriented language, from Norway)
* Smalltalk (pure object-orientation, originally from Xerox PARC)
o Bistro
o F-Script
o Little Smalltalk
o Squeak
o VisualAge
o VisualWorks
* SPIN
* SuperCollider
* VBScript (Microsoft Office 'macro scripting' language)
* Visual Basic
* Visual DataFlex
* Visual Foxpro
* Visual Prolog
* XOTcl

Object-oriented prototype-based languages

Prototype-based languages are object-oriented languages where the distinction between classes and instances have been removed:

* ABCL/1
* ABCL/R
* ABCL/R2
* ABCL/c plus
* ActionScript
* Agora
* Cecil
* CodeSimian
* ECMAScript
o ActionScript
o DMDScript
o E4X
o JavaScript (first named Mocha, then LiveScript)
o JScript
* Etoys in Squeak
* Io
* Lisaac
* MOO
* NewtonScript
* Maple
* Obliq
* REBOL
* Self (the first prototype-based language, derived from Smalltalk)
* Slate
* TADS

Off-side rule languages

Off-side rule languages are those where blocks are formed, indicated, by their indentation.

* ISWIM, the abstract language that introduced the rule
* ABC, Python's parent
o Python
* Miranda, Haskell's parent
o Haskell
+ Curry
* Occam
* Pliant
* SPIN

Procedural languages

Procedural programming languages are based on the concept of the unit and scope (the data viewing range of an executable code statement). A procedural program is composed of one or more units or modules, either user coded or provided in a code library; each module is composed of one or more procedures, also called a function, routine, subroutine, or method, depending on the language. Examples of procedural languages include:

* Ada (multi-purpose language)
* ALGOL (extremely influential language design. The second high level language compiler.)
o SMALL Machine Algol Like Language
* BASIC (BASICs are innocent of most modularity in (especially) versions prior to about 1990)
* BLISS
* C
* C++ (C with objects + much else)
* C# (from Microsoft, a next generation Java/C++ like language)
* ChucK (C/Java-like syntax, with new syntax elements for time and parallelism)
* ColdFusion
* COBOL
* Component Pascal (an Oberon-2 variant)
* Curl
* D
* Delphi
* ECMAScript
o ActionScript
o DMDScript
o E4X
o JavaScript (first named Mocha, then LiveScript)
o JScript
* Eiffel
* Fortran (better modularity in later Standards)
o F
* FPC Pascal (Pascal dialect)
* HyperTalk
* Java
o Groovy
o Join Java
* JOVIAL
* Lasso
* Modula-2 (fundamentally based on modules)
* Oberon-1 and Oberon-2 (improved, smaller, faster, safer follow-ons for Modula-2)
o Component Pascal
o Lagoona
o Seneca
* MATLAB
* M (more modular in its first release than a language of the time should have been; the standard has become still more modular since then)
* Nemerle
* Occam
* Pascal (successor to Algol60 and predecessor of Modula-2)
o Object Pascal
* Perl
* PL/C
* PL/I (large general purpose language, originally for IBM mainframes)
* Rapira
* VBScript
* Visual Basic
* Visual Foxpro

Reflective languages

Reflective languages let programs examine and possibly modify their high level structure at runtime. This is most common in high-level virtual machine programming languages like Smalltalk, and less common in lower-level programming languages like C. Languages and platforms supporting reflection:

* Aspect-oriented
* Befunge
* ChucK
* CodeSimian
* Curl
* ECMAScript
o ActionScript
o DMDScript
o E4X
o JavaScript
o JScript
* Eiffel
* Forth
* Java
o Java Virtual Machine
o Groovy
o Join Java
o X10
* Maple
* Lisp
o Common Lisp
o Dylan
o Logo
o Scheme
* Lua
* Maude system
* .NET Common Language Runtime
* Objective-C
* Objective Modula-2
* Perl
* PHP
* Pico
* Pliant
* Poplog
o POP-11
* Prolog
* Python
* REBOL
* Ruby
* Smalltalk (pure object-orientation, originally from Xerox PARC)
o Bistro
o F-Script
o Little Smalltalk
o Self
o Squeak
o VisualAge
o VisualWorks
* Snobol
* Tcl
o XOTcl

Rule-based languages

Rule-based languages instantiate rules when activated by conditions in a set of data. Of all possible activations, some set will be selected and the statements belonging to those rules will be executed. Examples of rule-based languages include:

* Clips
* Constraint Handling Rules
* Jess
* OPS5
* Prolog

Scripting languages

"Scripting language" has two apparently different, but in fact similar meanings. In a traditional sense, scripting languages are designed to automate frequently used tasks that usually involve calling or passing commands to external programs. Many complex application programs allow users to implement custom functions by providing them with built-in languages. Those which are of interpretive type, are often called scripting languages.

More recently many of these applications have chosen to "build in" traditional scripting languages, such as Perl or Visual Basic, but there are quite a few "native" scripting languages still in use. Many scripting languages are compiled to bytecode and then this (usually) platform independent bytecode is run through a virtual machine (compare to Java).

* AWK
* AppleScript
* BeanShell
* Ch (Embeddable C/C++ interpreter)
* CLIST
* ColdFusion
* ECMAScript
o ActionScript
o DMDScript
o E4X
o JavaScript (first named Mocha, then LiveScript)
o JScript
* EXEC
* EXEC 2
* F-Script
* Frink
* Game Maker Language (GML)
* ICI
* Io
* JASS
* Java
o Groovy
o Join Java
* Lua
* MAXScript
* MEL
* Mondrian
* Perl
* PHP (intended for Web servers)
* Python
* REXX
* Ruby
* Sed
* Tcl
* TorqueScript
* Revolution
* VBScript
* Windows PowerShell (Microsoft .NET-based CLI)
* Many shell command languages such as the UNIX shell or DCL on VMS have powerful scripting capabilities.

Stack-based languages

See also: :Category:Stack-oriented programming languages

Stack-based languages are a type of data-structured language that are based upon the stack data structure.

* colorForth
* Forth
* Factor
* Poplog via its implementation language POP-11
* PostScript
* RPL
* Urq

Synchronous languages

See also: :Category:Synchronous programming languages

Synchronous programming languages are optimized for programming reactive systems, systems that are often interrupted and must respond quickly. Many such systems are also called realtime systems, and are found often in embedded uses. Examples:

* Argos
* Averest
* Esterel
* LEA
* Lustre
* Signal
* SyncCharts

Syntax handling languages

* GNU bison (FSF's version of Yacc)
* GNU Flex (FSF's version of Lex)
* Lex (Lexical analysis, from Bell Labs)
* M4
* yacc (yet another compiler compiler, from Bell Labs)
* javacc
* Coco/R (EBNF with semantics)

Visual languages

See also: :Category:Visual programming languages

Visual programming languages let users specify programs in a two-(or more)-dimensional way, instead of as one-dimensional text strings, via graphic layouts of various types.

* CODE
* Eiffel (program design from BON or UML diagrams, with back-and-forth facilities (round-trip engineering) through EiffelStudio)
* Fabrik
* Hyperpascal
* LabVIEW
* Lava
* Limnor
* Mindscript — software visualization and development environment, open source
* Max
* Pict
* Prograph
* Pure Data
* Quartz Composer
* Simulink
* Spreadsheets
* Subtext
* Tinkertoy
* VEE
* VisSim
* VVVV

Some dataflow languages are also visual languages.

Wirth languages

Computer scientist Niklaus Wirth designed and implemented several influential languages.

* Algol W
* Modula
* Modula-2 (and Modula 3, etc. variants)
o Obliq Modula 3 variant
* Oberon (Oberon and Oberon-2)
o Component Pascal
o Lagoona
o Seneca
* Pascal
o Object Pascal (original name for Borland Delphi language)

XML-based languages

These are languages based on or that operate on XML. Although the big-boy equivalents of Oracle/PostgreSQL/MSSQL don't yet exist for XML, there are languages to navigate through it and its more tree-oriented structure.

* ECMAScript E4X
* Jelly
* XPath
* XQuery
* XSLT
* Cω

History of programming

Share |

History of programming

Wired plug board for an IBM 402 Accounting Machine.

The earliest programmable machine (that is a machine whose behavior can be controlled by changes to a "program") was Al-Jazari's programmable humanoid robot in 1206. Al-Jazari's robot was originally a boat with four automatic musicians that floated on a lake to entertain guests at royal drinking parties. His mechanism had a a programmable drum machine with pegs (cams) that bump into little levers that operate the percussion. The drummer could be made to play different rhythms and different drum patterns by moving the pegs to different locations.^[2]

The Jacquard Loom, developed in 1801, is often quoted as a source of prior art. The machine used a series of pasteboard cards with holes punched in them. The hole pattern represented the pattern that the loom had to follow in weaving cloth. The loom could produce entirely different weaves using different sets of cards. The use of punched cards was also adopted by Charles Babbage around 1830, to control his Analytical Engine.

This innovation was later refined by Herman Hollerith who, in 1896 founded the Tabulating Machine Company (which became IBM). He invented the Hollerith punched card, the card reader, and the key punch machine. These inventions were the foundation of the modern information processing industry. The addition of a plug-board to his 1906 Type I Tabulator allowed it to do different jobs without having to be rebuilt (the first step toward programming). By the late 1940s there were a variety of plug-board programmable machines, called unit record equipment, to perform data processing tasks (card reading). The early computers were also programmed using plug-boards.

A box of punch cards with several program decks.

The invention of the Von Neumann architecture allowed programs to be stored in computer memory. Early programs had to be painstakingly crafted using the instructions of the particular machine, often in binary notation. Every model of computer would be likely to need different instructions to do the same task. Later assembly languages were developed that let the programmer specify each instruction in a text format, entering abbreviations for each operation code instead of a number and specifying addresses in symbolic form (e.g. ADD X, TOTAL). In 1954 Fortran, the first higher level programming language, was invented. This allowed programmers to specify calculations by entering a formula directly (e.g. Y = X*2 + 5*X + 9). The program text, or source, was converted into machine instructions using a special program called a compiler. Many other languages were developed, including ones for commercial programming, such as COBOL. Programs were mostly still entered using punch cards or paper tape. (See computer programming in the punch card era). By the late-60s, data storage devices and computer terminals became inexpensive enough so programs could be created by typing directly into the computers. Text editors were developed that allowed changes and corrections to be made much more easily than with punch cards.

As time has progressed computers have made giant leaps in the area of processing power. This has brought about newer programming languages that are more abstracted from the underlying hardware. Although these more abstracted languages require additional overhead, in most cases the huge increase in speed of modern computers has brought about little performance decrease compared to earlier counterparts. The benefits of these more abstracted languages is that they allow both an easier learning curve for people less familiar with the older lower-level programming languages, and they also allow a more experienced programmer to develop simple applications quickly. Despite these benefits, large complicated programs, and programs that are more dependent on speed still require the faster and relatively lower-level languages with todays hardware. (The same concerns were raised about the original Fortran language.)

Throughout the second half of the twentieth century, programming was an attractive career in most developed countries. Some forms of programming have been increasingly subject to offshore outsourcing (importing software and services from other countries, usually at a lower wage), making programming career decisions in developed countries more complicated, while increasing economic opportunities in less developed areas. It is unclear how far this trend will continue and how deeply it will impact programmer wages and opportunities. Despite the "outsourcing trend" it can be argued that some of the richest persons on the globe are programmers by profession. Examples: Bill Gates (Microsoft), Larry Ellison (Oracle), Larry Page (Google), Hasso Plattner (SAP) and so on. Programming is clearly a leading-edge craftsmanship that continues to reward its practitioners both in countries such as India and developed countries like the USA or Germany.

Algorithmic Complexity

Share |

The academic field and engineering practice of computer programming are largely concerned with discovering and implementing the most efficient algorithms for a given class of problem. For this purpose, algorithms are classified into orders using so-called Big O notation, O(n), which expresses execution time, memory consumption, or another parameter in terms of the size of an input. Expert programmers are familiar with a variety of well-established algorithms and their respective complexities, and use this knowledge to consider design trade-offs between, for example, memory consumption and performance.

Research in computer programming includes investigation into the unsolved proposition that P, the class of algorithms which can be deterministically solved in polynomial time with respect to an input, is not equal to NP, the class of algorithms for which no polynomial-time solutions are known. Work has shown that many NP algorithms can be transformed, in polynomial time, into others, such as the Travelling salesman problem, thus establishing a large class of "hard" problems which are for the purposes of analysis, equivalent.

Google Desktop for Linux!

Share |

Google has finally released a long-awaited native Linux application: Google Desktop for Linux. As with the already shipping OS X and Windows versions, Google Desktop enables Linux users to search for text inside documents, local email messages, their Web history, and their Gmail accounts.

This first beta version doesn't offer the sidebar and gadgets, which are found in other versions of the application. Those will come later, according to a Google representative, who stated, "We focused most of our efforts on desktop search. Gadgets and sidebar are not supported, but will probably be added in the future."

Well, no pretty sidebar with widgets yet, but that is soon to come! It is great to know that Google is making such an effort to bring their excellent products to all platforms! Download Google Desktop for Linux at the Google Desktop download page. Read more @ DesktopLinux.com.

Malawian teenage Windmill maker dominates TED Talks

Share |

At TEDGlobal 2007, participants were privileged to listen to great speakers give their well prepared talks in Arusha, Tanzania. And indeed, you'll agree with me when the videos get uploaded on web that they were great talks.

The sessions included both 18 minute talks and short 3 minute presentations by a diverse group of speakers including business leaders, artists, activists, engineers, inventors and musicians.

Among these was a 3 minute Question and Answer session where the curator Chris Anderson asked William Kamkwamba questions regarding the Windmill he created for his home in Kasungu, Malawi at the age of 14. Through the Questions with photos on the slides, William told his story which made people shed tears and later, give him a big applause and a standing ovation.

In the sessions that followed, William's story became the most cited talk among the talks at this conference. Speakers like Ory Okolloh of Kenyan Pundit, journalist Dele Olojede and Noah A. Samara of WorldSpace referred to William Kamkwamba's tale of invention in their sessions.

The picture above shows Ory Okolloh who included the photo of William's QnA session with Chris Anderson from the previous day in her slides.

Look out for the TED Talk videos from TEDGlobal 2007 when they're uploaded on TED's website.

Are we ready for shockbots?

Share |

Last week, iRobot - maker of the Roomba robot vacuum cleaner - announced that it was working with stungun maker Taser to mount the latter’s controversial 'neuromuscular incapacitation' weapons on iRobot’s military droid: the PackBot.

The Packbot is already used in Iraq and Afghanistan to defuse roadside bombs and recently these robots have been fitted with lethal weapons like machine guns and shotguns. But, until now, weaponised robots have been for military use only. The iRobot/Taser collaboration changes this as it is geared towards making robots capable of shocking people available to law enforcement as well as the military.

Taser says the technology will let officers use a robot to 'engage, incapacitate, and control dangerous suspects without exposing those personnel, the suspect, or bystanders to unnecessary risks.'

But I spoke to Neil Davison, head of non-lethal weapons research in the peace studies department at Bradford University in the UK, and he sees some potential risks.

'The victim would have to receive shocks for longer, or repeatedly, to give police time to reach the scene and restrain them, which carries greater risk to their health,' he said. 'All you are really doing is further removing the process of human interaction,"

Then there’s the possibility that such robots could someday be autonomous, decided for themselves whether a target represents a threat. It might seem far fetched, but it's something iRobot has in mind, and its a possibility that has some researchers worried.

"If someone is severely punished by an autonomous robot, who are you going to take to the tribunal? The robot won't talk," says Steve Wright of Leeds Metropolitan University in the UK. "

I’m wondering what kind of smart anti-shockbot technologies the likes of G8 protestors might come up with? Any ideas?

Real-world transformers

Share |

The new Transformers movie is science fiction at its most fantastic, featuring fighting robots that shift shape to fight each other, for example, transforming from an aircraft to a ground vehicle.

Meanwhile, the Pentagon has set it sights on developing machines with similar capabilities, although they are clearly still a few decades away from matching Optimus Prime.

The military already has uncrewed air vehicles (UAVs) like the Predator, and
uncrewed ground vehicles (UGVs) such as Talon, both of which have been used extensively in Iraq. Now they'd like something that can combine the abilities of both.

This document describes a contract for "Transforming [aerial] vehicles that land, transforming into UGVs capable of inspecting caves and/or buildings to find people" awarded to Thorpe Seeop, Arizona, US, by the US Army (scroll down to "Small Scale Unmanned Air Vehicle").

The company's starting point was the company's Spinwing UAV, an unusual craft that transforms mid-flight from an airplane into a helicopter.

This idea was the taken further by Brian Yamauchi of iRobot (the company behind a widely-used ground vehicle called PackBot). Yamauchi came up with Griffon, a hybrid designed to "combine the speed and range of a UAV with the precise ground mobility of a UGV."

Griffon has a powered parafoil wing that attaches to the PackBot chassis. Software enhancements include, "semi-autonomous launch and landing software [that] will assist the operator in transitioning from ground to air modes and back."

The Griffon prototype took off with an 11-metre parafoil wing and, although it could hardly be described as graceful, the concept proved viable as this video shows. Things did not always go quite so smoothly, however, as another clip reveals. Oops.

Interestingly, the US Air Force Research Laboratory has its own plans. Fred Davis, of the Assessment and Demonstrations Division recently told me that they are looking at small UAVs that can morph or otherwise change their shape, and switch between different modes. These might include flying, perching and hopping or crawling. This would extend their endurance, as well as allowing them to go into buildings.

Morphing wings have been investigated for some time, but the new craft would be more capable, for example, with wings which converted to legs. "We call them Transformers," said Davis.

New Batteries Readied for GM's Electric Vehicle

Share |

The technologies behind the battery packs for the GM Volt are being tested and could be ready within a year.

This week, General Motors (GM) announced its selection of battery makers to develop and test battery packs for use in its proposed electric vehicles. The selected battery makers, Compact Power, based in Troy, MI, and Continental Automotive Systems, based in Germany, say that they've overcome the performance and cost limitations that have been an obstacle to electric vehicles in the past.

Over the next 12 months, researchers from, Compact Power, Continental Automotive Systems and GM will be testing the battery-pack designs in the lab and in vehicles to confirm that the packs can work for the life of the car--at least 10 years, says Denise Gray, director of hybrid energy storage devices at GM. Initial tests of individual battery cells, along with projections about the performance of battery packs that can contain hundreds of these cells, have Gray optimistic that her company will have proven packs by June 2008.

If the packs perform well, they are slated for use in the proposed Chevrolet Volt, an electric concept car announced by GM in January. The Volt marks a change in emphasis for GM, which previously focused on more distant plans to bring hydrogen-fuel-cell-powered cars to market. The Volt could be ready within a few years. Until now, however, it has been unclear who would develop its advanced batteries.

There are a number of design variations for the Volt, but they will all be propelled by electric motors. In one version, the battery pack, which can be recharged by plugging it in, will provide 40 miles of range. Then an onboard gasoline- or ethanol-powered generator will kick in to recharge the battery, providing an additional 600 miles of range. A proposed hydrogen-fuel-cell version would have a smaller battery pack and no onboard generator.

To make batteries that are up to GM's specifications, battery makers have had to redesign the chemistry of lithium-ion batteries, a type of battery widely used in mobile phones and laptops. While lithium-ion batteries are light and compact, the type of lithium-ion battery typically used in electronic devices relies heavily on cobalt, an expensive metal. The cobalt oxide used in one of the battery's electrodes isn't thermally stable, making the batteries prone to bursting into flame if damaged or poorly manufactured--a shortcoming that led to the massive recall of millions of laptop computer batteries last year. (See "Safer Lithium-Ion Batteries.") This could be a problem in vehicle battery packs, which would be much larger than those in portable electronics, so an accident could be more dangerous.

One alternative is to replace cobalt with manganese. Mohamed Alamgir, director of research at Compact Power, says that manganese-oxide electrodes are significantly more thermally stable than cobalt oxide, and less expensive. The battery maker has also developed a new material for keeping the electrodes separate: the material remains stable at higher temperatures than conventional materials, further guarding against the runaway heating that causes batteries to catch fire. What's more, the company makes the batteries in a flat shape rather than in the typical cylindrical design. Alamgir says this flat shape prevents heat from building up at the center of the cell, making it easier to keep the battery at an even, cool temperature.

See-Through Transistors

Share |

Transparent transistors made from nanowires could mean bright and clear OLED displays.

Organic light-emitting diode (OLED) displays are currently found on mobile phones and digital cameras. But in the future, manufacturers expect bigger, bendable, and completely transparent versions. They envision bright maps on visors and windshields, television screens built into eyeglasses, and roll-up, see-through computer screens. And although the OLEDs themselves can be transparent, to make a clear display, the transistors that control each display's OLED, or pixel, need to be transparent as well.

Researchers at Purdue University and Northwestern University have now made flexible, see-through transistors using zinc-oxide and indium-oxide nanowires. By contrast, the amorphous or polycrystalline silicon transistors used in existing displays are not transparent. The new transistors also perform better than their silicon counterparts and are easier to fabricate on flexible plastic.

The transistors could lead to brighter see-through OLED displays, says Purdue electrical- and computer-engineering professor David Janes, who led the work published in last week's Nature Nanotechnology. When conventional nontransparent transistor circuitry is placed around the OLED, it takes up space on the display that could otherwise be emitting light. But, says Janes, "you could put transparent transistors underneath or on top of the pixel," increasing the light-emitting area.

To make the transistors, Janes and his colleagues first deposit an indium-zinc-oxide gate electrode on glass or plastic. Then they put a nanowire solution on the surface. After finding a nanowire that is aligned appropriately, they deposit source and drain electrodes made from indium tin oxide on either side of the nanowire. Both indium zinc oxide and indium tin oxide are transparent materials.

The nanowire transistors have high electron mobility, which determines how fast the transistor can work and how much current it can carry. In fact, the mobility is a few hundred times better than it is for transistors made from amorphous silicon, which is widely used in the electronics for displays. Because of that, the transistors could be made smaller and faster, Janes says. More-compact transistors, he says, would mean an even larger pixel area. What's more, the nanowire transistors are much easier to make on plastic than silicon transistors are because they don't need high-temperature processing.

Research groups have recently made transparent transistors using thin films of zinc oxide or indium oxide, or using carbon nanotubes. (See "Cheap, Transparent, and Flexible Displays.") Both technologies face unique issues. While the carbon-nanotube transistors have much better electron mobilities and are stronger than the new nanowire transistors, they aren't totally transparent because they need tiny metal contacts to connect the nanotubes to the electrodes. Thin-film transistors, on the other hand, are easier to fabricate on various surfaces but have much lower mobilities.

For the new transistors, "the performance in terms of the mobility, flexibility, and transparency is very impressive," says John Wager, an electrical-engineering and computer-science professor working in the area of transparent electronics at Oregon State University. Now the biggest remaining question, he says, is, "Can all of this be translated into real-world manufacturability?"

Right now, there is no method to control where nanowires get deposited on a surface or how they line up. "In experimental demonstrations, you throw down a couple thousand nanotubes and hope one aligns in the direction you want," Wager says. But randomly depositing nanowires on a surface will not work if one is to manufacture transistors for large displays.

Indeed, says Janes, "you have to have some way of putting the desired number of nanowires in the location you want." At this point, all three technologies to make transparent transistors--nanowires, thin films, and carbon nanotubes--have a fair shot at replacing silicon transistor technology for future transparent, flexible displays, Janes says.

According to John Rogers, a professor of materials science and engineering at the University of Illinois at Urbana Champaign, the ultimate commercial success of one of the three technologies will depend on how they measure up on many different factors: transparency, electrical performance, flexibility, and the ease and cost of manufacturing them. "It will be a good horse race to see which approach wins," Rogers says.

Nanotube Circuits Made Practical

Share |

Software can predict the best designs for fabricating logic gates from disorganized carbon nanotubes.

Many experts believe that carbon nanotubes could eventually replace silicon in microelectronics because of their potential for superior speed and reduced power consumption. And over the past several years, researchers have made transistors out of carbon nanotubes. However, it's still difficult to make reliable circuits out of them. One problem is that the nanotubes, used for transistors that make up the circuits, tend to be fabricated in different directions, making it impossible to know which nanotube form which transistor. And such a chaotic arrangement can lead to electrical malfunctions. But now researchers at Stanford University have written a program that finds a working circuit layout, no matter how disorganized or misaligned the nanotubes.

"Just having a single [carbon nanotube] transistor isn't going to do it," says Subhasish Mitra, assistant professor of electrical engineering and computer science at Stanford. It may not be possible to synthesize precisely organized nanotubes anytime soon, so Mitra and his team, which includes Stanford electrical-engineering professor H.-S. Philip Wong, University of Southern California chemistry professor Chongwu Zhou, graduate student Nishant Patil, and Jie Deng of Stanford electrical engineering, have turned to algorithms to make sense out of the nanotubes mess.

Circuits are made of logic gates that collectively generate instructions to, say, send a document to a printer or turn on a cell phone. Transistors are at the core of these logic gates, grouped in various ways to make up different types of gates. The researchers first approached the problem of making nanotube circuits by looking at a specific type of digital logic gate called a 2-input NAND gate, which contains two parallel transistors that can messed up by misaligned nanotubes. If electrical current flows through one or both of the transistors, then the gate is "on." If electrical current flows through neither, then the gate is "off." But if the transistors are haphazardly arranged, these gates can't operate properly.

"Even if current flows through neither of the transistors, the gate may be turned on by misaligned nanotubes," says Mitra, "and if you try to complete a logic function, it could create a short or give a wrong response." What his algorithm does, he explains, is find a way to lay out a circuit that keeps these nanotubes from creating shorts or incorrect logic gates.

To do this, the algorithm uses a combination of the mathematics of complicated networks and Boolean algebra to define various regions on a batch of nanotubes. Depending on the desired function of the circuit, a design is proposed that lays out legal and illegal regions for the gates to exist. When nanotubes cross the boundary into a particular region, explains Mitra, they are chemically etched away so that they won't conduct an erroneous current to another transistor. The researchers have generalized the approach so that it works not just for NAND gates, but for any arbitrary logic gate as well.

It's important to explore approaches such as these, says Naresh Shanbhag, professor of electrical engineering at the University of Illinois, Urbana-Champaign. "Nanotubes are considered to be a promising post-silicon device," he says. "Nanotube circuits need such techniques ... so that a circuit exhibiting reliable behavior can be designed."

The Stanford algorithm does not solve all the problems with carbon-nanotube transistors, however. In a typical batch of nanotubes, as much as 30 percent of them act as a metal, constantly conducting electricity (unlike a semiconductor), making them useless as transistors. Another issue, says Mitra, is that it's difficult to control the density of carbon nanotubes from one batch to the next. And if there isn't a sufficient density, then there simply aren't enough nanotubes to make logic gates for circuits.

Progress is being made on all these fronts, says Tom Theis, director of physical sciences at IBM's TJ Watson Research Center, in Yorktown Heights, NY. Researchers at IBM, for example, are developing ways to selectively remove unwanted nanotubes--metal nanotubes where semiconductor nanotubes are wanted, for example--to help pave the way for reliable devices. While the Stanford work doesn't resolve all the challenges facing nanotube electronics, Theis says that it's "an interesting piece of the puzzle."

Plastics from Sugar

Share |

New catalysts convert glucose into a valuable chemical feedstock.

Researchers at Pacific Northwest National Laboratory (PNNL) have come up with an easy, inexpensive method to directly convert glucose into a chemical that can be used to make polyester and other plastics, industrial chemicals, and even fuels.

Petroleum is commonly used to make plastics and various chemical products, such as fertilizers and solvents. But researchers are trying to find a simple and affordable way to convert the sugars, including glucose and fructose, in plants into compounds that can replace petroleum feedstocks. If successful, such technology could use a chemical made from corn, potatoes, and even grass to substitute for ones derived from oil.

While previous studies have shown various ways to chemically convert fructose and glucose into plastic intermediates and even fuels, these conversion processes are complicated and costly, and are only efficient for converting fructose. Glucose is a much more common sugar because it can be derived directly from starch and cellulose, both plentiful in plant material. "The major bottleneck has been to utilize nature's most abundant building block, which is glucose," says Z. Conrad Zhang, a scientist at PNL's Institute for Interfacial Catalysis, who led the work.

Zhang and his colleagues have developed a catalysis process to transform the sugars into an organic compound called hydroxymethylfurfural, or HMF, which can be converted into polyester and a diesel-like fuel. The technique, which the researchers describe in last week's Science, yields almost 90 percent of HMF from fructose and 70 percent from glucose.

The yield from fructose is similar to that reported in the past by other research groups, Zhang says. But he claims that his process is simpler, involving fewer steps, which would make it more cost-effective. Previous methods use an acidic catalyst, and the chemical reactions take place in a water-based solution, producing high levels of impurities. Instead of an aqueous solution, the PNL researchers use solvents known as ionic liquids, and they use metal chlorides as catalysts. The resulting chemical reaction gives nearly pure HMF, getting rid of the cost of purification, Zhang says.

After trying various metal chlorides, the researchers found that chromium chloride is the best catalyst for glucose. It gets the most HMF from glucose and works at temperatures of 80 °C for fructose and 100 °C for glucose.

The ability to make HMF directly from glucose and in relatively high yields has caught the attention of some experts. The new technique is a step in the right direction, says Leo Manzer, president of Catalytic Insights, a consulting firm based in Wilmington, DE. "What folks have been looking for is a cheaper feedstock and a good way to make HMF," he says. "This is a very unique, remarkable system that [Zhang] has discovered."

The ultimate goal will be to build an economical reactor that can convert cellulosic biomass, such as grass and plant stalks, into HMF. Zhang says that his research team is already working on a method to utilize cellulose directly. However, he says, the first step will be to develop a commercial process for converting glucose into HMF, and that will take several years.

Storing Light

Share |

A new optical device could make high-speed computing and communications possible.

A microscopic device for storing light developed by researchers at Cornell University could help free up bottlenecks in optical communications and computing. This could potentially improve computer and communications speeds by an order of magnitude.

The new device relies on an optically controlled "gate" that can be opened and closed to trap and release light. Temporarily storing light pulses could make it possible to control the order in which bits of information are sent, as well as the timing, both of which are essential for routing communications via fiber optics. Today, such routing is done, for the most part, electronically, a slow and inefficient process that requires converting light pulses into electrons and back again. In computers, optical memory could also make possible optical communication between devices on computer chips.

Switching to optical routing has been a challenge because pulses of light, unlike electrons, are difficult to control. One way to slow down the pulses and control their movement would be to temporarily confine them to a small continuous loop. (See "Tiny Device Stores Light.") But the problem with this approach is getting the light in and out of such a trap, since any entry point will also serve as an exit that would allow light to escape. What's needed is a way to close the entryway once the light has entered, and to do so very quickly--in less time than it takes for the light to circle around the loop and escape. Later, when the light pulse is needed, the entryway could be opened again.

The Cornell researchers, led by Michal Lipson, a professor of electrical and computer engineering at the university, use a very fast, 1.5-picosecond pulse of light to open and close the entryway. The Cornell device includes two parallel silicon tracks, each 560 nanometers wide. Between these two tracks, and nearly touching them, are two silicon rings spaced a fraction of the width of a hair apart. To trap the light in these rings, the researchers turned to some of their earlier work, in which they found that the rings can be tuned to detour different colors by shining a brief pulse of light on them.

Light of a certain color passes along the silicon track, takes a detour through one of the rings, and then rejoins the silicon track and continues on its way. However, if the rings are retuned to the same frequency the moment after a light pulse enters a ring, the light pulse will circulate between the rings in a continuous loop rather than rejoin the silicon track and escape. Tuning the rings to different frequencies again, such as by shining another pulse on one of the rings, allows the light to escape this circuit and continue on to its destination.

Work remains to be done before such a device will function in a commercial system. So far, the rings only capture part of a pulse of light. As a result, any information encoded in the shape of the overall pulse is lost. This can be solved by compressing the pulse and using a cascade of rings, says Mehmet Yanik, a professor of electrical engineering and computer science at MIT.

The other issue is that the length of time a light pulse can be stored is relatively short, Lipson says. If the light stays in the ring for too long, it will be too weak to use. Lipson says it might be possible to make up for light losses by amplifying the light signal after it leaves the rings to restore any lost power.

Other schemes for storing light have been demonstrated in the past, but these were impractical, requiring carefully controlled conditions, for example, or a large, complicated system. The new approach is an important step forward because it makes it possible to store light in ambient conditions and in a very small device, says Marin Soljacic, a professor of physics at MIT. Once you've done that, he says, "then it becomes interesting to industry."

Molten Mirrors

Share |

Liquid mirrors could enable more-powerful space telescopes.

Canadian researchers have developed a liquid mirror that could operate in a future telescope located on the moon, allowing researchers to peer back into the origins of the universe with extraordinary clarity. Telescopes relying on liquid mirrors can be hundreds of times more powerful than those with glass mirrors--for the same cost--and they should be easier to assemble in space.

A liquid-mirror telescope could reveal much fainter objects than the Hubble Telescope can, says Ermanno F. Borra, a physics professor at the Université Laval, in Quebec, who is leading the development of the new mirror. The power of a telescope is proportional to the surface area of its mirror. The James Webb telescope, which is scheduled to launch in 2013 and is far more powerful than the Hubble, has a diameter of about six meters. (See "Giant Mirror for a New Space Telescope.") A lunar liquid-mirror telescope could be as large as 20 to 100 meters, says Borra.

The liquid mirror, which was funded by NASA, consists of a pool of an ionic liquid coated with a film of silver. Such ionic liquids are carbon-containing salts that freeze only at very low temperatures and have very high viscosity. The salt used in the Laval mirror is liquid down to -150 ºC and does not evaporate below room temperature, even in a vacuum--suggesting that it could withstand the harsh environment of the moon.

There are two limitations on cosmologists' observations of the early universe: "The objects you want to observe are incredibly distant and incredibly faint," says Borra. Telescopes in orbit like the Hubble, whose views are unobstructed by Earth's atmosphere, are limited in size and power; telescopes on Earth can be larger and more powerful but produce fuzzier images because of the atmosphere. Liquid mirrors couldn't go into orbit, but they could operate on the moon, which has no atmosphere.

Large, powerful liquid-mirror telescopes should be less complicated to take into space than their glass counterparts. "To put a glass mirror into a rocket, you have to break it into segments and then reassemble them," says Borra. "You can carry a liquid mirror in a jug." But none developed so far have been space worthy. The University of British Columbia's Large Zenith Telescope uses a liquid mirror made of mercury to observe the early universe. Mercury solidifies at -40 ºC--much warmer than the temperature on the moon.

Borra searched for a better liquid to make telescope mirrors and found that ionic liquids seemed promising. Unlike mercury, however, these molten salts are not reflective, and they require a metal coating to function as a mirror. "Depositing a layer of silver on liquid is like painting on air," says Borra. Laval graduate student Omar Seddiki adapted the technique used to coat glass mirrors: in a vacuum chamber, Borra and Seddiki run an electrical current between pieces of silver, which vaporize and form a thin coating over the liquid salt. The Laval researchers have so far made a small mirror, about two inches in diameter, to demonstrate the technology.

Making a large, perfectly smooth, concave optical surface out of glass is an involved and expensive process. Very tiny flaws in the glass can make a mirror unusable. The containers that hold liquid mirrors, says Borra, don't need precisely smooth surfaces and would be much cheaper to manufacture. Telescopes that rely on liquid mirrors would cost about 100 times less than glass-mirror telescopes of comparable size, says Borra.

"The forces of nature conspire to give the right shape," Borra says of liquid mirrors, which need only be rotated to form a flawless reflective surface. As the mirror spins, centrifugal force and gravity pull the liquid into a smooth parabola. Unlike with a glass mirror, if the liquid is perturbed, it can move right back into shape.

Borra expects that a liquid-mirror telescope would be assembled on the moon by robotics. "A container holding the liquid will be sent to the moon and opened up like an umbrella," he says of an imagined future system. A liquid-mirror telescope could not be put into orbit because gravity is necessary to form the optical surface--and because it would spill.

"There's a tremendous amount of research to be done" to fine-tune the mirror, cautions Robin D. Rogers, a chemistry professor at the University of Alabama. He points out that there are hundreds of other ionic liquids that might have a better set of properties than those used in the Laval mirror.

"It may take 20 years before it's built," Borra says of his telescope. If it does come about, however, such a system could help cosmologists observe faint signals from when the universe was only a billion years old, "at that time when matter first assembled into stars, stars into galaxies," says Borra.