Skip to main content
Commonmark migration
Source Link

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

 
  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).
 

So, Ruby was a Lisp originally, in theory.

 

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is an efficient way to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

 
  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).
 

So, Ruby was a Lisp originally, in theory.

 

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is an efficient way to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is an efficient way to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

added 7 characters in body
Source Link
coredump
  • 6k
  • 2
  • 23
  • 30

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is an efficient way to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is efficient to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is an efficient way to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

added 227 characters in body
Source Link
coredump
  • 6k
  • 2
  • 23
  • 30

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read-time time and can be compared by identity, which is efficient to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read-time and can be compared by identity. This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

The creator of Ruby, Yukihiro "Matz" Matsumoto, posted an explanation about how Ruby was influenced by Lisp, Smalltalk, Perl (and Wikipedia says Ada and Eiffel too):

Ruby is a language designed in the following steps:

  • take a simple lisp language (like one prior to CL).
  • remove macros, s-expression.
  • add simple object system (much simpler than CLOS).
  • add blocks, inspired by higher order functions.
  • add methods found in Smalltalk.
  • add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory.

Let's call it MatzLisp from now on. ;-)

In any compiler, you are going to manage identifiers for functions, variables, named blocks, types, and so on. Typically you store them in the compiler and forget about them in the produced executable, except when you add debugging information.

In Lisp, such symbols are first-class resources, hosted in different packages, which mean you can add fresh symbols at runtime, bind them to different kind of objects. This is useful when meta-programming because you can be sure you won't have naming collisions with other parts of the code.

Also, symbols are interned at read time and can be compared by identity, which is efficient to have new kind of values (like numbers, but abstract). This help writing code where you use symbolic values directly, instead of defining your own enum types backed by integers. Also, each symbol can hold additional data. That's how, for example, Emacs/Slime can attach metadata from Emacs right into a symbol's property list.

The notion of symbol is central in Lisp. Have a look for example at PAIP (Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp, Norvig) for detailed examples.

Source Link
coredump
  • 6k
  • 2
  • 23
  • 30
Loading