Post has attachment
This guy is clueless about modern practices.


The way to determine if year is a leap year:

is_leap_year = year % 4 == 0;
is_leap_year = year % 100 != 0;
is_leap_year = year % 400 == 0;

This is easy to understand and faster than his method.

Multiple inheritance

Has_a relationships are easier to understand than is_a ones. Also, if the attributes are all private, they can only be accessed within methods. Having is_a relationships would complicate objects and be harder to understand.


Aside from being highly dangerous, eval is a kludge for badly designed languages. Anything eval can do, can be designed into a language without the danger.


Recursion is good for a first attempt at problem. But it can always be converted to a loop, which is faster. People don't understand the four steps of recursion and find it difficult to use. Hence, they ignore it.

Four Steps of Recursion:

Post has attachment

Post has attachment

Pointers should be a problem for language designers and compiler writers, not
on for the typical programmer. Of course, with a Von Neumman architecture, it is impossible to have a program without them but they should be under the hood for most programmers. The issue is: how to hide them from the typical programmer without sacrificing usability?

For objects (or other data structures), the need to deal directly with pointers can be eliminated with automatic memory allocation and a good garbage collector. But what about first-class functions? Can the visibility of pointers to function be hidden?

What can be done with pointers to function?

1. They can be created, that is, there must be a way to specify that a pointer is wanted and not call the function immediately.

2. They can be copied and passed around.

3. They can be called.

There is a problem here. The 2nd activity means the function could be call out of context. This is a problem in OOLs. For purely-functional languages, there is no stored state and therefore, no context.  Functions may be called anywhere. But OOLs are the antithesis of functional programming; objects have a stored, hidden state. This means it is possible to call a pointer to a function out of context for that function, which would create unpredictable results.

To deal with these issues, consider the following proposal: allow methods of a class to be replaceable.

Say there is a class X with a replaceable method, foo(). Class X implements some reasonable default behaviour for foo(). It then can use foo() in other methods.

Now there is another class, Y, which creates object x of class X and replaces foo() with it's own function bar(). Both foo() and bar() must have the same signature. That means whenever Y calls a method of X, which in turn, calls foo(), foo() is replaced with In other words, even though the code says foo(), it actually calls This is necessary because bar() requires to run inside Y's context, not X's.

Of course, this requires pointers but they are hidden from the programmer. It does add some confusion about which context the function is called in. Perhaps this can be clarified with an appropriate syntax.

On side effect is that interfaces, are just classes with all of their methods being replaceable.

Does anyone have any thoughts on improving this?

Post has attachment
Hi there!
Does anybody here know JavaScript.
I'm having trouble with my new language that compiles to it...

Post has attachment

Post has shared content
Autothreading is when the language decides where threads should be used. Getting it just right is a difficult balancing act.
Part of the design of the Kori language is to incorporate autothreading. Autothreading is when the language decides where threads would be useful, removing the burden from the programmer. The main problem with autothreading is determining what size chunks s...

Post has shared content
A Restart

After a serious illness, I starting work again on my programming language.

Types fall into three categories:

1. Scalar -- these hold only one datum, such as text, numbers, dates, money. People are used to automatically convert these types and have difficulty when computers do not. This is where weak, dynamic typing shines.

2. Composite -- examples: OOP classes, DB tuples & tables, C structs & unions. These types combine scalars and composite types together. This is where strong, static typing shines.

3. Container -- examples: lists, arrays, trees, association lists, sets, bags. These types are heterogeneous and generic. They are used to
preserve a structure. They are iterated or walked to process their data. Again, dynamic typing works well with them.

Why Arrays?

I do a lot of programming in Perl and I can't remember the last time I used indexing to access an array. Most of the time I use Perl's
built-in iterator, the foreach loop. With its push, pop, shift, and unshift there is little need for indexing.

So, my question is: are arrays truly needed? Could they be replaced with double-ended queues (dequeues)? With a function like Perl's splice() which allows random-access de- and re-construction. Since most of the time, the whole list is iterated, dequeues are easily processed. And they don't have the copying overhead that dynamic arrays do when they grow.

Except for text, of course, which is a whole other can of worms.
Wait while more posts are being loaded