Live data from Hacker News

Choosing a language based on its syntax?

gingerbill.org

51–60 of 111 posts

Re: Choosing a language based on its syntax?

#51
post #46

Earlier quoted context omitted.

I hope that someday LLMs will interact with code mostly via language servers, rather than reading the code itself (which both frequently confuses the LLM, as you've noted, but is also simply a waste of tokens).

LSP is meant for IDEs and very deterministic calls. Its APIs are like this: give me a definition of . This makes sense for IDEs because all of those can be deterministically captures based of your cursor position. LLMs are notoriously bad at counting.

I think one could easily build an MCP tool wrapping LSP which smooths over those difficulties. What the LLM needs is just a structured way to say "perform this code change" and a structured way to ask things like "what's the definition of this function?" or "what functions are defined in this module?"

Not much different from what agents already do today inside of their harnesses, just without the part where they have to read entire files to find the definition of one thing.

Re: Choosing a language based on its syntax?

#52
post #18

Syntax is what keeps me away from Rust. I have tried many times to get into it over the years but I just don't want to look at the syntax. Even after learning all about it, I just can't get over it. I'm glad other people do fine with it but it's just not for me. For this reason (coming from C++) I wished Swift were more popular because that syntax is much more familiar/friendly to me, while also having better memory…

Swift's syntax may look nice, but as soon as you run into "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" you'll forget all of that. Hint: they are related.

It didn't have to be like that though... It hasn't always been this bad. Personally I think they've been ruining Swift since version 4.

It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)

Re: Choosing a language based on its syntax?

#53

Syntax is what keeps me away from Rust. I have tried many times to get into it over the years but I just don't want to look at the syntax. Even after learning all about it, I just can't get over it. I'm glad other people do fine with it but it's just not for me. For this reason (coming from C++) I wished Swift were more popular because that syntax is much more familiar/friendly to me, while also having better memory…

Wow, this is one of the most surprising comments I've ever read on HN! Personally, I bucket C++ and Rust and Swift under "basically the same syntax." When I think about major syntax differences, I'm thinking about things like Python's significant indentation, Ruby's `do` and `end` instead of curly braces, Haskell's whitespace-based function calls, Lisp's paren placement, APL's symbols, etc. Before today I would have…

There are a lot of important points of difference. Whether functions are introduced with an explicit keyword; how return types are marked; whether semicolons can be omitted at end of line; how types are named (and the overall system for describing algebraic types). Not to mention semantics around type inference (and whether it must be explicitly invoked with a `var` or `auto` etc.) and, again, algebraic types (what means of combination are possible?). And specifically with Rust you have the syntax required to make the borrow checker work. Oh, and then there are the implicit returns. Rust certainly didn't invent that (I seem to recall BASIC variants where you could assign to the current function name and then that value would be returned implicitly if control flow reached the end), but it reflects a major difference in philosophy.

... Which is really all to say: different people are focused on different details, at different levels.

Re: Choosing a language based on its syntax?

#54

in the era of LLMs, syntax might matter more than you think. The c form of `type name;` is ambiguous because it could actually be more than one thing depending on context. Even worse if you include macro sheananigans. The alternate (~rust/zig) is `var/const/mut name type` is unambiguous. For humans, with rather long memory of what is going on in the codebase, this is ~"not a problem" for experts. But for an LLM, its…

I suspect that the context-dependence in C is more an issue with the implementation than the overall syntactic philosophy.

Re: Choosing a language based on its syntax?

#55
post #35

I never got why compilers don't have pluggable syntaxes. I mean, once you decide the "flavor" (e.g.: typed, imperative, with a dash of functional and some oop for good measure), you could have more than one syntax and easily switch to whatever the reader wants. We had an integration language in a product I worked on that had three flavors (you can check it here: https://docs.oracle.com/cd/E13154_01/bpm/docs65/pdf/Ora…

> I never got why compilers don't have pluggable syntaxes. An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem. That said, the right way to implement this is as a "transpiler" that compiles one syntax into another. And only the people who want to use it pay the costs.

> An interesting question, but the answer is "because it's a bad idea" that doesn't actually solve the problem.

This doesn't really explain anything, and it isn't clear that both of you have the same model of "the problem" in mind.

Re: Choosing a language based on its syntax?

#56
post #42

Semantics are where the rubber meets the road, certainly; but syntax determines how readable the code is for someone meeting it the first time. Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function d…

> Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like. The…

I don't have any real problem with words that are reserved absolutely and words that are reserved just in particular places. My point was more that in Algol-derived languages control structures look like control structures. And even in languages that implement `map()` and other higher-order functions, you can tell that it's a method/function call and that these things are being passed to it and those other things are not without going and looking up what `map()` does.

Re: Choosing a language based on its syntax?

#57

