>>108916795
Declarative programming is just a dirty hack. It relies on real programming, it can only exist after the problem was figured out. Basically it's a config for a finished software written imperative-style.

>>108916822
>blub language programmer
You can use Lisp to write and generate programs at any level, from the lowest one, closest to the hardware, to the highest one, to a declarative one, closest to the human.
You can create your own C-like language in Lisp, compile it to the machine assembly language and use it to write any low level thingy you want.

>>108916795
Show something you've made in Lisp.

>>108916854
The issue is data structures, that's why Lisp machines failed.
Linked lists just don't work at the lowest level.
Arrays (FORTRAN) or stacks (Forth) are the better approach.
C/C++ is arrays, stacks, heaps, lists, jack of all trades.
Yes you can implement these data structures from lists abstractly, but for performance/raw metal you cannot car or cdr.

>>108916854
When it comes to chickens and eggs, we know that imperative was first. Everything is based on imperative commands. Move that date from here to there. Perform this operation. Store result over there.
That's is what goes under the hood. Why you are describing are very high level configs for the software that runs like I just described.
Problem with your high level configs you call declarative programming languages is that they are drifting too far away from the real world and turn software into a slow meaningless slop.

>>108916881
Lisp has native arrays.

>>108916881
Linked lists are just a thin abstraction over the linear memory model we have in the abstracted von neuman CPU. you're talking like Lisp has 20 layers of abstraction above the stack and heap just to output a simple execution.

>>108916881
To represent Lisp lists, you use linked lists.
To represent other data structures, you can use arrays.

>>108916886
>binary code is what a physical machine uses to execute programs
>assembly language is used to describe in text form the binary code
>use an operational language to represent C-like code
You can do all that in Lisp. Blub programmers, I swear.
You can create an assembly DSL in Lisp. Let's use x86 as an example

(x86-executable
    (label abc)
    (mov eax ebx)
    (jump abc))

You can create a C-like DSL in Lisp.

(c-function
    (parameters
        (a in uint32_t)
        (b in uint32_t)
        (c out uint32_t)
        (d out uint32_t))
    (code
        (+ a b c)
        (* a b d)))

Notice how you can make it even better than C itself, you can have two return values, HLSL/GLSL style.
Then you can create a Lisp program which takes the C DSL, type checks it, compiles it and emits the assembly DSL, then use another Lisp program which takes the assembly DSL and produces the final executable which runs in bare metal.

I have an irrational hate with people who have lisps. It's like I want to crush their skulls open

>>108916977
What's the advantage over just using x86 ASM or C?

>>108916795
>JSON? Swap it out for a Lisp file.
Executable config/data files have proven themselves a fantastic attack vector over and over

>>108917004
You do not have a bajilions of uninteroperable programming languages with some having completely incompatible syntax and semantincs, you have one single programming language with DSL for each use case and you can combine and chain them easily within the same system.
As a result, you can build more advances DSLs on top of each other which all eventually get compiled to the same base C-like DSL.
For example, you can make a serialization DSL which describes the schema of some serialized data structure (think proto-buffers, but for disk, network, remote call, databases) and from that description you generate all the C-like DSL functions (serialize, deserialize, verify unsafe and potentially malicious, generate random data, compute some hash of the data) you want to have and call them directly in your code. You do not have to implement them at all, just specify the schema and a Lisp function generates everything you need.

>>108916795
introspectability is undesirable by TPTB

