OP

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.

Pink Fox 23d

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

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.

>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.

OP

Show something you've made in Lisp.

Happy Cow 23d

>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,

>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.

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.

Happy Cow 23d

>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,

>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.

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.

Pink Fox 21d

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 t

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.

Lisp has native arrays.

Pink Fox 21d

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 t

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.

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.

Pink Fox 21d

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 t

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.

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

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

Green Giraffe 17d

>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 l

>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.

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

OP

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

Magenta Monkey 16d

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

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

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.

OP

introspectability is undesirable by TPTB

OP

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.

Coral Walrus 14d

You do not have a bajilions of uninteroperable programming languages with some having completely incompatible syntax and semantincs, you have one single p

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.

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

Coral Walrus 14d

introspectability is undesirable by TPTB

introspectability is undesirable by TPTB

>tptb
literally who

Grumpy Monkey 11d

>tptb literally who

>tptb
literally who

Me

Grumpy Monkey 12d

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 (s

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.

Yeah the tooling is shit but the language seems interesting.

Swift Giraffe 11d

Yeah the tooling is shit but the language seems interesting.

Yeah the tooling is shit but the language seems interesting.

Meme prog lang, teh definition of it.

Green Giraffe 17d

>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 l

>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.

Looks better to me without parentheses.

OP

>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.

Sleepy Bear 10d

>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

>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.

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.

Sleepy Eagle 10d

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

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.

Most lisps allow for all styles of programming.

nerd

Sleepy Eagle 10d

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

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.

>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.

Sleepy Eagle 10d

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

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.

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.

OP

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.

Magenta Monkey 16d

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

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

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

Grumpy Monkey 12d

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 (s

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.

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.

Lucky Elephant 9d

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 dialec

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.

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