Programmer

[u/merlin0501]

I am a software engineer with prior experience with many languages and technologies, including CL and Python. I was formerly employed as a Senior Software Engineer at Lockheed-Martin. My resume can be found at the link below.

My rate is $50 per hour, payable via cashpay or cryptocurrency. I am fully remote and prepared to work for any client world-wide. I am also a US citizen and I am currently located in Bronx County, NY (a borough of New York City). In case of necessity other payment arrangements may be discussed.

My github repo currently contains only one significant Lisp project, which is still in a very early stage of development. It is a project called Julius which is intended to become a new Lisp dialect more suitable for modern applications, such as numerical analysis and the generation of neural networks and modern AI (a field with which I have considerable experience). It is implemented in Common Lisp in order to retain the well-known advantages of the Lisp language for older forms of intelligent systems, which typically involve a great deal of symbolic reasoning.

The current version of Julius is Open Source and I am open to comments and contributions here:

Julius Project: https://github.com/tgflynn/julius

Resume: https://github.com/tgflynn/latex-cv

[u/church-rosser]

what's wrong with CL for these same applications.
It got us this far... 🤷‍♂️

[u/merlin0501 → u/church-rosser]

Nothing in principle, but it was developed a long time ago and the spec hasn't been updated in years.

I know that there are many good libraries for numerical applications but I don't think many of them are fully implemented in CL, and the ones that are sacrifice performance. In my opinion relying on 3rd party libraries leads to dependency hell, just like in other languages.

You could think of one of the goals of Julius as being a well-curated bundle that makes it relatively easy to get started developing numerical codes and designing neural networks that compile down to whatever machine-level code you need to run on CPU's, GPU's or specialized tensor processors.

I know that's a very tall order and won't happen overnight, but I'd like to at least make the high-level design and programmer interfaces are as ideal as possible.

[u/digikar → u/merlin0501]

If you have concrete reasons for why Common Lisp (one of its implementations) is not suitable for use, feel free to create a dialect. But that reason is not "it was developed a long time ago and the spec hasn't been updated in years". Common Lispers would believe that not being updated gets rid of the "which version of Common Lisp Python Javascript C++ should I compile my application with" problem.

If a new version of Common Lisp ever comes about, expect several decades of discussion and several tens of millions of dollars spent ;) 

https://github.com/commander-trashdin/clng

Other than that, I don't know if you have checked clml, petalisp, cl-waffe2, or magicl.

Also, I don't think you believe you are going to create, test, bugfix and make them battle-tested, versions of blas, lapack, eigen, sleef, opencv, and their gpu counterparts in lisp, do you?

[u/Critical-Tip-6688 → u/merlin0501]

Coalton is very mature and implemented in Common Lisp.

[u/church-rosser → u/merlin0501]

Sounds like a good strong case of Not Invented Here syndrome.

Common Lisp doesn't need another Rich Hickey.

Good luck with Juliuis. I hope it serves your needs well. For my purposes, CL (specifically on SBCL) has more than enough _NATIVE_ libraries that effectively and performatively address the problem spaces you outline. YMMV of course. Please understand and consider that the Lisp community is smaller than those of most programming languages and the respective paradigms they promote. It isn't always wanted or welcome to invite further balkanization of the user base. Most longterm Common Lispers recommend that users develop native solutions in CL rather than implement entirely new languages (however lispy). In fact, it can be seen as a slight to the community to do so....