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

Designing a programming language to speedrun Advent of Code

blog.vero.site

Post reply on HN
Print view View original

11–20 of 101 posts

Re: Designing a programming language to speedrun Advent of Code

#11

Post by hnlmorg »

KeplerBoy wrote: post #6
bmitc wrote: post #5

Earlier quoted context omitted.

I don't really even understand what is meant by "being able to write code from left to right without backtracking”, much less why that is bonkers. Scrolling down and seeing the code examples, the language even seems quite conventional, so I'm even more confused.

Isn't that a whole lot more "being able to write code without making a lot of dumb mistakes", which is a feature of the programer. So it boils down to getting gud and practice?

No, what the author is discussing is a syntax thing.

Lets take a hypothetical C-like language:

    result = C(B(A()))
In this your result is on the left hand side. The first function to be executed is A and then B and lastly C, which also reads right to left. This is a pretty common way to write code, it's by no means unique to C-like languages. So you'd have gotten so good at reading code like this that you probably don't even realise you're reading right to left.

Now lets look at a POSIX-like shell language:

    result = $(A | B | C)
Here the result is still on the left hand side but now you're reading the functions from left to right (ie pipes)

I'm not the article author by my own programming language takes things a step further from conventional shells and you can do the following:

    A -> B -> C -> set result
Here it reads fully left to right. There is zero confusion about which order to read this.

----------------

Going back to the more general point about reading left to right, it's worth noting that even math operators can be extended this way. For example with polish notation (https://en.wikipedia.org/wiki/Polish_notation) your operators precede your values. Effectively turning those symbols into function names:

    + 2 5
...would return 7

Though personally I prefer the more traditional format of operators sitting between their values (2+5), but that's purely because that is what I'm used to.

Re: Designing a programming language to speedrun Advent of Code

#13

Post by bmitc »

ThreeToZero wrote: post #9
KeplerBoy wrote: post #6

Earlier quoted context omitted.

Isn't that a whole lot more "being able to write code without making a lot of dumb mistakes", which is a feature of the programer. So it boils down to getting gud and practice?

The post gives an example of how python doesn't have this feature in the section [ https://blog.vero.site/post/noulith#coding-with-and-without-... ] Python fails this criteria because if you type as you think through the process, you have to move the cursor to the beginning to prefix the 'map' around the input. For example this series of transforming the input: puzzle_input.split("\n\n") map(ints, puzzle_input.split(…

Thanks for pointing out that specific example and comparison. The solution seems like it's just a less readable pipeline.

    puzzle_input split "\n\n" map ints map sum then max;
    puzzle_input split "\n\n" map ints map sum then sort then (_[-3:]) then sum;

Re: Designing a programming language to speedrun Advent of Code

#14

Post by xiaq »

hnlmorg wrote: post #11
KeplerBoy wrote: post #6

Earlier quoted context omitted.

Isn't that a whole lot more "being able to write code without making a lot of dumb mistakes", which is a feature of the programer. So it boils down to getting gud and practice?

No, what the author is discussing is a syntax thing. Lets take a hypothetical C-like language: result = C(B(A())) In this your result is on the left hand side. The first function to be executed is A and then B and lastly C, which also reads right to left. This is a pretty common way to write code, it's by no means unique to C-like languages. So you'd have gotten so good at reading code like this that you probably don…

You can write A | B | C | result=$(cat) in shell.

Edit: this only works if the shell runs the last command in the current environment (as opposed to a subshell), and only ksh and zsh seem to do that...

Re: Designing a programming language to speedrun Advent of Code

#15

Post by frou_dh »

hnlmorg wrote: post #3

> Before we move on, I want to point out that “being able to write code from left to right without backtracking” is a completely bonkers thing to optimize a programming language for. This should not be anywhere in the top hundred priorities for any “serious programming language”! There are plenty of serious languages that are written this way. Most noticeably are shell scripting languages but I’ve seen stack based an…

Talking of shell, the preference for left-to-right is often used to justify "useless use of cat", i.e. `cat file | command` instead of `command <file`, but it can just be written `<file command` instead.

Re: Designing a programming language to speedrun Advent of Code

#16

Post by [deleted] »

xiaq wrote: post #14
hnlmorg wrote: post #11

Earlier quoted context omitted.

No, what the author is discussing is a syntax thing. Lets take a hypothetical C-like language: result = C(B(A())) In this your result is on the left hand side. The first function to be executed is A and then B and lastly C, which also reads right to left. This is a pretty common way to write code, it's by no means unique to C-like languages. So you'd have gotten so good at reading code like this that you probably don…

You can write A | B | C | result=$(cat) in shell. Edit: this only works if the shell runs the last command in the current environment (as opposed to a subshell), and only ksh and zsh seem to do that...

[deleted]

Re: Designing a programming language to speedrun Advent of Code

#17

Post by robertlagrant »

frou_dh wrote: post #15
hnlmorg wrote: post #3

> Before we move on, I want to point out that “being able to write code from left to right without backtracking” is a completely bonkers thing to optimize a programming language for. This should not be anywhere in the top hundred priorities for any “serious programming language”! There are plenty of serious languages that are written this way. Most noticeably are shell scripting languages but I’ve seen stack based an…

Talking of shell, the preference for left-to-right is often used to justify "useless use of cat", i.e. `cat file | command` instead of `command <file`, but it can just be written `<file command` instead.

I'm surprised that file> command isn't the preferred idiom. Does that mean something else?

Re: Designing a programming language to speedrun Advent of Code

#19

Post by hnlmorg »

robertlagrant wrote: post #17
frou_dh wrote: post #15

Earlier quoted context omitted.

Talking of shell, the preference for left-to-right is often used to justify "useless use of cat", i.e. `cat file | command` instead of `command <file`, but it can just be written `<file command` instead.

I'm surprised that file> command isn't the preferred idiom. Does that mean something else?

Yes, that would write to a file called "command". So the correct way to write that would be:

    command > file
https://www.gnu.org/software/bash/manual/html_node/Redirecti...

Re: Designing a programming language to speedrun Advent of Code

#20

Post by smrq »

robertlagrant wrote: post #17
frou_dh wrote: post #15

Earlier quoted context omitted.

Talking of shell, the preference for left-to-right is often used to justify "useless use of cat", i.e. `cat file | command` instead of `command <file`, but it can just be written `<file command` instead.

I'm surprised that file> command isn't the preferred idiom. Does that mean something else?

That would execute the command `file` and put the output into the file `command`.
Post reply on HN