Original request here:  http://phrogram.com/forums/permalink/6917/6918/ShowThread.aspx#6918

The forums totally messed this up when I tried to merge the threads so here's all the input:

randya:

I would like to throw one task on your to-do list.  Phrogram needs to handle multiple files (i.e., some form of packaging).  Having classes is a great step from top down programming to OO, but (IMHO) the concept of reuse is not very powerful when everything must be contained in the same file.

davidw:

the project? Then, presumably, a file in one project (perhaps with a user-defined class) can be used in another project as well ... well, we could try to go in that direction, although it feels more like intermediate (rather than beginner) level capabilities. And we try to contextualize everything we do in terms of, "can a beginner handle it?"

 

LFS:

I would think the goal would be to get them performing intermediate tasks, from the beginner mentality. For example, 3D games were definately not in beginner territory until you guys made it so with KPL. Likewise with other advanced techniques, if made to appear simple, they would educate as well as provide powerful functionality using a streamlined (or simplified) interface. The idea of allowing for multiple files has been suggested before here.

randya:

The term packaging was a poor choice on my part.  I've worked with many IDEs (most recently with Eclipse, Netbeans, and IntelliJ) and I know firsthand that defining and maintaining a project can be a confusing and daunting task, and certainly not one for a beginner to tackle.

My point is simply that the next step from developing a class-based program is to separate the classes into individual source files.  Presumably, as new developers move forward they will quickly see that very few programs are encased in one large file.  Again IMHO, the quicker developers get use to seeing a program comprised of multiple files, the easier it will be for them to understand more complex concepts, like builds.

To be clear, I am definitely not advocating using make files, ant scripts, or other build methods.  Those concepts quickly move away from the realm of beginner. Rather, I would like to see something on the order of include or import statements: some concept or method that will allow me to demonstrate how software can be divided up conceptually and yet come together to accomplish a task.

So it comes down to how would include/import be implemented by the compiler, and thats a tough one.  I think thats where the real complexity lies.  You certainly wouldn't want to introduce anything like classpath (at least I don't think you would want to).  We could come around full circle and say that every Phrogram program has a directory and all source resides in it ala projects.  I'm not sure if that's the answer.  Perhaps it could be as simple as all files have to reside in the same directory as the file with the main() method.

Well, it certainly is something to think about. And I do appreciate your concern that it might be a tick above the beginner level.  Certainly, there are are plenty of lessons to be taught/learned using Phrogram's current capabilities.

Pro:

1. Its how other .Net languges work - useful to learn how it works while you are beginning
2. Shrinks size of source code - your application is now easier to edit and control when it grows beyond small size
3. Allows for reuse

Con:

1. Single file - everything in one place makes for an easier thought process for small programs and easier distribution - "here's my .kpl file"
2. One more thing to teach a beginner.... and think for a minute of total beginners. Every single new concept you need to to teach is potentially a barrier to solving the problem

Issues to discuss:

1. Can we solve the visibility problems in other ways - the file can be a single file and we can present it in different UIs
2. How do we solve the reuse problem when people link to a library on their hard drive that isn't on yours. We can duplicate files when you 'include' them but then you end up with multiple copies.
3. Should be mark routines as 'for reuse' and have a library function within Phrogram so we know what is shared and what is not?

Just a few comments on the pro's and con's post:

Pro:

1. Useful to learn. - Precisely why it would be a good feature to 'include'.

2. Shrinks size of source code. -  A boon to writing larger programs, its not fun writing a program when you have to fight the editor to get your code entered.

Con"

1. Single file. - An Include feature need not be used if it is not needed, so small programs can still be in one file.

2. One more thing. - Again. only needed when their skills advance to the higher levels. It is pretty self explanitory, ( Include MyFile.kpl ) so the real effort there is simply to know it exists.

Issues:

1. Other ways. - The problem is the editor slow down with large files / managment of large source code.  Windowing sections of code (providing another tab or similar) would be IMHO more confusing than a simple one line Include command.

2. Missing library problem. - Is very similar to a missing media file problem. While there are several commands that might load an image, only one command would load a library so a search of the source code for that command would be easier than searching for code that calls up media files. In other words, fixing the problem would be easier than fixing missing media issues.

