Programming thread

[Indefinite_Ordered_Sets]

Also I literally have no idea how someone could think treating code as data is a bad idea, generally it's the thing most people look at Lisps and go "oh yeah that's actually really useful".

Yeah, it is very powerful concept, but like for backend implementations, such as compilation & optimization, but not for human operations.

Lisp itself was invented as an autocode for symbol processor machine, and is perfectly fitted exactly for that. Retards was blown away of new concept that computers can be more than simple number crunchers and run away with Lisp as a high level general purpose programming language, which it never was.

 

[Considered HARMful]

Sure there is a bit of a learning curve to reading it but once you've done it for like a day or two it's like reading anything else.

I wanted to write how that part is the goto-copout of every hackernews exceptional person, but @Indefinite_Ordered_Sets did it a lot better.

 

[Anstiv]

I wanted to write how that part is the goto-copout of every hackernews exceptional person, but @Indefinite_Ordered_Sets did it a lot better.

It's not a cop-out. Notation is notation. Learning to read music takes time. Learning to read any form of notation that conveys information is a valuable and concise way takes time to learn to read fluently. Expressing logic in plain English includes superfluous information that makes things take significantly longer to read.

"We should explain how to play an entire piece of music in English, that makes so much more sense. Tablature is the copout every exceptional newfangled musician goes for. We should be explaining this all in English so that everyone can understand it. There couldn't possibly be a benefit to using a different form of notation."

I understand there's a manner of taking notation too far, you don't need a DSL for every single thing. But s-exps are absolutely not too far.

 

[byuu]

It's not a cop-out. Notation is notation. Learning to read music takes time. Learning to read any form of notation that conveys information is a valuable and concise way takes time to learn to read fluently. Expressing logic in plain English includes superfluous information that makes things take significantly longer to read.

Music notation isn't a mess of parenthesis that needs fancy editor features to be readable.

 

[Considered HARMful]

It's not a cop-out. Notation is notation. Learning to read music takes time. Learning to read any form of notation that conveys information is a valuable and concise way takes time to learn to read fluently. Expressing logic in plain English includes superfluous information that makes things take significantly longer to read.

Knowing musical notation does not make one a composer.

 

[Kosher Dill]

But s-exps are absolutely not too far.

Is there something you do consider too far?

 

[Anstiv]

Is there something you do consider too far?

I think the main flaw of DSL's is when they almost all inevitably succumb to the inner-platform effect. The example wikipedia gies for this is X-Path. Off the top of my head the most recent DSL's I've found to be annoying are things like jq and JMESPath, though some people might disagree.

 

[Kosher Dill]

I think the main flaw of DSL's is when they almost all inevitably succumb to the inner-platform effect.

Oh, I meant in terms of notation rather than design. Is there anything in actual use (that is, not intentionally-hostile joke languages like INTERCAL) that you would consider "impractical"?

 

[Shoggoth]

No. It fails because of its absurdly unreadable syntax (which all of its successors continue to double down on), and fancy yet hardly useful in real world programming idea of S-expressions (i.e. code is data). Yeah, it is very powerful concept, but like for backend implementations, such as compilation & optimization, but not for human operations. How often do you need to write self-modifying code in real programs, or programs to generate programs? There are saner ways to do generic programming than full-blown macro-generation, which with already fucky syntax of Lisp gives even bigger fuck you to program's maintainer. Same goes for DSL, why do you need to invent new ways for expressing things that you already can express in base language? What, you are expert in your field, but not good at programming, so DSL is a very handy way to express yourself to computer? Well, no, if you not good at programming, than no amount of DSL will help your programming, you always will end up with shitty code, just in DSL. That route was already explored by COBOL. So, gid gud and learn to design and develop in proper programming language.

Lisp itself was invented as an autocode for symbol processor machine, and is perfectly fitted exactly for that. Retards was blown away of new concept that computers can be more than simple number crunchers and run away with Lisp as a high level general purpose programming language, which it never was. For fuck sake, all Lisp's descendants to this day don't have a proper mathematical expression syntax, the first thing that started the high level programming.

"Having irregular syntax is good, actually."
I didn't say CL isn't fugly. That's one of the reasons it will fail. Clean up the syntax? Case sensitive names? THATS-FOR-CHUMPS BIG-BOY LISPERS (USE BIG-BOY-LETTERS)
Homoiconicity is great, code as data is great. It's interesting the neo-lisps have decided that while macros are nice, if you rely to heavily on them you're off in DSL land and only you can read your code, which is retarded and takes you back to uncommon lisp.

Nigger if you can't figure out how to write and read s-exps I feel bad for your teeny-tiny brain.

Install a bracket-pair colourizer, The extension in VS Code even underlines the current form in a very helpful way like this:
View attachment 2624803

