|
|
Re: Why I Decided to Design a Programming Language
|
Posted: Oct 25, 2004 12:24 PM
|
|
> * 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.
|
|
Previous Topic
