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

71–80 of 111 posts

Re: Choosing a language based on its syntax?

#71

Post by tialaramex »

shevy-java wrote: post #44

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

> Rust is not an exception. It is basically C++ really, from the syntax - or even worse.

That's a superficial impression. Yes the resemblance is on purpose, but it doesn't go very deep which suggests you haven't stared at this for more than a few seconds.

Re: Choosing a language based on its syntax?

#72

Post by tialaramex »

zahlman wrote: post #55
hyperpape wrote: post #38

Earlier quoted context omitted.

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

The usual way people get here is that they didn't realise programs are for reading by humans. That's why we have formatting conventions (the compiler doesn't care but humans do) and so it's also why a single syntax is important.

If there are six syntaxes for a hypothetical language L, then either every L practitioner must learn all six syntaxes (ew, no thanks) or most L programmers can't read each other's programs and so it's basically unmaintainable.

Re: Choosing a language based on its syntax?

#73

Post by tialaramex »

zahlman wrote: post #36

> I am still perplexed by how people judge a language purely by its declaration syntax, and will decide whether to use the language purely based on whether they like that aspect or not. Throughout the article, OP seems baffled that people have aesthetic preferences. Well, yes, of course we do; dealing with ugly things is the computer's job. It also comes across like OP hasn't seen a lot of examples of really interest…

> Throughout the article, OP seems baffled that people have aesthetic preferences. Well, yes, of course we do

I think Bill is astonished not really that people have aesthetic preference but that anybody's real preferences could be different from his. He supposes that, at most, these are false beliefs they should reject to reveal that their sincere preference is identical to his, the only correct preference.

Re: Choosing a language based on its syntax?

#74

Post by zahlman »

rtfeldman wrote: post #67
zahlman wrote: post #53

Earlier quoted context omitted.

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

> examples of things I always thought were generally considered small enough differences...

The thing is that they add up. Writing C or C++ is unpleasant enough for me that I've seriously thought about learning Rust just to have an alternative in that niche that actually has traction this time. (I wasn't under the impression that Swift — or Go, similarly — is intended to be quite as low-level. But maybe they are?)

Re: Choosing a language based on its syntax?

#75

Post by wavemode »

dnautics wrote: post #62
wavemode wrote: post #49

Earlier quoted context omitted.

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.

I still don't follow. Why doesn't that count as cost?

Re: Choosing a language based on its syntax?

#76

Post by teo_zero »

zahlman wrote: post #64
dnautics wrote: post #63

Earlier quoted context omitted.

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.

Yes, it's a pity that some symbols have been overloaded with multiple meanings and the syntax can't disambiguate them. This case would not exist if another symbol had been chosen for dereference.

A similar claim, equally not related to type declarations, is with & that serves two roles as a boolean operator and address-of, that makes (foo)&bar ambiguous.

The list of C symbols that have been badly chosen at the beginning and now it's too late to correct continues with && for logical and, that prevents masking an address-of without adding spaces or parentheses in ``mask & &var``, /* for comments, that prevents dividing by a dereferenced value without adding spaces or parentheses in ``*a / *b``, the pre-increment ``--`` that is indistinguishable from a double application of the unary minus, and the original =+ etc. that have been later changed to += etc.

Re: Choosing a language based on its syntax?

#77

Post by dnautics »

wavemode wrote: post #75
dnautics wrote: post #62

Earlier quoted context omitted.

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.

I still don't follow. Why doesn't that count as cost?

A+B > A+C => B > C

Re: Choosing a language based on its syntax?

#78

Post by dnautics »

zahlman wrote: post #64
dnautics wrote: post #63

Earlier quoted context omitted.

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.

Ok fine but never here have I not been talking specifically about C

Re: Choosing a language based on its syntax?

#79

Post by ErroneousBosh »

ivanjermakov wrote: post #68
ErroneousBosh wrote: post #47

Earlier quoted context omitted.

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.

What's "ML" in this context?

Re: Choosing a language based on its syntax?

#80

Post by ivanjermakov »

ErroneousBosh wrote: post #79
ivanjermakov wrote: post #68

Earlier quoted context omitted.

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.

What's "ML" in this context?

ML (Meta Language)

https://en.wikipedia.org/wiki/ML_(programming_language)

Post reply on HN