Live data from Hacker News

Choosing a language based on its syntax?

gingerbill.org

61–70 of 111 posts

Re: Choosing a language based on its syntax?

#61

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…

I agree, that I do not like automatic semicolon insertion (in my opinion it is one of the worst features of JavaScript, and possibly the really worst one), and I think it is a good idea that you should use semicolons or whatever to separate expressions and statements (except for a programming language where it is already unambiguous (e.g. because you are required to have brackets around them instead), in which case it is unnecessary).

However, spaces, line breaks, tabs, page breaks, etc are not normally tokens (and should not be tokens), but will separate tokens.

However, that is not the only issue with the syntax, although it is a significant one.

Re: Choosing a language based on its syntax?

#62

Earlier quoted context omitted.

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.

Reading files is not that input tokien heavy, I suspect. But anyways I omitted it because presumably it would have done so to gain local context in general.

Re: Choosing a language based on its syntax?

#63
post #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.

It's a thing in c.

foo * bar;

Is that multiplication? Or a declaration of type foo*?

Re: Choosing a language based on its syntax?

#64
post #54

Earlier quoted context omitted.

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

It's a thing in c. foo * bar; Is that multiplication? Or a declaration of type foo*?

Right; and my argument is that this isn't because the type expression `foo *` precedes the name `bar`; it's because the type "pointer to foo" is expressed in a way that could also be a prefix of a multiplication expression.

Re: Choosing a language based on its syntax?

#65

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…

I agree, that I do not like automatic semicolon insertion (in my opinion it is one of the worst features of JavaScript, and possibly the really worst one), and I think it is a good idea that you should use semicolons or whatever to separate expressions and statements (except for a programming language where it is already unambiguous (e.g. because you are required to have brackets around them instead), in which case i…

Yeah I misused the term "token". What I really meant is that they should just be token separator and nothing more (i.e. once we encounter whitespace it means the current token has ended)

Re: Choosing a language based on its syntax?

#66
Hmm... I don't know how serious this wants to be taken

- first example argues that syntax is interchangeable

- but then the author tries to sell me his semis

???

And who even cares in the time of LLMs and auto formatting?

"My hammer has this slight angle and if I hit the nail with just the right motion, it feels really good"

Re: Choosing a language based on its syntax?

#67
post #53

Earlier quoted context omitted.

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 m…

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

Yes, these are all examples of things I always thought were generally considered small enough differences that nobody who was okay with how C++ or Rust or Swift did them would find the way one of the others did it a deal-breaker.

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

For sure!

Re: Choosing a language based on its syntax?

#68

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.

When I ponder about PL semantics, crossroad feature is currying. This decides whether partial application, pattern matching, function composition, combinators, and other functional features would play a major role in the language design. Functions are curried? ML style. Not curried? C style.

Re: Choosing a language based on its syntax?

#69
post #2

Language syntax is like the weather. When it's good (or when you're acclimated to it, I guess) you don't notice it. When the weather is perfect you don't even feel like the atmosphere even exists. When a language is so ingrained in your mental models, you don't even notice syntax, you just see semantics.

True to any design in general.

Re: Choosing a language based on its syntax?

#70

I like the semantics you type in the google search bar when using it for impromptu calculations. You can use ^ to raise to a power, for example. Just type sin 45. It’s all least surprise.

I wonder how many people use REPL of a language of choice as a calculator as I do.
Post reply on HN