Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing a language based on its syntax?

gingerbill.org

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Choosing a language based on its syntax?

#21

Post by dnautics »

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 knowledge is limited to the content that currently exists in your context, and conventions baked in with the training corpus, this matters. Of course it is ALSO a problem for humans if they are first looking at a codebase, and if the types are unusual.

Re: Choosing a language based on its syntax?

#22

Post by JamesTRexx »

nice_byte wrote: post #7

I have really just one wish when it comes to syntax: no syntactically significant whitespace. Space, newline, tab, etc. should ALL map to the same exact token. In practice this also means semicolons or something like them are needed as well, to separate expressions/statements. I dislike langs that try to insert semicolons for you, but at least it's better than the alternative. the way python treats whitespace is a hu…

That's one of the things I like about C, the independence in how one can write code. I was able to develop my own style thanks to that, visualising the structure of the code to distinguish the different parts of statements and make it more clear (at least to myself).

(edited several times to try to correct changes in formatting for an example here, but it's just screwed up :-/ )

Re: Choosing a language based on its syntax?

#23

Post by rtfeldman »

majorchord wrote: post #5

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 assumed that anyone who was fine with C++ or Rust or Swift syntax would be fine with the other two, but TIL this point exists in the preference space!

Re: Choosing a language based on its syntax?

#24

Post by wavemode »

dnautics wrote: post #21

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

Re: Choosing a language based on its syntax?

#25

Post by cfiggers »

I am an S-exp enjoyer, and more for practical reasons than aesthetic ones—I really like the editor tooling that's possible with S-expressions. So I will absolutely choose a Lisp or a lisp if given the option, even at some level of inconvenience when it comes to the maturity of the language itself. I will always write Hy[0] rather than Python, for example.

[0] https://hylang.org

(I am aware of Combobulate[1] for Emacs folks, of which I'm sadly not one.)

[1] https://GitHub.com/mickeynp/combobulate

Re: Choosing a language based on its syntax?

#26

Post by cranberryturkey »

dnautics wrote: post #21

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…

[dead]

Re: Choosing a language based on its syntax?

#27

Post by cfiggers »

majorchord wrote: post #5

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…

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.

Re: Choosing a language based on its syntax?

#28

Post by dheera »

dnautics wrote: post #21

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…

Humans also have limited context. For LLMs it's mostly a question of pipeline engineering to pack the context and system prompt with the most relevant information, and allow tool use to properly understand the rest of the codebase. If done well I think they shouldn't have this particular issue. Current AI coding tools are mostly huge amounts of this pipeline innovation.

Re: Choosing a language based on its syntax?

#29

Post by netbioserror »

Major syntactic structures definitely have an influence on my language choices. Outside of compilation and runtime model, modeling the domain (both data and procedures) changes drastically between paradigms. Syntax is what enables or hamstrings different modeling paradigms.

My two biggest considerations when picking a language are:

- How well does it support value semantics? (Can I pass data around as data and know that it is owned by the declaring scope, or am I chained to references, potential nulls, and mutable handles with lifetimes I must consider? Can I write expression-oriented code?)

- How well does it support linear pipelining for immutable values? (If I want to take advantage of value semantics, there needs to be a way to express a series of computations on a piece of data in-order, with no strange exceptions because one procedure or another is a compiler-magic symbol that can't be mapped, reduced, filtered, etc. In other words, piping operators or Universal Function Call Syntax.)

I lean on value semantics, expression-oriented code, and pipelining to express lots of complex computations in a readable and maintainable manner, and if a language shoots me in the foot there, it's demoralizing.

Re: Choosing a language based on its syntax?

#30

Post by dnautics »

wavemode wrote: post #24
dnautics wrote: post #21

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

why? I suspect that writing code itself is extremely token efficient (unless like your keywords happen to be silly, super-long alien text).

Like which do you think is more token-efficient?

1)
2)

    

    resp: 
          my_function 
          your_function 
          some_other_function 
          kernel_function1 
          kernel_function2 
          imported_function1 
          imported_function2 
          ... 
     
     resp:
          my_variable 
          other_variable_of_same_type
Post reply on HN