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

31–40 of 59 posts

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

#31

Post by noduerme »

ufo wrote: post #27
krisoft wrote: post #25

Earlier quoted context omitted.

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

From Mozilla's docs:

>> JavaScript Hoisting refers to the process whereby the interpreter appears to move the declaration of functions, variables, classes, or imports to the top of their scope, prior to execution of the code.

>> Hoisting is not a term normatively defined in the ECMAScript specification. The spec does define a group of declarations as HoistableDeclaration, but this only includes function, function*, async function, and async function* declarations. Hoisting is often considered a feature of var declarations as well, although in a different way. In colloquial terms, any of the following behaviors may be regarded as hoisting:

>> Being able to use a variable's value in its scope before the line it is declared. ("Value hoisting")

>> Being able to reference a variable in its scope before the line it is declared, without throwing a ReferenceError, but the value is always undefined. ("Declaration hoisting")

>> The declaration of the variable causes behavior changes in its scope before the line in which it is declared.

>> The side effects of a declaration are produced before evaluating the rest of the code that contains it.

So basically all the shit we take for granted when not writing C/C++. What is curious to me is whether the main reasons for not attempting this in a C++ compiler in 2023, or else moving the language spec in this (unofficial) direction, is to produce maximal performance-optimization, or if it's mostly a cultural thing at this point. It does have the benefit of turning away hordes of javascript kiddies from the gates, but, the relative value of the performance edge to any optimization is getting weaker as compute becomes cheaper.

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

#32

Post by noduerme »

moron4hire wrote: post #23
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…

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.

Right. Adding virtual classes in weird orders does not make code more readable, and it's just a hint for the compiler anyway.

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

#33

Post by cpfohl »

simias wrote: post #20
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 someone who basically started coding with C I feel the other way around, unsurprisingly. Even in scripting languages when I write something non trivial I tend to encapsulate everything in functions and then have a `main()` call at the bottom of the file. I think it's one of the things python g…

> it amuses me that a language so obsessed with getting rid of symbols and looking like pseudocode decided that such cumbersome, obtuse and ugly looking boilerplate was just fine.

100 times this! I have always wondered about that.

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

#34

Post by noduerme »

mypetocean wrote: post #29
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 ord…

I like the method chain and find it very readable (and a good guarantor of typed output in the absence of strict types, if you use something like Typescript to lint it). But I don't see how the choice between that or a pipe operator has any impact on whether function main() should be your program's entry point. Unless your program is going to be an endless loop, e.g. a Nodejs server or else a game, I don't know why you'd want to saddle yourself with a main() every time it runs.

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

#35

Post by tw37074462 »

noduerme wrote: post #21
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…

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

> even stupid Firefox just hung trying to load or trying to redirect from what it thinks should be the default https version

Cannot reproduce.

The only problem(s) I'm seeing are related to operator error; nothing to do with browsers "loop[ing] themselves into a frenzy". The server at www.randomhacks.net works, but the server at randomhacks.net, on the other hand (and which is not the same as www.randomhacks.net), is for whatever reason failing to respond to the HTTP request. Reasonable guess: it's not a Web server.

At best, the service operator has the server (arguably) misconfigured, and the client operator is expecting the browser to do something it shouldn't while blaming failure on the browser after assuming it's doing something that it isn't actually doing.

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

#36

Post by [deleted] »

noduerme wrote: post #31
ufo wrote: post #27

Earlier quoted context omitted.

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.

From Mozilla's docs: >> JavaScript Hoisting refers to the process whereby the interpreter appears to move the declaration of functions, variables, classes, or imports to the top of their scope, prior to execution of the code. >> Hoisting is not a term normatively defined in the ECMAScript specification. The spec does define a group of declarations as HoistableDeclaration, but this only includes function, function*, a…

[deleted]

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

#37

Post by noduerme »

tw37074462 wrote: post #35
noduerme wrote: post #21

Earlier quoted context omitted.

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

> even stupid Firefox just hung trying to load or trying to redirect from what it thinks should be the default https version Cannot reproduce. The only problem(s) I'm seeing are related to operator error; nothing to do with browsers "loop[ing] themselves into a frenzy". The server at www.randomhacks.net works, but the server at randomhacks.net, on the other hand (and which is not the same as www.randomhacks.net), is…

You're right, my bad, the www subdomain just works, the plain domain hangs not as a result of a redirect. I thought I was looking at one of those 443>80 crack-ups once I got it to resolve and it was plain http, but I didn't notice I'd re-added the www.

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

#39

Post by ufo »

noduerme wrote: post #31
ufo wrote: post #27

Earlier quoted context omitted.

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.

From Mozilla's docs: >> JavaScript Hoisting refers to the process whereby the interpreter appears to move the declaration of functions, variables, classes, or imports to the top of their scope, prior to execution of the code. >> Hoisting is not a term normatively defined in the ECMAScript specification. The spec does define a group of declarations as HoistableDeclaration, but this only includes function, function*, a…

The genie got somewhat out of the bottle with constructors: C++ will call constructors to initialize static variables. In theory we could use this mechanism to allow top-level statements. However, these static initializers are so full of footguns that perhaps it's best we don't :P

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

#40

Post by OJFord »

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…

Surely it's less constricting? You can put that one function anywhere.

(I grew up on python, then C etc. at university, but as sibling says in Python I'd still `if __name__ == "__main__"`.)

Post reply on HN