3 ms·

Off the topic of dependent types, but this is way too hilarious to pass up.. > Imagine if pickType did a network request to a server and then returned whatever

by jesse__ 11mo ago

Off the topic of dependent types, but this is way too hilarious to pass up.. > Imagine if pickType did a network request to a server and then returned whatever type the server said. Sounds like a bad idea! Fucking .. isn't this what LSPs are?! Finally something functional programming people and I can agree on. That does sound like a bad idea.

ChadNauseam 11mo ago
I think it's a bit apples and oranges. I was suggesting that compilation itself should probably not involve nondeterministic network requests. If I understand LSP correctly, it only uses network requests to allow your editor to communicate with a binary that provides type information. But the compiler behavior is unchanged. Honestly LSPs seem pretty reasonable to me.
- jesse__ 11mo ago
  What's the fundamental difference between a syntax highlighter and the frontend of a compiler? I would argue not much, apart from the fact that people are willing to have their syntax highlighter randomly explode, but are much more concerned about their compiler randomly exploding.
  - hyghjiyhu 11mo ago
    The fundamental difference is that in his case any conforming compiler has to do the network request. Whereas with LSP it's just an implementation detail of the editor.
    - jesse__ 11mo ago
      My point is "why do we tolerate network requests in LSPs, but not compiler frontends"? If you think about it, the LSP is a way of doing libraries, which is dramatically worse than just inventing a binary interface and doing actual dynamic libraries. If you follow the LSP model to it's natural conclusion, everything becomes this horrible, disconnected morass of servers talking to each other on your local machine..
      - skybrian 11mo ago
        It's not network requests that are a problem. It's nondeterministic network requests. Build systems do make network requests, but assuming the network is up and the build servers are running, the result of a compile should always be the same. If the server isn't reachable then the build fails. Also, while build systems can do stuff over the network, the program isn't allowed to run arbitrary network code at compile time. At most it can import a library at a particular URL. The build system will need to download the library the first time, but it can also cache libraries so no download is needed.
        jesse__ 11mo ago
        > It's not network requests that are a problem. It's nondeterministic network requests. Ohhhhh, right, my bad. I forgot that you could just make network requests deterministic with the __do_it_determinstically flag. Of courseeee, how could I be so silly. .. Think about it; you just illustrated my point exactly. If the network request is assumed to always complete, with the desired payload,, and the client/server exist on the same machine, then why the fuck is there a network request?? An LSP server is just a library, but instead of being loaded into the process address space like a normal library, there's a separate server for some unknown reason. Anyways, /rant
        ChadNauseam 11mo ago
        Do the client and server necessarily exist on the same machine? I thought vscode had an architecture where the frontend and backend could be on separate machines, although I don't know if the LSP crosses that gap. Also, I'm sure there's a way to do it, but if someone wanted to write an LSP in Haskell and the editor was written in JavaScript, I'm not sure it would be as straightforward to load it as a dynamic library as you suggest it should be.
        jesse__ 11mo ago
        Theoretically, the client/server don't have to be on the same machine, but in practice they mostly are. As for the interface.. any language that can't speak the C ABI isn't a real language (read: they all can).. but this is besides the point. Counterpoint; when's the last time you used an editor written in JavaScript and an LSP written in Haskell? I bet never.
    - jibal 11mo ago
      The fundamental difference is that a compiler determines the semantics of the program being compiled, and having that be non-deterministic is disastrous ... whereas a syntax highlighter has no effect on the semantics of the program that is generated from the code being highlighted. Things blowing up is a complete red herring.
  - chongli 11mo ago
    A compiler is allowed to halt on a syntax error. Syntax highlighters ideally should not give up on colouring the rest of the document due to mismatched parentheses (or braces or any other delimiter pair).
    - jesse__ 11mo ago
      Fair point
    - jibal 11mo ago
      Many syntax highlighters in fact do so, but this simply isn't what the point was about network indeterminacy--compilation determines the semantics of the program being compiled, syntax highlighters do not.
  - jibal 11mo ago
    The fundamental difference is that a compiler's actions determine the semantics of the program; a syntax highlighter has no effect on it. And I don't think the concern here is about things blowing up. (Not that things blowing up isn't concerning, but it just doesn't have anything to do with this discussion.)
Quekid5 11mo ago
No, LSPs return the name/metadata of a concrete type. Dependent typing means that the return type of any given function in your (static) program can depend on a runtime value, e.g. user input... In well-defined ways ofc.
- jesse__ 11mo ago
  So, you're saying it's outside the scope of an LSP to return information about a dependent type because it's .. not a concrete type? That sounds wrong. I can make literally any language support dependent types that have struct, enum, switch, and assert. You make a boxed type (tagged union, algebraic datatype, variant, discriminated union, fucking, whatever), and just assert whenever you pack/unpack it on function entry/exit. I do this all the time. In plain English, my quip boils down to 'why do we tolerate network requests in our syntax highlighters, when we don't tolerate them in our compiler frontends?'
  - wredcoll 11mo ago
    Because in this world my vim editor gets to benefit from the money and time microsoft spent building a typescript syntax highlighter. If I waited for one that spoke the c abi so someone could load it via dll instead of http, well, I'd still be waiting.
