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

41–50 of 111 posts

Re: Choosing a language based on its syntax?

#41

Post by vidarh »

juancn wrote: 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…

Code is communication. The compiler could handle it, but what is important is that other people can.

There are many infamous examples of people using the C preprocessor to write near-Pascal or similar in C. It largely died out because it hindered effective communication about the code.

Re: Choosing a language based on its syntax?

#42

Post by zahlman »

wduquette wrote: post #8

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 former provides more clues, which makes it easier to decipher at a glance. (Not knocking Haskell, here; it's an interesting language. But it's absolutely more challenging to read.)

For what it's worth, Python has been moving away from this, taking advantage of a new parser that can implement "soft keywords" like 3.10's "match" statement (which I'm pretty sure was the first application).

Believe it or not, the motivation for this is to avoid reverse compatibility breaks. Infamously, making `async` a keyword broke TensorFlow, which was using it as an identifier name in some places (https://stackoverflow.com/questions/51337939).

In my own language design, there's a metaprogramming facility that lets you define new keywords and associated control structures, but all keywords are chosen from a specific reserved "namespace" to avoid conflicts with identifiers.

Re: Choosing a language based on its syntax?

#43

Post by zahlman »

norir wrote: post #40

I personally would prefer to hear more about what is uniquely good about Odin semantically or syntactically than more ad hominem attacks on the intelligence of the critics of the language, which I have seen in multiple recent pieces by this author.

Agreed; this communication style by itself makes me less inclined to try out the language.

Re: Choosing a language based on its syntax?

#44

Post by shevy-java »

This is the old "syntax does not matter" claim. Syntax is not the most important thing in the world when it comes to programming languages, but it does matter too. I was using perl, then PHP then ruby. There is no comparison here; ruby beats the other two languages hands down. I get to be able to do more, with less syntax and it is easier to read too (provided you write good code; you can write horrible code in any language of course).

Most of the languages that are created anew, end up being a clone of C or C++. Go is one of the few exceptions here; Rust is not an exception. It is basically C++ really, from the syntax - or even worse.

Sadly it is not possible to try to convince people who claim that syntax does not matter, that it does matter. They just keep on repeating that syntax is irrelevant. I don't think syntax it is irrelevant at all. It has to do with efficiency of expression. Clear thoughts. Clear design. It is all inter-connected.

Re: Choosing a language based on its syntax?

#45

Post by andersmurphy »

kgwgk wrote: post #33
cfiggers wrote: post #25

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…

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.

Re: Choosing a language based on its syntax?

#46

Post by 0x457 »

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

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.

Re: Choosing a language based on its syntax?

#47

Post by ErroneousBosh »

jiriknesl wrote: post #32

I don't want to be overly negative, but it seems to me that author considers just different flavours of C. There is a massive difference between Clojure, Prolog, and Forth. The whole: type name = value—type-focused name: type = value—name-focused var name type = value—qualifier-focused Is so much deep into details of how syntax might look like. If you are choosing between Kotlin and Go, it is for the platform, not th…

All programming languages are basically Algol or Lisp, even the ones I like.

C? Basically Algol. Pascal? Basically Algol, actually quite closely. Go? Basically Algol, via Pascal. Lua? Basically Algol, surprisingly closely.

Forth? Basically Lisp. Postscript? Basically Lisp.

Re: Choosing a language based on its syntax?

#48

Post by O-stevns »

cfiggers wrote: post #27
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.

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 chance of me getting into it.

If my life depended on it, I could get over such a shallow reason to dismiss a language but fortunately it doesn't and that's why I write Swift rather than Rust.

Re: Choosing a language based on its syntax?

#49

Post by wavemode »

dnautics wrote: post #30
wavemode wrote: post #24

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

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

Not sure I follow. You seem to have omitted the part of 1) explaining how the LLM knew that my_function even existed - presumably, it read the entire file to discover that, which is way more input tokens than your hypothetical available_functions response.

Re: Choosing a language based on its syntax?

#50

Post by d-us-vb »

imglorp wrote: post #4

As Ken Iverson noted in "Notation as a Tool of Thought"[1], yeah the syntax absolutely matters. The same program might resonate and make sense in one language but be incomprehensible if translated 1:1 in another. Computer languages are for humans to understand and communicate. 1. https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...

Iverson's point is more regarding semantics than syntax, though. The only mention of syntax suggests its better for it to be simple (presumably so that the semantics are closer to the surface). Every programming language is a notation for describing computation; notation is a catch all for all three levels: orthography, syntax, and semantics. APL is interesting because it not only uses an unconventional syntax, but also an unconventional orthography (obligate usage of special symbols), and its semantics are different as well from most languages (array programming). Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, and that this point generalizes across programming languages.

GingerBill's article is making a narrower claim: that semantics are what determines a good notation usually, not syntax.

Post reply on HN