The Artima Developer Community
Sponsored Link

Weblogs Forum
Why I Decided to Design a Programming Language

5 replies on 1 page. Most recent reply: Oct 26, 2004 6:28 PM by Jordan Zimmerman

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Why I Decided to Design a Programming Language (View in Weblogs)
Posted: Oct 24, 2004 5:59 PM
Reply to this message Reply
Summary
I designed the Heron programming language because, like many other programmers, I was dissatisfied with other languages. In this entry I list some the features that what I was looking for in a programming langauge.
Advertisement
The answer the commonly asked question: "Why did you write a programming language" is that I am dissatisfied with the other programming languages that I have studied, worked with or come into contact with over many years of working as a software developer. I have consistently found myself fighting the language to get it to do what I wanted, correctly, succintly and efficiently.

Over time I developed a feature wish list for my ideal programming language. Rather than being a reasonable man and adapting myself to existing languages, I decided to design my own programming language. Here is a summary of the feature wish list that inspired me:

  1. OOP (Object Oriented Programming)
    Encapsulating data and methods is one of the best things to happen in computer science since the invention of the subroutine.
  2. Easy to Read and Write
    Some languages are very obfuscated when it comes to any kind of sophisticated code.
  3. User Defined Value Types
    Without value types it means we are stuck with whatever primitives the language designers decide to throw us, along with whatever predefined behaviours. No matter how hard a language designer tries, it is virtually impossible to provide all of the conceivable value types a programmer may need.
  4. First Class User Defined Types
    Too often in languages user defined types are either inefficient, or crippled in some way when compared to the built-in types. For instance, many languages don't allow casting but the built-in primitives follow magical promotion rules. This is frustrating and unneccessary.
  5. Efficient
    Moore's law not withstanding, software shouldn't be a needless cpu or memory hog. Because today's software is more sophisticated, and more is expected from it, efficiency is as much a concern now as ever.
  6. Interfaces
    Object oriented software design starts with interfaces. Unfortunately most interfaces are implemented as abstract base classes. ABC's are slow, inefficient, and force pointless virtualization of functions, just to achieve a degree of run-time polymorphism.
  7. Delegation
    Sometimes delegation of interface implementations to member fields makes much more sense in a software design than simple inheritance. There is no reason not to have this functionality.
  8. Parameterized Types
    Parameterized types have been in use as long as typed arrays have existed, it is just illogical to not allow parameterization of other types.
  9. Imperative Programming
    Certain classes of algorithms are not easily expressed in pure functional languages. It is an arbitrary restriction which provides no practical advantage.
  10. AOP (Aspect Oriented Programming)
    Aspect oriented programming allows full use of PwC (Programming with Contracts) by making it easy to express invariants. It also allows us to simply express some otherwise very complex designs.
  11. No Garbage Collector
    Garbage collectors are inefficient, and they make it hard to use the useful RAII (Resource Acquisition is Initialization) technique. I would rather have control over memory management, but have help doing so from the language.


Jordan Zimmerman

Posts: 23
Nickname: jordanz
Registered: Jul, 2003

Re: Why I Decided to Design a Programming Language Posted: Oct 25, 2004 1:38 PM
Reply to this message Reply
Garbage collectors are inefficient, and they make it hard to use the useful RAII

Please explain this. I don't see how the Garbage collector affects RAII one way or the other. Resource allocation/deallocation is an abstract concept. When the backing store is released is a low level operating system issue.

Easy to Read and Write
I looked at some Heron example code and it didn't seem easy to read to me. It looked a lot like C++ which is impossible to read.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Why I Decided to Design a Programming Language Posted: Oct 25, 2004 3:02 PM
Reply to this message Reply
"Resource allocation/deallocation is an abstract concept."

I don't understand what you mean by that.

"When the backing store is released is a low level operating system issue."

Not all resources are system resources, some are abstract resources defined by the programmer. Heron is designed to allow the possibility of low-level programming. It simply depends on how low-level the system library is.

"It looked a lot like C++ which is impossible to read."

Compared to what language?