3. Special 'reuse' mark. - Not needed, so why bother?  It would be simpler to explain its use if it simply means 'additional source code located in a separate file". the only time files really need to be duplicated is when packaging the program for uploading/sharing.  Safegaurds would be needed to avoid overwriting files when un-packaging, but that is a common issue for all files. 

. 

LFS:

Con

1. Single file. - An Include feature need not be used if it is not needed, so small programs can still be in one file.

But beginnes learn by reading other peoples code. So if samples used the multi file/include view then its something that people might have to learn up front. It becomes one more thing to learn.

LFS:

2. One more thing. - Again. only needed when their skills advance to the higher levels. It is pretty self explanitory, ( Include MyFile.kpl ) so the real effort there is simply to know it exists.

We have heard of and seen some languages that have advanced views and advanced modes (the current Phrogram ones doesn't afect language just the IDE) and we've resisted that approach in the past. Maybe its time to revist this.

In fact a lot of the problems we face going forward are going to suffer from this kind of argument. When do we tell people that its time to move on to C# or VB? We dont want Phrogram to become just another .Net language.

The trouble I see is that the editor actually slows down and becomes a bear to use when program size exceeds about 30-40K.  That is one area where having multiple files would be advantagous.  Yes, small files could still use Include so the beginner may run into it, and as I already said, "Include" is pretty much self explanitory so the learning curve is pretty flat for that one.  Simply seeing it used once is about all they will need to see to learn how to use it.  I just don't see this as an 'advanced' feature, it is simply another tool used in managing source code.

Phrogram has its own IDE, how is it going to become a .Net language?  Some may not desire to move on simply wanting to learn a little about programming, not intending to make a career out of it....

I agree with Larry, if the only code related to it is "Include MyFile.kpl" then there's not much else to say about it. About the same difficulty as learning the difference between

"Define Index as Integer"

and

"Var Index as integer"

Rather simple, isn't it? I can only think of a few "confusion spots" when it comes to Include.

1: What does it do,

2: Why would I use it,

3: Ooops, I can't find that file.

with 3 being the most obvious. The solution is simple: zip all your files before uploading them. The exact same thing happens with media files, and the answer is the same. 

I don't see how this would compromise simplicity any more than the Define/Var confusion.

Imagine a language that has 10 features... beginners seem to enjoy it and learn quickly... imagine that language gets 20 features.... beginners find it more difficult but the power users love it.... the next year it has 40 features... the power users are crazy happy but the beginners see all the great applications and want to do the same. But they can't becuase it means using all 40 features.

I don't think inlcude in itself is a hard concept but I am just saying that adding feature after feature isn't always the right way to skin a cat.

I agree, a feature laden application easily becomes confusing rather than productive.  On the other hand, when providing a well rounded environment, the basic necessities should be covered before adding rarely used, or otherwise obscure features.  The ability to divide up the program into (reusable) files is (IMHO) far closer to the basics than say an option to "SetConsoleBulletMode" or the ability to find the hyperbolic cosine of some number.

If you really want to get fancy, catering to beginners and advanced users alike, you might devise some means of tagging each command with a level value such that the IDE and Class Viewer would only accept and show commands whose value is equal or less than the current Level setting of the IDE.  All the bare necessities would be at level 1, with more fined grained control as the levels advance.  Then people would know if they see a 'Level 1" program, it is a very basic (simple) program, and so on for the different levels.  Likewise, beginners could start learning only 'Level 1" commands, and still be able to write some nifty programs.  In that way you can reduce the learning curve to a series of more managable steps, where your concern for too many features would be addressed. People who set their IDE at level 1 won't see or use any commands higher than level 1, and likewise on up the scale. Its a bit of a stretch, but could be done!  ;-)

LFS:

I agree, a feature laden application easily becomes confusing rather than productive.  On the other hand, when providing a well rounded environment, the basic necessities should be covered before adding rarely used, or otherwise obscure features.  The ability to divide up the program into (reusable) files is (IMHO) far closer to the basics than say an option to "SetConsoleBulletMode" or the ability to find the hyperbolic cosine of some number.

I wholeheartedly agree. A while ago I found this game engine that was fully loaded feature-wise. It had a full terrain engine, a very versatile particle system, an integrated lighting engine, animated mesh support, convex-polygon collision engine and oh so much more. I though to myself, "Wow! This looks like every 3D game developer's dream! I'll go ahead and try it out.". So I tried it out. Most of the features were only accessible through the scripting language they used ( Yes it had a GUI world designer for placing objects etc ). Well, it turns out that the language was a very confusing non-user-friendly mess. I couldn't for the life of me figure out how to make an explodable target ( A very simple task ). I finally gave up in frustration.  I managed to find one engine that is alot easier to understand than most, but I keep coming back to Phrogram because of it's ease of use.

IMO, basics > features. Even without a system method that calculates the hyperbolic cosine of a number, you can probably google it and find an algorithm that would be easily adaptable using Phrogram's basic operators ( +  -  *  / )...

The Dragon Rider:

IMO, basics > features. Even without a system method that calculates the hyperbolic cosine of a number, you can probably google it and find an algorithm that would be easily adaptable using Phrogram's basic operators ( +  -  *  / )...

You guys are not exaclty what I would call beginner programmers...

KPL and Phrogram have allowed many beginners to get going without the concept of include so its not something that is a basic/essential feature like addtion and substraction.

I admit I'm playing a little devils advocate here to get some response and critical thinking of the features... I do think we will have something to help solve these problems in future versions of Phrogram. I just want to make sure we are solving a problem rather than copying a feature.

I didn't know about the IDE slowing down for large files - thats something that we might be able to deal with ahead of a feature.

As for switches that take you between beginner/intermediate/expert - I know this is something Jon had thought about and there was some research into other languages that had done it. I'll see if I can get him to share an opinion.

This is a very useful discussion - note it's really a product design brainstorming session.  Let's keep it going.  Several thoughts:

As Andy said, if very large files cause problems with the IDE's performance, there may be performance optimizations we can do to fix that problem, without supporting multiple files.  In fact, if it's compiler / code processing issues, pushing the code into multiple files might not fix the problem. 

I am inclined to agree that we want to support hobbyists as well as beginners - which is what Larry is getting at.  That's a business-level decision about the product that needs a lot of thought and discussion, since obviously advanced hobbyists like you guys are not the initial optimum target user we built KPL and Phrogram for.

I like the idea, generally, of pushing some additional features implemented for advanced hobbyists behind the "Advanced" switch for the IDE - including possible library or language features.  But I'm not agreeing with any particular feature yet!  :)

Note that if we do that, we need to think carefully about the user experience - including clear error handling or messaging around the features if, for instance, a basic IDE opens a file written in the advanced version.

I don't think anyone has mentioned this idea yet, so let me put it out there - how about we allow a Phrogram file to be compiled down to a DLL, a class library like the ones that are already used in the IDE, and then when referenced that DLL is available to a code file in the IDE in the same way as the current libraries are?  This has the advantage of being something that could easily fit into the IDE as an "Advanced" menu choice - and would be both very educational and very flexible.  It does add a dependency on the compiled DLL, yes.  It also seems like it might be easier to implement than multi-file handling, source code libraries, etc...

JonS:

I don't think anyone has mentioned this idea yet, so let me put it out there - how about we allow a Phrogram file to be compiled down to a DLL, a class library like the ones that are already used in the IDE, and then when referenced that DLL is available to a code file in the IDE in the same way as the current libraries are?  This has the advantage of being something that could easily fit into the IDE as an "Advanced" menu choice - and would be both very educational and very flexible.  It does add a dependency on the compiled DLL, yes.  It also seems like it might be easier to implement than multi-file handling, source code libraries, etc...

I agree, that would be very useful and flexible, but...

1. A DLL would not be modifiable inside of Phrogram, so the user would not be able to fix any mistakes/errors in the file that the creator may have missed.
   
2. The user would not be able to see visually what the creator does to achieve an effect, such as calculating the hyperbolic cosine of a number. In a DLL, the source would be unavailable to see and learn from.
3. It adds an extra step. The exact same effect is possible using the humble KPL file.