Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mal – Make a Lisp, in 68 languages

github.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Mal – Make a Lisp, in 68 languages

#51

Post by flavio81 »

Sjenk wrote: post #34

I am curious why is hackernews always so happy and obsessed with lisp, there is almost daily a lisp post on the frontpage. I dont really care/mind but I am just curious as why people love lisp so much. The only thing that I notice about Lisp are the bracket jokes and memes.

>I am just curious as why people love lisp so much.

Lisp is addictive, like a hard drug.

Lisp is the original "programmable programming language".

Experienced programmers with no previous knowledge of Lisp should relish (or doubt in disbelief) at the features provided.

Lisp, at least Common Lisp (but other Lisp dialects as well) might claim to be the most powerful and versatile programming language (and environment) available.

CL can run pretty fast. At the same speed than Java on the oracle JVM, and if some tricks are applied it should match C and Fortran speed under certain conditions. CL code is extremely portable.

Lisp has been used for very high level tasks (AI, etc) and for low level tasks (operating systems for Lisp machines).

Re: Mal – Make a Lisp, in 68 languages

#52

Post by [deleted] »

jdmoreira wrote: post #39
Sjenk wrote: post #34

I am curious why is hackernews always so happy and obsessed with lisp, there is almost daily a lisp post on the frontpage. I dont really care/mind but I am just curious as why people love lisp so much. The only thing that I notice about Lisp are the bracket jokes and memes.

Lisps have properties that are not so common in other languages: - Homoiconicity: Code and data are the same (s-expressions) - Lisp code is basically the AST in itself - It's trivial to implement lisp in lisp (eval) - Continuations (call/cc) - Macros - etc... It's a truly fascinating language. I never really did any Lisp coding outside some university projects and I still obsess and read about Scheme all the time.

[deleted]

Re: Mal – Make a Lisp, in 68 languages

#53

Post by flavio81 »

spc476 wrote: post #44
josmar wrote: post #42

Earlier quoted context omitted.

After being a user of languages for a long time, writing my own LISP was the experience of leaving Platons cave and seeing what the thing I use daily really is made of. What is "if"? What is a boolean, a variable, a function? It's a beautiful thing. I wish I would never have to climb down into the cave (languages with more advanced parsers) again.

You climed in the wrong direction. What you want is assembly. That's where software ends up. Also, it's interpreters all the way down. Even assembly is interpreted.

>What you want is assembly.

Which you can code in a convenient way by using Lisp and Lisp macros to generate the machine language output using opcodes.

Re: Mal – Make a Lisp, in 68 languages

#54

Post by [deleted] »

copx wrote: post #9
gbacon wrote: post #7

Earlier quoted context omitted.

In struct MalVal[0], the values f0 through f20, where each holds a pointer-to-functions of the corresponding arity, live in a big (multifacted?) union. Using arg_cnt, the switch assigns func to the appropriate value in mv->val using the appropriate cast. For example, when arg_cnt is 2, mv->val.f2 receives func converted to void * (* )(void* , void* ), that is, pointer to a function that accepts two parameters of type…

This could be made massively less ugly and more readable by typedef'ing the function pointer types by the way. Then one could just write: case 13: mv->val.f13 = (F13)func; break; As a C programmer I got to say people in general don't use typedef for function pointer types often enough. The types are so ugly and verbose, they should be typedef'ed by default.

[deleted]

Re: Mal – Make a Lisp, in 68 languages

#55

Post by flavio81 »

arunc wrote: post #41

I tried finding the lines of code in each language with cloc. C/C++ Header contains a sum of C and CPP header files. Python has been used across different language dirs as wrapper script or so, otherwise, it's own implementation is probably 1350 lines at max. This would also probably include bugs in cloc. github.com/AlDanial/cloc v 1.70 T=2.86 s (433.6 files/s, 67570.0 lines/s) ---------------------------------------…

Note that the number of intermediate "steps" uploaded to github, as well as the number of tests, differ for each language.

Re: Mal – Make a Lisp, in 68 languages

#57

Post by dragandj »

Sjenk wrote: post #34

I am curious why is hackernews always so happy and obsessed with lisp, there is almost daily a lisp post on the frontpage. I dont really care/mind but I am just curious as why people love lisp so much. The only thing that I notice about Lisp are the bracket jokes and memes.

> The only thing that I notice about Lisp are the bracket jokes and memes.

You have also noticed that lots of people use it to create cool things which reach the HN front page.

Re: Mal – Make a Lisp, in 68 languages

#58

Post by kazinator »

copx wrote: post #9
gbacon wrote: post #7

Earlier quoted context omitted.

In struct MalVal[0], the values f0 through f20, where each holds a pointer-to-functions of the corresponding arity, live in a big (multifacted?) union. Using arg_cnt, the switch assigns func to the appropriate value in mv->val using the appropriate cast. For example, when arg_cnt is 2, mv->val.f2 receives func converted to void * (* )(void* , void* ), that is, pointer to a function that accepts two parameters of type…

This could be made massively less ugly and more readable by typedef'ing the function pointer types by the way. Then one could just write: case 13: mv->val.f13 = (F13)func; break; As a C programmer I got to say people in general don't use typedef for function pointer types often enough. The types are so ugly and verbose, they should be typedef'ed by default.

This code could take advantage of the fact that the type is a union.

One can bend the rules of prim-and-proper well-defined ISO C just a little bit and assign to the simplest function pointer, taking advantage of all function pointers having the same representation on every machine known to mortal hacker, and all being overlaid by the union. Thus all the cases collapse down to this:

   mv->val.u.f0 = (void (*)(void)) func;
done. Now if this is 13 arguments, then strictly speaking, accessing mv->val.uf13 is not well-defined behavior. That's only going to be problem when it actually doesn't work, though. A big problem, then. :)

Re: Mal – Make a Lisp, in 68 languages

#59

Post by kanaka »

arunc wrote: post #41

I tried finding the lines of code in each language with cloc. C/C++ Header contains a sum of C and CPP header files. Python has been used across different language dirs as wrapper script or so, otherwise, it's own implementation is probably 1350 lines at max. This would also probably include bugs in cloc. github.com/AlDanial/cloc v 1.70 T=2.86 s (433.6 files/s, 67570.0 lines/s) ---------------------------------------…

Every implementation has a stats target that gives byte counts, LOCs, and comments that is specific to that implementation. I.e. from the top-level you can run the following to get stats for every language:

  make stats
or for more condensed form:

  make stats | egrep "Running|total|comments"

Re: Mal – Make a Lisp, in 68 languages

#60

Post by kanaka »

flavio81 wrote: post #55
arunc wrote: post #41

I tried finding the lines of code in each language with cloc. C/C++ Header contains a sum of C and CPP header files. Python has been used across different language dirs as wrapper script or so, otherwise, it's own implementation is probably 1350 lines at max. This would also probably include bugs in cloc. github.com/AlDanial/cloc v 1.70 T=2.86 s (433.6 files/s, 67570.0 lines/s) ---------------------------------------…

Note that the number of intermediate "steps" uploaded to github, as well as the number of tests, differ for each language.

The steps and main files are the same for every implementation (that's part of the requirements for merging into the main tree). Some implementations have additional files like readline, utility routines, etc. But for the most part the general structure and file divisions are very similar.
Post reply on HN