Wisdom from the Land of Lisp

There are just a few syntaxes around. We have Algol which coveres almost all the programming languages like SQL, Python, Pascal, PHP, and JavaScript. Some might say most of these are C, or B and they are right since these were the first to replace the typical begin with {. Looking at your profile you know mostly algol dialects and when you learned the last one it probably was simple since you already knew much from the knowledge of their sibling languages. You didn't learn a new language but a variant of one you already knew.

Lisp came in the late 50s and it had symbols and lists. It's syntax was not based on Fortran, that was the language of choice at the time. The original paper expressed eval using a few primitives. You can read about this in Paul Grahams excellent essay. If you know one dialect it's as easy to learn another in the same manner as with algol dialects. Trying to learn a lisp dialect by assimilating algol was very frustrating for me so I know this by experience.

Wikipedia has an excellent programming language tree you can browse. Like in natural language you have crazy languages like Finish that is not where to be found on the indieuropean language tree. You have such islands in programming languages as well. Lisp and Algol are truely different worlds even with some influenced over the decades.

As to the answer of what is needed for it to be a lisp dialect it's a little hazy, but I would include all languages that has one of these features:

Fully parenthesized polish prefix notation. (S-expressions)

cons,car,cdr and a symbol type with functions being first class citizens. eg. you can create mapcar (map in scheme)

Of course a undeniable lisp dialect would have both of these, but I would consider every language that only has one as lisp as well.

Sassy is intel assembly with better (lisp) syntax. It can perhaps expand macros and use the features of Scheme so it's a lisp but its restricted so not all would see it as a lisp dialect.

The creator of JavaScript, Brendan Eich, originally wanted to make a Scheme dialect. JavaScript is very close to be a Lisp but I still don't consider it a lisp since it has neither of my lisp feature sets. If they had made a singly linked lists a part of the spec I would have considered calling it a Lisp dialect with very bad looking syntax. Other people might include JS as a lisp.

Is it hard to write cons,car,cdr functions in other languages?

>>2
No. Just the eval() and reading code as data is hard and leads to potential security issues. If Lisp was mainstream, how secure you think will be that everything running around is a full-fledged runtime interpreter.

I don't like the half-baked OOP facilities that were shoehorned into Javascript. I really wish that new, this, super, and the whole prototype chain had never been added. Instead, the language should have been given optional typing like Typescript has. This means that everyone would be forced to use what Douglas Crockford calls the "factory pattern," in which objects (i.e., primitives, arrays, maps, etc) are returned by calls to functions.

>>4
One day, JavaScript will have everything you want. Common Lisp and C++ prove that you can add anything you want to any language. Programs don't have to fit on a floppy anymore.

Prototype-based OOP > the ``factory pattern"

>>4

the "factory pattern," in which objects (i.e., primitives, arrays, maps, etc) are returned by calls to functions

struct thing {
int i;
double d;
};

struct thing *
make_thing(int i, double d)
{
struct thing *res;

if (!(res = malloc(sizeof(struct thing))))
return NULL;

res->i = i;
res->d = d;
return res;
}

void
free_thing(struct thing *t)
{
free(t);
}

>>7
http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html

>>8
I wish LAC was still here to see this Sepples abomination.

>>8
GCC attributes are a nice toy, but useless in the real world since they're non-portable. If your program really requires destructors, you might as well use a language that actually supports them properly, rather than using a non-standard hack.

>>10
GCC C is incredibly common in the real world. Just look at Linux or most GNU programs.

Chances are that nobody will ever compile your programs with anything other than gcc, and even if they do, they would use clang which also supports it.

>>12
Oracle Developer Studio supports it as well.


# define __TGMATH_BINARY_REAL_IMAG(Val1, Val2, Fct, Cfct) \
(__extension__ (((sizeof (__real__ (Val1)) > sizeof (double) \
|| sizeof (__real__ (Val2)) > sizeof (double)) \
&& __builtin_classify_type (__real__ (Val1) \
+ __real__ (Val2)) == 8) \
? ((sizeof (__real__ (Val1)) == sizeof (Val1) \
&& sizeof (__real__ (Val2)) == sizeof (Val2)) \
? (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
__tgml(Fct) (Val1, Val2) \
: (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
__tgml(Cfct) (Val1, Val2)) \
: (sizeof (__real__ (Val1)) == sizeof (double) \
|| sizeof (__real__ (Val2)) == sizeof (double) \
|| __builtin_classify_type (__real__ (Val1)) != 8 \
|| __builtin_classify_type (__real__ (Val2)) != 8) \
? ((sizeof (__real__ (Val1)) == sizeof (Val1) \
&& sizeof (__real__ (Val2)) == sizeof (Val2)) \
? (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
Fct (Val1, Val2) \
: (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
Cfct (Val1, Val2)) \
: ((sizeof (__real__ (Val1)) == sizeof (Val1) \
&& sizeof (__real__ (Val2)) == sizeof (Val2)) \
? (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
Fct##f (Val1, Val2) \
: (__typeof ((__tgmath_real_type (Val1)) 0 \
+ (__tgmath_real_type (Val2)) 0)) \
Cfct##f (Val1, Val2))))


>>14
Thats what LISP looks to me.

>>14
C is almost as ugly as LISP.

>>16
Only if you try