News for hackers. Stuff that matters.
Re:LSP could have been better by Hendrikto on Thursday October 12, 2023 @05:05AM (#37854947)
> If I am most comfortable/fluent viewing python, why can't I view a javascript source as python?

Because they are not isomorphic. At all. Even if you just consider the languages themselves, and ignore their ecosystems, which, in practice, you cannot.

Re:LSP could have been better by spunker540 on Thursday October 12, 2023 @08:22AM (#37856201)
Some percent of python code I’ve written code be rewritten as JavaScript code at the function-level.
Re:LSP could have been better by Conscat on Thursday October 12, 2023 @02:27PM (#37860997)
Meta's "Transcoders" or whatever they changed the name to demonstrate that. However, if we want perfectly semantically equivalent functions, as soon as you add two numbers, then Python -> JS is impossible. The best we can do is approximately translate the behavior.
Re:LSP could have been better by fiddlerwoaroof on Thursday October 12, 2023 @06:34PM (#37864011)
I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “homoiconicity”: eval consumes and produces the same types of data)
Re:LSP could have been better by Calavar on Friday October 13, 2023 @03:09AM (#37867674)
Sure, you could do that. But how does it help you understand the code better than reading it in the original source form? Programming languages are more than syntax. If you don't understand the semantics, you don't understand the code.
Re:LSP could have been better by fiddlerwoaroof on Friday October 13, 2023 @04:14AM (#37868122)
Different syntaxes are better for different purposes: s-expressions are easy to manipulate structurally; significant indentation is often easier to read; etc. Semantics is important, but syntactic noise is too.
Re:LSP could have been better by Calavar on Saturday October 14, 2023 @02:03PM (#37882705)
You mean different purposes by humans or different purposes by machines?

For machine manipulation, I think it makes more sense to directly manipulate the AST.

For human manipulation, I think the cognitive overhead of mentally converting between the display syntax and the canonical syntax would far outweighs any gains in readability. But maybe your workflow is different than mine - If you have a lot of custom macros in your editor, I could see s-exps being useful (although, again, I think exposing and directly manipulating the AST would be less error prone)

Re:LSP could have been better by fiddlerwoaroof on Saturday October 14, 2023 @05:16PM (#37884343)
A programming language doesn’t need a canonical syntax if its semantics are specified in terms of the data-structures the parser produces and not in terms of the textual representation of those data structures.
Re:LSP could have been better by Hendrikto on Friday October 13, 2023 @05:19AM (#37868540)
> Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure.

If you designed the languages and interpreters/compilers around it. Neither Python nor Javascript are, though.

Re:LSP could have been better by fiddlerwoaroof on Friday October 13, 2023 @03:22PM (#37874467)
My point isn’t that existing languages are designed this way, but it wouldn’t be hard to retrofit this onto an existing language. Especially one like JavaScript that already has relatively widely-used transpilers