Heron syntax is indeed C++ inspired (i.e. Algol and Fortran derived), but there are many improvements such as: strict layout order of modules, strict layout order within classes, improved template syntax, consistent constructor / destructor naming, no macros (conditional compilation is done through the metaprogramming subsystem), etc.

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Why I Decided to Design a Programming Language Posted: Oct 25, 2004 3:24 PM
Reply to this message Reply
> * Easy to Read and Write
> Some languages are very obfuscated when it comes to
> any kind of sophisticated code.

This is very subjective. Every language is claimed by its author to be readable and easy to write, and opinions of other people vary.

> * User Defined Value Types

What do you mean by "value types"? How are they different from other types?

Do you mean, contrasted to references? Most languages have only one kind of types, with the semantics of references. Some of them can be implemented as value types, invisibly to programmers (sometimes even depending on the actual value: fixnums vs. bignums). This is equivalent, as long as these values are immutable and we don't try to apply reference equality to them.

Or do you mean something else?

> * Imperative Programming
> Certain classes of algorithms are not easily expressed
> in pure functional languages. It is an arbitrary
> restriction which provides no practical advantage.

What is wrong with impure functional programming? It means not introducing side effects unnecessarily. For example by making most values immutable, especially small values, and using APIs which generally return new values instead of mutating values in place; by having the appropriate semantics of loops, which conceptually create a new control variable for each iteration rather than mutate the same variable (this matters for closures, especially executed by separate threads); by properly optimizing tail calls, especially tail recursion, which allows expressing loops without mutation; and generally by tuning the performance toward fast allocation at the cost of slow mutation (this is taken by Java recently, even though its roots are imperative).

> * No Garbage Collector
> Garbage collectors are inefficient, and they make it
> hard to use the useful RAII (Resource Acquisition is
> Initialization) technique.

Efficiency depends on the programing style, because garbage collection allows for faster allocation and faster non-local exits. It also allows to omit program logic used for tracking liveness of references (e.g. reference counts), which is done more efficiently by the runtime which has access to whole program data.

Programs written in a non-GC'ed language are efficient only when they avoid heap-allocated objects, prefer large objects to graphs of small objects, avoid making temporary objects for passing a few values together, prefer fixed size arrays to arrays which can accommodate any amount of data, avoid using function closures to pass pieces of code at runtime, prefer arrays to linked lists etc. It constains programming style by making allocation of small objects relatively expensive and forcing the programmer to deal with their deallocation - even in cases when it doesn't really matter when they are deallocated, as long as it happens when it's no longer used and not too much time after that.

You can't be more friendly both to the programmer and to the machine: either the human can freely create new objects to express his mind, or he must be careful to put these objects in places convenient for the machine.

RAII is a syntactic detail. If you don't insist on letting it look exactly as creating an object inside a local variable ("an object inside a variable" is nonsensical in most languages anyway), resources can also be explicitly freed in a GC'ed language: see e.g. C# using keyword.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Why I Decided to Design a Programming Language Posted: Oct 26, 2004 1:20 PM
Reply to this message Reply
Marcin, you misunderstand that the list was intended as a subjective list of what I was looking for in a programming language.

Value types refers to types with copy semantics like Java primitives. Nothing is wrong with impure functional languages. C and Fortran outperform any garbage collected language in most non-trivial benchmarks. I wanted a language which would allow that level of performance when needed.

Jordan Zimmerman

Posts: 23
Nickname: jordanz
Registered: Jul, 2003

Re: Why I Decided to Design a Programming Language Posted: Oct 26, 2004 6:28 PM
Reply to this message Reply
"Resource allocation/deallocation is an abstract concept."
I don't understand what you mean by that.

I meant to distinguish it from GC which is a low-level concept. GC is concerned with releasing the bits allocated for an object when the object is no longer referenced. In my mind, this is different conceptually from allocation/
RAII. In Java, I can do RAII on any conceivable resource. Why should a programmer care how/when/where the bits come from?

Flat View: This topic has 5 replies on 1 page
Topic: On Promoting and Designing a Programming Language Previous Topic   Next Topic Topic: Programming with Contracts


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us