Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make simple programs simple #155

Open
AnthonyDGreen opened this issue Aug 29, 2017 · 8 comments
Open

Make simple programs simple #155

AnthonyDGreen opened this issue Aug 29, 2017 · 8 comments
Assignees
Labels

Comments

@AnthonyDGreen
Copy link
Contributor

AnthonyDGreen commented Aug 29, 2017

There's a lot of ceremony in VB for the simplest of programs. My first program (in QBasic) was:

PRINT "Hello, World!"

Just one statement. The concept count to the equivalent VB program is much larger:

Module Program
    Sub Main()
        Console.WriteLine("Hello, World!")
    End Sub
End Module

And without features such as project-level imports and the project root-namespace there would be more concepts still. I hypothesize that removing a lot of this ceremony will make VB more approachable to the first time developer.

Proposals #102 and #103 are in this theme.

@KevinRansom
Copy link
Member

KevinRansom commented Aug 29, 2017

In F#, we support this:
printfn "Hello, World ..."

The last file in a project can contain just code no module no namespace etc ...

For a normal program entry point looks like this ...

[<EntryPoint>]
let main argv = 
    printfn "%A" argv
    0

However ... for multiple source file soutions in VB you may have more issues because you have no notion of file ordering or even a special file.

@ericmutta
Copy link

@AnthonyDGreen And without features such as project-level imports and the project root-namespace there would be more concepts still.

Some of the coolest things in VB are invisible...like those two features you just mentioned. I really love the fact that I can go crazy and use Imports repetitively in every source file or just keep it DRY and import it once at the project level. You miss this flexibility very quickly when using C# (which I have to use for Xamarin development because VB isn't supported there yet).

@rskar-git
Copy link

rskar-git commented Apr 27, 2019

Check out Dr Green's "https://anthonydgreen.net/2019/04/23/top-level-code-scenario-a/" - awesome!

@AnthonyDGreen I noticed that the demo shows that a Class is assumed in this new style rather than Module - or at least, that's what I think I'm seeing when you type out Shared Sub Main (about 1m 30s in video), followed by Call New Program().PrintBanner() (which does look kind of intimidating). Has any further thought been given to Class vs Module? Is Class going to be the winning mode?

Any thoughts on this idea?: two new file extensions: *.vbcls to make a Class, and *.vbmod to make a Module. Would that make it easier to detect the new simple style of coding, and help avoid any potential confusion or confounding in regular *.vb syntax now and in the future?

@ericmutta
Copy link

@rskar-git Check out Dr Green's "https://anthonydgreen.net/2019/04/23/top-level-code-scenario-a/" - awesome!

Thanks for sharing this link, it's a very interesting idea. For those of us who have been writing code for years (or even decades) this type of thing may seem pointless, but the other day I started teaching someone to write code and I cannot overstate how much easier it is to explain to someone what's going on when all you have on screen is Console.WriteLine().

Having just the bare minimum at each stage is also useful for teaching someone why certain language features exist. For example, with this prototype, if the file becomes long and unwieldy, you can begin to split code into subs/functions so the learner can see why a language has those constructs. And then again after you have many subs/functions you can organise them into modules/classes so the learner can see again why those constructs exist. Same thing for organizing modules/classes into namespaces.

At each stage you see how life sucks without a a given feature, then later the feature is introduced to reveal what problem it solves. This is only possible if the idea @AnthonyDGreen proposes is implemented and I hope it gets to ship soon! 👍

There is also the case that what you do to make life simpler for beginners has a way of being useful to the experienced too. As @AnthonyDGreen mentions in his blog post, this feature would make it easy to write "scratch code" intended for testing out an idea...which is something I find myself doing so often, that I have a dedicated "scratch" console project in each solution I create!

@rskar-git Any thoughts on this idea?: two new file extensions: *.vbcls to make a Class, and *.vbmod to make a Module.

I also noticed the whole Shared Sub Main thing and thought that it would re-introduce the problem of having to explain concepts like Shared because of underlying implementation details, rather than their relevance to the problem at hand. I like the idea of using file extensions to indicate one's preference (it is very much in the spirit of VB which always gives you choice), though it would be even better if the compiler could figure it out so you don't have to discuss the concept of classes and modules when the file is being created.

I realise the rules can get quite complex when figuring out how to wrap the code into a valid program, so maybe we could come up with a few key scenarios and define how each one is wrapped into a valid program (e.g. if the file contains just variable declarations and control-flow statements, you can just wrap that into Sub Main...and if the file also contains subs/functions then you can require an explicit Sub Main and have it and other subs wrapped into a module....I think these two rules may cover pretty much all scenarios where you wanted to write code without too much boilerplate. Beyond that, a learner has probably advanced enough to learn to write code the way we do now with all the concepts found in the boilerplate code).

@DualBrain
Copy link

I don't think we need different extensions... I think this creates more problems that it is worth. Besides, if you need to be able to specify whether it is supposed to be a class or module... we already have that...

With that said, I feel as everyone else does commenting that this is a feature that we really need (at minimum, one that is truly desired).

Thank you @AnthonyDGreen for taking the time to put together a prototype to demonstrate the tangible usefulness that having this would provide!

I will add...

though it would be even better if the compiler could figure it out

Although I absolutely am against the idea of having different file extensions... I could get on board with the idea that the compiler could "figure it out". In my mind this could easily be triggered by whether or not the Shared keyword is included in the optionally included Sub Main(). If Sub Main() doesn't exist, it's a Module. If Sub Main() exists without the Shared keyword, it's still a Module. If Shared is added to the Sub Main(), it's now a Class. I'm still trying to wrap my head around why this might be useful; but I'll contented that there is probably a need somewhere and I think I can definitely get on board with the concept of the language being able to adapt to the user (inference).

Also, I completely agree with @ericmutta point of view regarding the teaching side... I think the concepts are easier to absorb if the problem space is clear and the new elements introduced are clearly solving the problems that are actually experienced. Having this style of a project would better facilitate that.

With that said... I write a lot of Console applications... and I'll admit that I would simply take advantage of this because a) it's simpler (ie. laziness), b) it's cleaner (for a small project) and c) it just feels right (I've been using BASIC since the TRS-80/Atari/Commodore era).

@rskar-git
Copy link

@DualBrain

...if you need to be able to specify whether it is supposed to be a class or module... we already have that...

Yep, we certainly do for regular *.vb files as we have them now. The key trick is on whether the compiler can make a fair guess between class and module in the simple style.

If Sub Main() doesn't exist, it's a Module. If Sub Main() exists without the Shared keyword, it's still a Module. If Shared is added to the Sub Main(), it's now a Class.

I admit, that seems workable. However, that also seems kind of subtle, and we now have a situation that every class made this way also has a Shared Sub Main(). Very weird.

I'm beginning to think we should limit this simple style to the making of modules exclusively (presuming the file extension idea is now kaput). This keeps things simple for beginners. They can make classes within the module, and learn about them that way (although perhaps they would need to make sure their class definitions don't appear until after the code-block or Sub Main()). Once they graduate from there, the boilerplate of Class Foo ... End Class is no big deal.

@AnthonyDGreen
Copy link
Contributor Author

Hey just and FYI to the folks on this thread (e.g. @ericmutta @rskar-git @DualBrain ), the more expansive write-up on what was shown in the various linked blog posts about this has just been posted at #446

I'd love to hear your thoughts on the specifics!

@ericmutta
Copy link

@AnthonyDGreen Hey just and FYI to the folks on this thread...the more expansive write-up...

Will check out it, the level of detail is AMAZING and it's really great to see how much effort you are putting into this! 👍 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants