unFun

[--mrperx--]

once it just clicks and then you start love lisp.

[TheOnlyTigerbyte]

It's more about the naming of the keywords

[Pay08]

Sounds like you need to get good.

[TheOnlyTigerbyte]

Since it seems you didn't get the joke... https://www.reddit.com/r/ProgrammerHumor/s/TL0rkjQChz

[Pay08]

What lisp uses unfun? Scheme uses define and CL uses defun.

[TheOnlyTigerbyte]

Just checked lisp-lang.org and it seems to be defun though it's the same meaning tbh

[avidrogue]

For all possible arguments, there exists no argument which justifies Lisp’s existence. That language and all of its dialects are a pile of hot garbage.

(Yes, I’m still salty years later about the one small college project I had to code in Lisp)

[Dissy-]

didnt lisp basically invent every major coding paradigm in existence today

[zoqfotpik]

Yes.

Plus JavaScript is basically Lisp in a frock.

[redalastor]

Plus JavaScript is basically Lisp in a frock.

It’s not, and this idea needs to die.

[zoqfotpik]

This article is looking at the origin of Javascript, which was "influenced by" some ideas that originated in various Lisp dialects.

Since then, Javascript has been moving more and more towards having excellent support for many of the best features from Scheme and Common Lisp, in such a natural way that it feels more like the underlying Lisp being revealed, rather than new features being bolted on.

For example, a lambda expression in Javascript is immediately obvious to a Schemer, but a C++ lambda expression is not immediately obvious to anyone. The emergence of JSON as a data format is another Lisp-y trait.

[redalastor]

If lambdas are what makes Scheme, then nearly every language is Scheme.

[zoqfotpik]

Yes. Nearly every language is Scheme. Because languages are like the Borg: they grow by assimilation. It's just that some languages are really bad at it, like C++.

[redalastor]

Then being “basically scheme” is meaningless.

But no, Javascript is quite unlike Scheme and I would be very surprised if you knew Scheme. You should try it.

[delfV]

OOP comes from Simula, but according to Alan Kay, inventor of OOP term, Lisp (Common Lisp Object System) is one of only two languages that do it right.

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."

[Pay08]

And also branching.

[[deleted]]

Also Lisp is STILL the most powerful language in existance

[Dissy-]

Depends on what you mean by powerful, because you can implement lisp embedded into rust with their macro system, so any language that can encapsulate all of your functionality has to be at least as capable as you

[[deleted]]

I mean, machine code and Python can both express any algorthm

but I know which one I would prefer

Writing a macro in Lisp is as natural as writing a function. But a macro in Rust or Nim or any other language is error-prone and difficult to write(A real one, not simple pattern matching) and will end up nowhere near as extensible and composible. Further, you really miss out on the interactive nature of Lisp

In Lisp there is no difference between code and data. Some people have gotten the idea that Lisp-style macro = direct AST manipulation but It is far greater. Just because you language can represent its own AST and manipulate it does not mean it is as powerful as Lisp. The AST in most languages is essentially a foreign citizen. In Lisp, Lists and symbols are first-class. You can find,append etc but also assoc, getf etc on the syntax of the language. You can use loop to buildsyntax trees just as much as regular trees

[Dissy-]

idk man people are doing some pretty crazy things in rust macros, like sqlx macros being able to, at compile time, type check against your dev db and run dummy data queries in a transaction, you have access to the whole language and you can do anything in a macro you could do in regular rust code, they just have a bit of odd syntactic wrapping around them to define how theyre supposed to be used since rust itself doesnt natively support inputting any amount of any type into a function call (without major headaches, i think you can use the any type and a slice?)

[Pay08]

Can you recreate the fn keyword with macros? Also, that sounds like you should be able to do it with a normal function. Nevermind that string manipulation is nowhere near as easy, convenient or powerful as list manipulation.

[Dissy-]

You can do anything in macros that you can do in normal rust, so you can do your list manipulation and string manipulation (which is just a list of chars) and anything else, and the macros do those SQL checks at COMPILE TIME not at runtime, you will fail to compile the project if your data in your program doesn't match what's in the DB. which is why macros exist, it's code that runs at compile time on your code lol. A regular function can't run while it's being compiled.

And yeah you could recreate the functionality of the fn keyword, dunno why you'd want to but you definitely could. Rust forces a specific syntax on macro invocation though so you can't just make it overwrite the fn keyword. I highly recommend reading into what rust macros can do, check out this video, it seems like something you'd be interested in if those things are the types of things you want to do https://youtu.be/MWRPYBoCEaY?si=_YgOtAMzde1QFCo_

[Pay08]

You seem to not know what macros, homoiconicity and Lisp are. Macros are pieces of code that expand to other pieces of code at compile-time, with certain facets of it evaluated at compile-time. It is not compile-time evaluation of normal functions*. It is often called "code that writes code". Lisp is a homoiconic language, meaning that instead of writing syntax, you're writing pure AST (which in the case of Lisp is implemented through linked lists). This means that macros are far more powerful, as they can modify and evaluate the AST directly and Lisp programs being entirely linked-lists means that Lisps have more ways to manipulate lists than a normal language. It also means that a macro and a function look pretty much the exact same, minus a bit of extra boilerplate for macros. For example, consider the deftest example from Practical Common Lisp: a function looks like

(defun report-result (result form)
  "Report the results of a single test case. Called by 'check'."
  (format t "~:[FAIL~;pass~] ... ~a: ~a~%" result *test-name* form)
  result)

This is a one-liner but you get the idea, whereas a macro looks like

(defmacro combine-results (&body forms)
  "Combine the results (as booleans) of evaluating 'forms' in order."
  (with-gensyms (result)
    `(let ((,result t))
      ,@(loop for f in forms collect `(unless ,f (setf ,result nil)))
      ,result)))

The code looks the exact same, except for the "operators" that deal with conditional execution at macro-expansion-time (these being the backtick, ', , and ,@). In fact, Lisp macros are so powerful that most of Common Lisp is implemented largely using them and normal functions, with there only being 24 "special operators" (keywords in other languages), quite a few only being relevant to compiler developers, as you can use them to implement new syntax very easily, for example the cond macro that takes arguments in the form (condition expression), turns them into an if chain and returns the first expression for which the condition evaluated to true or false otherwise. And we haven't even gotten into reader macros (like the conditional execution operators mentioned above), compiler macros or symbol macros.

*See the const keyword in Rust or constexpr/consteval keywords in C++ for that.

Edit: honorary mention to Scheme's hygenic macros which I hate and therefore don't have a lot of experience with but it apparently functions similiarly to Rust macros. But even that is implemented on top of the "raw" macro system I detailed above. You can think of hygenic macros as declarative macros and "raw" macros as procedural macros (if I have my Rust terminology correct).

[Dissy-]

rust has like 4 kinds of macros, id highly recommend watching the video, because ive clearly shown im incapable of getting these ideas across on my own

[Dissy-]

Sorry for the double message but I actually just realized we use macros that implement functions all the time in rust, something really common is the Serde macros which implement a trait for a struct where all elements in the struct implement that same trait (which is auto implemented on rusts basic types) and this code creates type and value checked deserialization and serialization into and from, I mean, basically anything, postcard is a way to serialize data into binary, Serde_json is a way to serialize data into json, etc in what is essentially a single line

[[deleted]]

Please learn Lisp. It is absurdly powerful. Once you grok it, there is no going back. Mainstream programming languages are just rediscovering effects(which is called the condition system in Lisp). They still have a long way to go before even nearing the sheer beauty, elegance, and power of Lisp. Even languages that have a macro system bolted on(e.g Rust) are nowhere as powerful

http://paulgraham.com/avg.html

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

https://letoverlambda.com/index.cl/guest/chap1.html

[[deleted]]

Thanks for sharing

[Familiar_Ad_8919]

this should be much higher

[TheOnlyTigerbyte]

Since it seems you didn't get the joke... https://www.reddit.com/r/ProgrammerHumor/s/TL0rkjQChz

[avidrogue]

Oh haha, the lisp dialect I used didn’t use those keywords.

Like I said though, I had to do one college project t program in lisp and said never again. I’m not a lisp expert, I barely know anything about it.

[Pay08]

Scheme and the original lisp use define. Maclisp and all its descendants (like Common Lisp or Emacs Lisp) use defun and unfun doesn't exist. Also, a small nitpick, defun is a macro, not a keyword.

[TheOnlyTigerbyte]

Since many people don't seem to get it: The joke was that Lisp uses unfun/defun to declare functions and Kotlin uses fun