search

kanaka / mal

mal - Make a Lisp
Other
10.06k stars 2.55k forks source link

Project is too addictive #561

Closed wgmyers closed 3 years ago

wgmyers commented 3 years ago

Thank you for Mal.

Having now implemented Mal in Ruby up to step A and including self-hosting, I have learned a great deal about Ruby and even a certain amount of Lisp. It has consumed all my free time over the last couple of weeks and I am very glad to have done it.

I'm not sure that there would be any interest my second, definitely-not-as-good-or-idiomatic-as-the-first Ruby implementation, so I doubt I'll go ahead and do the Docker / pull request thing, but if I go for a round 2 in COBOL (I might, given that it's missing and that I played around with COBOL a bit earlier this year) I'll let you know.

All that said, I am semi-serious in raising this as an issue: perhaps some kind of warning in the main README along the lines of 'you may find that embarking on your own Make-A-Lisp journey is more addictive than you realise' would be in order.

Thanks again.

wasamasa commented 3 years ago

I agree with the fun bit being almost addictive.

Regarding COBOL, I've made this repository to test languages before implementing MAL in them. I have an incomplete uncommitted cobol directory because I didn't understand it sufficiently to actually write functions (that is, the kind accepting arguments) as opposed to subroutines (which don't accept arguments). This feature seems to have not made it into COBOL at all and will require careful coding to work around, like figuring out a calling convention or something. I don't consider COBOL a general-purpose programming language for that reason and can only commend you for your bravery to consider using it.

kanaka commented 3 years ago

@wgmyers To be honest, the addictive nature was not entirely unintentional. After I realized that the project would be useful as a pedagogical tool for others, I applied aspects of "gamification" to the structure of the project. I even did a talk in 2015 (https://www.youtube.com/watch?v=lgyOAiRtZGw) about how the make-a-lisp process fulfills the five aspects of gamification defined by Charles Coonradt in "The Game of Work": Goals, Scorekeeping, Choice, Coaching, Feedback.

I'm am happy to merge additional implementations of a language but they need to add something worthwhile from a pedagogical aspect: different or more idiomatic source in some way, better performing data-structures, leveraging or not using language libraries to make a higher or lower-level implementation, etc.

COBOL would be great, but definitely challenging. If you are looking for an older language that is more challenging than Ruby but not quite in the COBOL realm then I would recommend Fortran. It also has the benefit of not having an existing implementation so you wouldn't have to come up with something unique to convince me to merge it, just something that works and adheres to the mal process structure. ;-)

I'm going to close this ticket, but if you feel a warning in the guide is important, feel free to propose a pull request modifying the guide. If I like the wording, I'll merge it. :-)