>>108916795
The tooling around most lisps is pretty much dogshit in all situations. Shit lispfags brag about is just an inferior version to an lsp + auto formatter (something that a lot of lisps don't have). CL's defacto package manager is a joke and they didn't bother to use https so every single person that has ever used it has potentially been mitm'd. The repl integration is the one saving grace that makes a lisp worth using although you have to use emacs and emacs is a slow laggy pile of shit with 50 years of legacy cruft and it is mostly made in a language that is completely single threaded so there is no hope of it ever getting better.

>>108917063
But how does this work *in practice*? Talk is cheap.

>>108917083
>tptb
literally who

>>108917159
Me

>>108917144
Yeah the tooling is shit but the language seems interesting.

>>108917209
Meme prog lang, teh definition of it.

>>108916977
Looks better to me without parentheses.

>>108916795
>Why don't we just write everything in Lisp
Because lisp is an obsfucated, slow, memory hog of a language. Oh, and it is interpreted, which makes it even slower.
Lisp is more of a cult than a language, actually, a circle-jerk in which you all tell each other you're smart to use it, but you struggle to get anything done beyond a fizzbuzz and you are only fooling yourself.
I used Lisp in the 80s. I stopped. I got better.

>>108917330
Compiled/interpreted is irrelevant since all languages now a days come with a compiler and or an interpreter. it's just different ways of translating the code.
some C debuggers allow you to use C in an interpreted manner for example.
the question is pure vs impure languages. not compiled vs interpreted.

>>108917383
Most lisps allow for all styles of programming.

>>108917383
>it is interpreted
You don’t know what you’re talking about
>I used Lisp in the 80s. I stopped. I got better.
So did the rest of your former team I bet.

>>108917383
Busted. You are not a programmer. You've just revealed that you don't know the difference between interpreted and compiled. Hint: one runs at least ten times faster than the other. Can you guess which? Flip a coin if you're having trouble. The coin more likely to answer correctly than you are.

>>108918426
>t. retard

>>108916795
LISP fans will probably refuse to acknowledge this but the only successful LISP variant with actual usage in the industry is Clojure. It's the only dialect with good tools + good performance (JVM) + good library support. The others only exist inside academia.

>>108917006
They have also proven themselves the only valid way to do config over and over. They are currently the standard. Greenspun's 10th rule.

>>108917144
You can also use vim. I always use vim when developing lisp. You are 100% spot on about quicklisp (and the companion systems that the zoomers came up with like qulot and whatever other abomination I don't want to remember are pants on head retarded). You are also mostly right that most lisp tooling except the repl is pretty poor. However, lisp repl also gives the single best debugging experience by a mile. The ccl repl also has the best debugger for C program segfaults (dynamically link a library with symbols and let it segfault in a call, it will halt on the segfault and let you walk and examine up and down the call site and discover exactly why the dynamic library crashed and debug it in a way that I have not been able to replicate even with gdb).
Also I don't know of any lisp without autoformating, because autoformating in a lisp is the most trivial shit in the world thanks to parens. The repl also provides autocomplete, docs and jump abilities better or on par to any lsp, but also allow multithread debugging in a way that is impossible in all other platforms, and can locally tell you the assembly a statement compiles to, etc., which is impossible anywhere else.

>>108919030
Clojure has garbage tools and performance compared to most common lisp implementations, however it does have access to a better library ecosystem.

File: Macron-Benalla.jpg (62 KB, 932x582)

62 KB JPG

>>108917144
>emacs is a slow laggy pile of shit with 50 years of legacy cruft and it is mostly made in a language that is completely single threaded so there is no hope of it ever getting better.
Everything changed for the better, since you looked into Emacs 20 years ago.
Even haters admit it: https://www.youtube.com/watch?v=DMbrNhx2zWQ

>>108916795
Realising code is data and data is code takes years of experience vv it takes too long like expecting every one to be enlightened

You know but see the average response in this thread vv they don’t have the eyes to see

File: IMG_2668.jpg (1.09 MB, 1170x1637)

1.09 MB JPG

>>108917063
You’ve achieved programming gnosis and enlightenment

>>108919030
The most used lisp in industry today is likely either autolisp or allegro, but obviously it had its highest market adoption during the previous ai boom

File: 3C3C2740-1968-42B5-9A60-7(...).jpg (506 KB, 673x982)

506 KB JPG

>>108916881
> why Lisp machines failed
When you look at the history of spike, it’s clear that the fastest workstations of the time couldn’t beat the TI explorers of the time. This is around the end of Sun 3 era transitioning into sparc machines.
It didn’t fail due to technical reasons, it was among the fastest processors of the time. Maybe *the* fastest. It failed because most people don’t understand lisp, and something they *do* understand… like Logo… isn’t very useful.

>>108917279
> parentheses is hard to read
I imagine Chinese characters are hard for you to read as well.
If it’s any consolation, the problem is you.

>>108921946
> Realising code is data and data is code takes years of experience
I’m sure many a jr. C developer has tried to execute data accidentally. Perhaps even on their first day.

>>108916795
it turns out that if you let everyone use lisp no one uses the same lisp

>>108922100
You don’t get what they mean by it

Your comment even makes a distinction between c code and data