11–20 of 184 posts
I read that as: less syntax, less leaky abstractions and less macros; and I mostly agree. I would add better integration with the C tool chain, more separation of concerns and less academic ego bullshit. I've been working on something like that [0] lately. https://gitlab.com/sifoo/snigl
Sounds like the opposite of what the post is advocating.
> FILE * test_file = fopen(“/tmp/test.txt”, “w+”);
> Should become something like this:
> create file /tmp/test.txt for input and output as test_file
> Syntax highlighting should work instead of syntax notation just fine.
I couldn't disagree more.
The first example is easily scannable visually -- a variable is being created from a function call. I can tell because my eyes immediately notice the middle "=" first (easy to scan without reading) and the "(...)" in the second half (also easy to scan).
The second example is all words without punctuation, which requires me to read the entire thing word-for-word to figure out what it's doing.
We certainly shouldn't aspire to regex-like syntax for programming... but we also shouldn't aspire to prose. A healthy balance of words, punctuation, and whitespace/indentation helps to let our eyes understand the structure of code at a glance.
I'd argue that C-style syntax actually achieves this quite well, although I'm also a fan of named (as opposed to ordered) function arguments.
Not sure this is a popular opinion as presented by the author? I'd say the most sought-after PL features would be expressive type systems and those that reduce boilerplate. I've never heard someone long for a more "business oriented" programming language.
>It’s naïve to think that the language is responsible for the quality of code and that by adding some bells and whistles (or removing some bells and whistles), we can automatically make everything better […] I feel like the core issue here is in the domain of sociology and psychology, and not the programming.
I'd disagree, e.g. Rust's semantics rule out whole classes of common runtime errors. More expressive languages such as Kotlin, Scala, Swift, … are seeing rapid adoption over their more boilerplate heavy counterparts, such as Java or Obj-C. The desire for better languages is justified imho, as there's still a lot to gain. New PL development is not rooted in neurotic unhappiness, real progress is made.
> Ultimately this: > FILE * test_file = fopen(“/tmp/test.txt”, “w+”); > Should become something like this: > create file /tmp/test.txt for input and output as test_file > Syntax highlighting should work instead of syntax notation just fine. I couldn't disagree more. The first example is easily scannable visually -- a variable is being created from a function call. I can tell because my eyes immediately notice the mid…
People, don't comment before you read the whole article (and click on the survey on the bottom)...
I read that as: less syntax, less leaky abstractions and less macros; and I mostly agree. I would add better integration with the C tool chain, more separation of concerns and less academic ego bullshit. I've been working on something like that [0] lately. https://gitlab.com/sifoo/snigl
I don't agree with 'less syntax'. More syntax (when designed well) results is significantly more readable code.
Syntax for the sake of syntax is pointless, imo. Obviously there's a balance here - APL and Applescript both suffer from either extreme.
It falls into a sort of uncanny valley. Apple tried that sort of successfully with Hypertalk but really badly with AppleScript.
This submission is kind of genius because it shows how often people don't finish reading articles. There are no spoiler tags on HN, but thr TLDR is the author is describing the design goals of COBOL, and is making a point that there is no programming language or environment that can solve all your problems. I slightly disagree in a "use the right tool for the right job" sense, but it clearly helps to understand your…