Semantics are where the rubber meets the road, certainly; but syntax determines how readable the code is for someone meeting it the first time. Contrast an Algol-descendant like C, Pascal, Java, or even Python with a pure functional language like Haskell. In the former, control structure names are reserved words and control structures have a distinct syntax. In the latter, if you see `foo` in the body of a function d…

> In the latter, if you see `foo` in the body of a function definition you have no idea if it's a simple computation or some sophisticated and complex control structure just from what it looks like.

All control structures are reserved as keywords in Haskell and they're not extensible from within the language. In C I can't tell that an if(condition) isn't a function call or a macro without searching for additional syntactic cues, or readily knowing that an if is never a function. I generally operate on syntax highlighting, followed by knowing that an if is always a control structure, and never scan around for the following statement terminator or block to disambiguate the two.

I've found in general programmers greatly overestimate the unreadability they experience with the ISWIM family to be an objective property of the grammar. It's really just a matter of unfamiliarity. Firstly, I say this as a programmer who did not get started in the ML family and initially struggled with the languages. The truth of the matter is that they simply engage a different kind of mental posture and have different structural lines you're perceiving, this is generally true of all language families.

Pertinant to that last point and secondly, the sense of "well this is clearly less readable" isn't unique when going from the Algol family to the ISWIM family. The same thing happens in reverse, or across pretty much any language family boundary. For example: Prolog/Horn clauses are one of the least ambiguous syntax families (less so than even S-expressions IMO), and yet we find Elixir is greatly more popular than Erlang, and the most commonly cited preference reason has to deal with the syntax. Many will say that Erlang is unintuitive, confusing, strange, opaque, etc. and that it's hard to read and comprehend. It's just the same unfamiliarity at play. I've never programmed Ruby, I find Elixir to be borderline incomprehensible while Erlang is in the top 3 most readable and writable languages for me because I've spent a lot of time with horn clauses.

I think there's a general belief programmers have where once you learn how to program, you are doing so in a universal sense. Once you've mastered one language, the mental structures you've built up are the platonic forms of programming and computer science. But this is not actually the case. More problematically, it's propped up and reinforced when a programmer jumps between two very similar languages (semantically and/or syntactically) and while they do encounter some friction (learning to deal without garbage collection, list comprehensions, etc), it's actually nothing that fundamentally requires building up an entirely different intuitive model. This exists on a continuum in both semantics and syntax. My Erlang example indicates this, because semantically the language is nothing like Prolog, its differentiation from Elixir is purely syntactic.

There is no real universal intuition you can build up for programming. There is no point at which you've mastered some degree of fundamentals that you would ever be able to cross language family boundaries trivially. I've built up intuition for more formal language families than is possibly reasonable, and yet every time I encounter a new one I still have to pour a new foundation for myself. The only "skill" I've gotten from doing this ad nauseum is knowing at the outset that mastery of J does not mean I'd be able to get comfortable reading complex Forth code.

Re: Choosing a language based on its syntax?

#58
post #33

Earlier quoted context omitted.

The most machine-friendly syntax - and the least appropriate for our LLM overlords which get confused by parenthesis because they don’t see the structure.

Have you tried? LLMs are really good at elisp, which is strange because elisp code is almost always GPL. There's an option beyond lisp. Forth has even less syntax.

In my experience, they find counting parenthesis as difficult as counting the r's in strawberry if it was spelled srtrawrrrbrrerryrrrr.

Re: Choosing a language based on its syntax?

#59
post #46

Earlier quoted context omitted.

LSP is meant for IDEs and very deterministic calls. Its APIs are like this: give me a definition of . This makes sense for IDEs because all of those can be deterministically captures based of your cursor position. LLMs are notoriously bad at counting.

I think one could easily build an MCP tool wrapping LSP which smooths over those difficulties. What the LLM needs is just a structured way to say "perform this code change" and a structured way to ask things like "what's the definition of this function?" or "what functions are defined in this module?" Not much different from what agents already do today inside of their harnesses, just without the part where they have…

So not using LSP, but rather using something in a middle that uses LSP as implementation detail.

So far enabling LSP in Claude only added messages like "this is old diagnostic before my edit".

Re: Choosing a language based on its syntax?

#60

Earlier quoted context omitted.

Definitely second this sentiment. Rust just... Looks wrong. And for that reason alone I've never tried to get into it. I understand exactly how shallow that makes me sound, and I'm not about to try and defend myself.

No need to defend yourself, I share this sentiment as well. If I'm going to spend time writing and reading a lot of code in a new learning language, I want my previous knowledge to be somewhat reusable. For this reason I was able to get into Odin as opposed to Zig because of some similarities with Swift Syntax as well how easy it is to parse. The less I need to rewire my brain to use xyz language, the greater the cha…

When I was a kid learning BASIC, a lot of beginner examples in books used the (purely decorative) keyword LET for every assignment. Consequently I associate it with "coding like a baby who understands nothing" and still hate to write let to this day.
Post reply on HN