IceDane 11mo ago
This is easily the stupidest thing I've read on HN in quite a while, and your continued arrogance in the rest of the thread doesn't help. Quite an achievement for a site so full of people who have a direct line from their ass to the comment section. Congratulations!

by jesse__ 11mo ago

ChadNauseam 11mo ago

I think it's a bit apples and oranges. I was suggesting that compilation itself should probably not involve nondeterministic network requests. If I understand LSP correctly, it only uses network requests to allow your editor to communicate with a binary that provides type information. But the compiler behavior is unchanged. Honestly LSPs seem pretty reasonable to me.

jesse__ 11mo ago
What's the fundamental difference between a syntax highlighter and the frontend of a compiler? I would argue not much, apart from the fact that people are willing to have their syntax highlighter randomly explode, but are much more concerned about their compiler randomly exploding.
- hyghjiyhu 11mo ago
  The fundamental difference is that in his case any conforming compiler has to do the network request. Whereas with LSP it's just an implementation detail of the editor.
  - jesse__ 11mo ago
    My point is "why do we tolerate network requests in LSPs, but not compiler frontends"? If you think about it, the LSP is a way of doing libraries, which is dramatically worse than just inventing a binary interface and doing actual dynamic libraries. If you follow the LSP model to it's natural conclusion, everything becomes this horrible, disconnected morass of servers talking to each other on your local machine..
    - skybrian 11mo ago
      It's not network requests that are a problem. It's nondeterministic network requests. Build systems do make network requests, but assuming the network is up and the build servers are running, the result of a compile should always be the same. If the server isn't reachable then the build fails. Also, while build systems can do stuff over the network, the program isn't allowed to run arbitrary network code at compile time. At most it can import a library at a particular URL. The build system will need to download the library the first time, but it can also cache libraries so no download is needed.
      - jesse__ 11mo ago
        > It's not network requests that are a problem. It's nondeterministic network requests. Ohhhhh, right, my bad. I forgot that you could just make network requests deterministic with the __do_it_determinstically flag. Of courseeee, how could I be so silly. .. Think about it; you just illustrated my point exactly. If the network request is assumed to always complete, with the desired payload,, and the client/server exist on the same machine, then why the fuck is there a network request?? An LSP server is just a library, but instead of being loaded into the process address space like a normal library, there's a separate server for some unknown reason. Anyways, /rant
        ChadNauseam 11mo ago
        Do the client and server necessarily exist on the same machine? I thought vscode had an architecture where the frontend and backend could be on separate machines, although I don't know if the LSP crosses that gap. Also, I'm sure there's a way to do it, but if someone wanted to write an LSP in Haskell and the editor was written in JavaScript, I'm not sure it would be as straightforward to load it as a dynamic library as you suggest it should be.
        jesse__ 11mo ago
        Theoretically, the client/server don't have to be on the same machine, but in practice they mostly are. As for the interface.. any language that can't speak the C ABI isn't a real language (read: they all can).. but this is besides the point. Counterpoint; when's the last time you used an editor written in JavaScript and an LSP written in Haskell? I bet never.
  - jibal 11mo ago
    The fundamental difference is that a compiler determines the semantics of the program being compiled, and having that be non-deterministic is disastrous ... whereas a syntax highlighter has no effect on the semantics of the program that is generated from the code being highlighted. Things blowing up is a complete red herring.
- chongli 11mo ago
  A compiler is allowed to halt on a syntax error. Syntax highlighters ideally should not give up on colouring the rest of the document due to mismatched parentheses (or braces or any other delimiter pair).
  - jesse__ 11mo ago
    Fair point
  - jibal 11mo ago
    Many syntax highlighters in fact do so, but this simply isn't what the point was about network indeterminacy--compilation determines the semantics of the program being compiled, syntax highlighters do not.
- jibal 11mo ago
  The fundamental difference is that a compiler's actions determine the semantics of the program; a syntax highlighter has no effect on it. And I don't think the concern here is about things blowing up. (Not that things blowing up isn't concerning, but it just doesn't have anything to do with this discussion.)

Quekid5 11mo ago

No, LSPs return the name/metadata of a concrete type. Dependent typing means that the return type of any given function in your (static) program can depend on a runtime value, e.g. user input... In well-defined ways ofc.

jesse__ 11mo ago
So, you're saying it's outside the scope of an LSP to return information about a dependent type because it's .. not a concrete type? That sounds wrong. I can make literally any language support dependent types that have struct, enum, switch, and assert. You make a boxed type (tagged union, algebraic datatype, variant, discriminated union, fucking, whatever), and just assert whenever you pack/unpack it on function entry/exit. I do this all the time. In plain English, my quip boils down to 'why do we tolerate network requests in our syntax highlighters, when we don't tolerate them in our compiler frontends?'
- wredcoll 11mo ago
  Because in this world my vim editor gets to benefit from the money and time microsoft spent building a typescript syntax highlighter. If I waited for one that spoke the c abi so someone could load it via dll instead of http, well, I'd still be waiting.

IceDane 11mo ago

This is easily the stupidest thing I've read on HN in quite a while, and your continued arrogance in the rest of the thread doesn't help. Quite an achievement for a site so full of people who have a direct line from their ass to the comment section. Congratulations!