Carp 0.3

I've not used it, but https://github.com/carp-lang/Carp/blob/master/docs/Manual.md seems to have details on integrating with C codebases, including exporting your code as a dylib.

I’ve played with Carp a bit and have made minor contributions to the language. I’m not sure if there’s been any investigation into using it as an embedded scripting language yet, but there are definitely folks using it for embedded programming based on the community chats. I think someone has used it for programming modular synthesizers (or something like that)? At any rate, Carp definitely supports interfacing with C libs and you can choose to disinclude the standard library which is useful when you have limited space.

More generally, the language is a blast to use! IMO it grants one the fluidity and expression of lisp with the confidence one gets from a Haskellesque type system.

If you have any questions, the community on Gitter is very helpful.

It's a lot like programming haskell (which is not surprising given that carp is written in haskell, and utilises haskell's type system to achieve some things), in that you'll find something is going fine for a while, then suddenly you hit a wall where you're not sure why the type system is rejecting what you want to do and suddenly you feel out of your depth.

For example, trying to parse command line arguments ends up a bit weird because there's no 'return the command line arguments as a list/array' function, but you have to use Array.copy-map to run System.get-arg on each element of an array created by `(Array.range 0 (- @(System.get-args-len) 1))` and inferring the @s in there (a syntactic sugar for `(copy ...)` is a little confusing.

Thank you, I thought it was OpenBSD's CARP port to Linux until I read your comment.

Thanks for clarifying. The repo subject line "A statically typed lisp, without a GC, for real-time applications" had me thinking it was for hard real-time systems and not really being able to come up with areas where it would be needed. These days with fast cores and pauseless gc the same areas of the tl;dr can be done in a variety of languages now including lisp.

Once you are counting the amount of parentheses in a Python vs in a LISP program doing the same and realise the the Python version has more you give up on your parentheses phobia pretty quickly.

Do you really think people do not get used to brackets being in slightly different places and things being ordered slightly differently? (The ones starting with functional languages certainly do when they start using other languages later :D)

It seems like you're getting hung up on s-expression syntax being different than what you're familiar with. This would be akin to a native English speaker saying that Korean is completely incomprehensible. Meanwhile, a native Korean speaker would have quite a different perspective.

My team used to be a Java shop, and we switched to Clojure about a decade ago. Looking back and comparing similar types of projects that we've developed in both languages there's no contest. Clojure is much faster to develop, and far easier to maintain long term.

There are two fundamental problems with OOP. The first problem is that classes encourage creating ad hoc APIs. Every time you create a class with some methods, that's a unique API. Knowing how one class behaves tells you nothing about the next. As the number of classes grows, it becomes more difficult to understand what the system is doing because you have to keep all the unique behaviors in your head to reason about it.

The second problem is that objects are state machines. Each object has its own internal state that gets manipulated via its methods. The states of the objects are also interdependent in most cases. So, the more objects you have at runtime, the more states you have to keep in your head to know what any one piece of code is doing at any given time.

In practice, this makes it impossible to reason about code with any degree of confidence in large systems. Only thing you can do is fire up the debugger, put your application in the desired state, and then inspect it. Reasoning about code becomes a heuristic at that point. You can test it for some specific cases, and hope that it will work for all cases, but you can never really know that it will.

FP and immutability tackle both of these problems head on. Immutable data directly leads to the ability to do local reasoning about your code, and allows you to write pure functions that can be reasoned about independently. Meanwhile, data is not being abstracted inside opaque state machines that provide ad hoc DSLs as their API. Instead, it's explicitly passed through function pipelines to transform it. These aspects make the code much easier to understand and maintain because you can look at a specific part of the application and reason about its behavior in isolation.

I prefer s-expressions, for what its worth, to almost any syntax. I've also been programming in Lisp dialects for more than a decade, so I've had time to get used to them. But I still find them more readable than any other kind of language.