View attachment 2624838
(there's almost definitely a better way of doing this)

Make use of the thread first/last macros. Use a paredit. If you do all those fairly simple things your code will be very easy to read and it'll be easy to write.

If your functions are massively nested behemoths that go past 79 columns then you're writing your code like a nigger. Refactor that shit into smaller and more abstract functions.

Sure there is a bit of a learning curve to reading it but once you've done it for like a day or two it's like reading anything else.

Also I literally have no idea how someone could think treating code as data is a bad idea, generally it's the thing most people look at Lisps and go "oh yeah that's actually really useful". Even if you leave macros aside, being able to write EDN over a wire is very useful.

Cheshire (not jsonista)
Blocking on a paginated API
Nigga I'm gonna beat you senseless rewrite that to be non-blocking.

Is there something you do consider too far?

Hoon

Music notation isn't a mess of parenthesis that needs fancy editor features to be readable.

I really don't see the problem with S expressions. They're regular, consistent, and at least in Clojure/Hy/Fennel/Janet, very unambiguous.
You don't need a fancy editor to write in lisp, only something which enforces parens balance and indentation. Syntax highlighting and linting can be nice, but are not required, and like all visual cues, should be unobtrusive.
If anything, the problem is that we're editing text and not something better.
Smalltalk didn't even have files

 

[byuu]

If anything, the problem is that we're editing text and not something better.

Oh yes, it's the fault of the simple plain text format not the shitty syntax you force people to write in.

 

[Strange Looking Dog]

I have come to like parenthesis, the only part I dislike is how they stack up at the end of functions for which I usually just give each one it's own line, at which point it's not really any different from curly brackets in a c-like.

So long as you indent nicely, what's the difference? The lack of infix? Who gives a shit?

Is there something you do consider too far?

What's wrong with s-expressions? Beyond just macros to simplify code, they also allow you to add entirely new capabilities to a language. You can quibble if you want and argue that it's just adding new syntax for existing features, but at that point you may as well argue that it's time for a return to assembly as all other languages are really just derivative syntactic sugar.

Smalltalk didn't even have files

The compiler didn't operate on files? Elaborate

 

[byuu]

So long as you indent nicely, what's the difference? The lack of infix? Who gives a shit?

Look at that fucking mess. I can barely see where parameters end and the body begins, or when the consequent ends and the alternative begins, when function calls are made or when control structures are used .
It all blends together into a pile of shit even with all the fancy highlighting.

 

[Knight of the Rope]

I usually just give each one it's own line

Holy shit you have to go back.

 

[Strange Looking Dog]

Holy shit you have to go back.

I've already hopped the border wall gringo! The dysfunctional era is over, now begins the reign of the imperative rape mutant
WHERE THE WHITE WOMEN AT wait where are the women at? oh god it's all troons let me out I want to go back

Look at that fucking mess. I can barely see where parameters end and the body begins, or when the consequent ends and the alternative begins, when function calls are made or when control structures are used .
It all blends together into a pile of shit even with all the fancy highlighting.

The fact that his example function has two different bodies is what really throws me off personally. Personally I'd prefer some kind of specific syntax for that, like some kind of obvious symbol that separates the different definitions.

I'm still working on my own weird imperative lispy thing albeit slowly, and one big change I've settled on is eager evaluation of expressions. To that end, function arguments which should be evaluated lazily are surrounded with curly brackets instead of parens. I think this makes this particular case a little clearer, as you can see where the function body is, and can tell which parts might be evaluated lazily (e.g. in conditionals like struct-match or if)

(def $fac (fn $v {
 struct-match v
  [:case $c { # input is a single value
   fac c 1 # defer to 2-tuple version
  }]
  [:case [$c $acc] { # input is a 2-tuple, loop till c <= 1
   if (gt c 1)
    {fac (sub c 1) (mul c acc)}
    {acc}
  }]
}))

(fac 5) # returns 120

# parens evaluate the contained expression
# curlies return the contained expression as an expression object
# squares create a tuple (or initialize an object, [:name ...] syntax)
# a dollar sign creates a symbol (basically a variable name)

Why does ruby syntax highlighting of all things fit so well? How embarrassing

 

[Indefinite_Ordered_Sets]

Blocking on a paginated API

MFW, JavaScriptKiddies using mathematical notation for AI research and symbolic computation as a means of gay-ass web-programming. Where in those micro-services and YOBA-frameworks do you ever use homoeroticismiconicity of Lisp and code as data? And if you do, why you cannot do it without (you are not writing evolving algorithms for AI nor a making thesis for your PhD in computational linguistics)? Can you write code to rewrite infix notation in backwards, so you at least be writing a+b*c like a normal human being.

 

[Shoggoth]

Oh yes, it's the fault of the simple plain text format not the shitty syntax you force people to write in.

If you don't understand why using text and not something better to represent software is a bad idea, you're beyond help. Maybe all you program is PDP11 and micro controllers, so a bad language like C is sufficient for you.

I have come to like parenthesis, the only part I dislike is how they stack up at the end of functions for which I usually just give each one it's own line, at which point it's not really any different from curly brackets in a c-like.

When you learn to disregard the parens, the trailing closing paren lines are just visual noise, good enough indentation conveys scope unambigiously in most cases.
Just like text is irrelevant for representation, since there is no ambiguity regarding scope when parsing lisps, you can safely use an auto-formatter.

The compiler didn't operate on files? Elaborate

Smalltalk didn't have a compiler, it was an image based VM. Everything was a class, all classes were part of the image. The image was a sort of database. You just interactively added or modified classes as part of the image, saved it, then distribute. Even Smalltalk 80 was years ahead of modern IDEs

evaluated lazily

Laziness is hard to get right. Have you read the paper Cons Should Not Evaluate Its Arguments? Also, compare Racket's streams with Clojure's lazy sequences and Haskell's laziness, might give you some ideas

MFW, JavaScriptKiddies using mathematical notation for AI research and symbolic computation as a means of gay-ass web-programming. Where in those micro-services and YOBA-frameworks do you ever use homoeroticismiconicity of Lisp and code as data? And if you do, why you cannot do it without (you are not writing evolving algorithms for AI nor a making thesis for your PhD in computational linguistics)? Can you write code to rewrite infix notation in backwards, so you at least be writing a+b*c like a normal human being.

It isn't specifically the homoiconicity, but the understanding that you can go far by representing stuff as data. For example, look at the Reitit routing library in Clojure. It's a mini compiler from routes specified as data to optimal class hierarchy. You could do it all with classes and DSLs, but it's ass, with data it's clean, understandable, and very testable.

 

[Considered HARMful]

If you don't understand why using text and not something better to represent software is a bad idea, you're beyond help.

Like what?

 

[Shoggoth]

Like what?

Either something that lets you interact directly with the AST, like a lisp, or something which lets you interact directly with the runtime, like smalltalk. Text is relevant only for the "leaf" nodes representation. Text is to represent scalar types. Anything else needs something better.
Why even save it to files, in the end? you can save it in a database, again, like smalltalk did.

 

[Anstiv]

Music notation isn't a mess of parenthesis that needs fancy editor features to be readable.

Ok but literally you need a significantly more complex editor and training to notate music than you do to write Lisp code. Notating and reading music fluently both have high barriers to entry (notation exceptionally so).

You can setup a free text editor to write Lisp in a half hour and learn to read it fluently in a day or two. Learning to read music fluently takes months to sight read a single staff, and reading every single stave of a full symphonic score at the same time takes a while to do with real fluency. Learning to engrave music properly means at bare minimum reading Elaine Gould's "Behind The Bars" and purchasing expensive notation software like Dorico or Sibelius, unless you want to write everything by hand.

Yes, western music notation doesn't require a fancy editor to read it (and you really don't with Lisp either to read it, it's just that some extenions help), but it already has (most of) the necessary information packed in to it's elaborate, 400+ year old, tested and evolved notation system. And still even then musicians still cover their sheet music in handwritten notes because this elaborate system is still incomplete.

 

[Considered HARMful]

Either something that lets you interact directly with the AST, like a lisp, or something which lets you interact directly with the runtime, like smalltalk.

Yeah, no. I should not ask questions I know the answer to. And I've had my experience with Smalltalk - it's shit, as many novel, revolutionary, academic ideas are.

Besides, writing code as a text is basically creating AST, no? Potatoe, potatoh.

Text is relevant only for the "leaf" nodes representation. Text is to represent scalar types. Anything else needs something better.

Like what? C'mon man, don't make me do the work for you again. Propose something tangible, make a mockup in Paint, whatever.

Why even save it to files, in the end? you can save it in a database, again, like smalltalk did.

Filesystem is a database.

Ok but literally you need a significantly more complex editor and training to notate music than you do to write Lisp code.

Iunno, LaTeX is OK for me. I haven't even seen any fancy editor for writing musical notation and can do it nonetheless.

Notating and reading music fluently both have high barriers to entry (notation exceptionally so).

So is programming. How many lines of code does an experienced programmer make in a day's work in an established project? I mean: if a programmer can write code (basically: text) fluently, why does he write so little of it during a day's work?

You can setup a free text editor to write Lisp in a half hour and learn to read it fluently in a day or two.

Dude, no. Stop it. Get some help.

Or actually try to teach somebody what you're preaching and see how hard it is.