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

Main is usually a function. So then when is it not? (2015)

jroweboy.github.io

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Main is usually a function. So then when is it not? (2015)

#21

Post by noduerme »

ekidd wrote: post #18
noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

Hey just on a completely off-topic thing, I like your style.

But I typed the name of your website into the URL bar, and even stupid Firefox just hung trying to load or trying to redirect from what it thinks should be the default https version. Had to specify http:// to load it. The browsers are making it almost impossible these days to just go to a plain website. half the time they loop themselves into a frenzy and cache the failed address with predictive type to the https version somewhere a normal user can't clear it, even when clearing history. It's a bloody mess for anyone who still needs to build http services.

Re: Main is usually a function. So then when is it not? (2015)

#22

Post by picadores »

We built a embedded "Operating System" during CS science courses, that was basically just a continous recursion, were the stack was eliminated and reset repeatetly. Main was just some assembly manipulating the instruction pointer to get the whole thing rolling. Good times, good crimes.

Re: Main is usually a function. So then when is it not? (2015)

#23

Post by moron4hire »

ekidd wrote: post #18
noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

Top-level execution doesn't require linear execution. As an example, JavaScript has top-level execution where function definition order doesn't matter. This is achieved by "hoisting" all function declarations within a block of execution to the beginning of the block before then exercising any statements.

Re: Main is usually a function. So then when is it not? (2015)

#24

Post by fstokesman »

noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file.

The trickiest thing is that main() is not even the bootstrap function. The actual entry point of a program is usually generated by libc, and is called generally called _start (though it can be anything).

Re: Main is usually a function. So then when is it not? (2015)

#25

Post by krisoft »

ekidd wrote: post #18
noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

> ...then a() needs to crash when first called, because b() hasn't been declared yet.

Why would it “need to” crash? If it is easier to implement to not crash and the developer intention is clear why would you define your new programing language such that it “needs to crash” in this situation?

It is as if you go to your garden to pick tomatoes, but you trip over a rake you intentionally put in your way and then as you lay on the ground hurting you conclude that it is impossible to pick tomatoes. Picking the tomatoes in this case is making a compiled programing language which has a main file instead of a main function. And the rake you trip over is the intentional decision to make the program crash in this situation. Just don’t put the rake there (choose to not crash in this situation) and then you can pick the tomatoes (have a compiled language with a main file instead if a main function).

There might be more complicated reasons why it is neccesary to have a main function, but this example does not really demonstrate it for me.

Re: Main is usually a function. So then when is it not? (2015)

#27

Post by ufo »

krisoft wrote: post #25
ekidd wrote: post #18

Earlier quoted context omitted.

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

> ...then a() needs to crash when first called, because b() hasn't been declared yet. Why would it “need to” crash? If it is easier to implement to not crash and the developer intention is clear why would you define your new programing language such that it “needs to crash” in this situation? It is as if you go to your garden to pick tomatoes, but you trip over a rake you intentionally put in your way and then as you…

One corner case is that b() might use variables that are initialized further down in the file. Some languages, such as Javascript, lift function definitions to the top so you can call functions defined below you, but it's harder to do the same for variables. In a compiled language it should be possible to detect this at compile time, but it's fiddly and more complicated than having a main function.

Re: Main is usually a function. So then when is it not? (2015)

#28

Post by Kim_Bruning »

ekidd wrote: post #18
noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

Heh, I first ran into this issue with the built in assembler in BBC BASIC II.

You couldn't naively make a forward reference to label. This is because wasn't defined yet at the time the assembler encountered your instruction.

That's when you learned about multi-pass assembly.

Re: Main is usually a function. So then when is it not? (2015)

#29

Post by mypetocean »

noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

I've become a big fan of using something like a `main()` function to act as the one conventional place where pure functions are piped together at the top of a module.

You get this very nice linear execution birds' eye view which tends to be readable. Combine that with hoisting and you start with this big picture at the top of a file, and then can dig deeper into the smaller functions as needed, written in lexical order lower in the file.

Here is a very trivial JS example from a kata:

```js function main (numbers) { return Array .from(numbers) .sort(byGreatest) .slice(0, 2) .reduce(toSum) } ```

This is much more regularly written in languages with a pipeline operator, like Elixir, because you can pipe to arbitrary functions and operators (instead of being restricted to a method chain).

(JS/TS will get there eventually, if the TC39 committee can ever finally commit to the proposal.)

Re: Main is usually a function. So then when is it not? (2015)

#30

Post by em-bee »

ekidd wrote: post #18
noduerme wrote: post #16

This is fun. On a broader note though, entry point main-type functions have always bothered me. Maybe because I grew up as a simple script kiddie with BASIC and Bash and PHP. I like code that starts executing from the first line and then runs whatever functions it wants to run. I realize that's just an abstraction of main() but it's a pleasant one for me. There's something more constricting about there being one func…

> There's something more constricting about there being one function to bootstrap everything than there is about one file. As a compiler author, there are a bunch of nasty surprises to this approach. If you execute a file line-by-line, then functions only exist once you "reach" them. If you write: def a(): b() a() def b(): ... ...then a() needs to crash when first called, because b() hasn't been declared yet. So your…

how about before anything is executed, add a parse step that reads the whole file, looks for function definitions, and then goes back to the start to execute?
Post reply on HN