What Makes A Programming Language Good

[Jesse Phillips]

Jim Wrote:

> Jesse Phillips Wrote:
> > > It makes everything much clearer and creates a bunch of opportunities for further development.
> > 
> > I don't see such benefit.
> 
> It's easier for the programmer to find the module if it shares the name with the file. Especially true when faced with other people's code, or code that's more than 6 months old, or just large projects. The same goes for packages and directories. The relationship is clear: each file defines a module. The natural thing would be to have them bear the same name.

Like I sad, I haven't seen this as an issue. People don't go around naming their files completely different from module name. There are just too many benefits to do it otherwise, I believe the include path makes use of this. 


> It lets the compiler traverse dependencies by itself. This is good for the following reasons:
> 1) You don't need build tools, makefiles. Just "dmd myApp.d". Do you know how many build tools there are, each trying to do the same thing. They are at disadvantage to the compiler because the compiler can do conditional compiling and generally understands the code better than other programs. There's also extra work involved in keeping makefiles current. They are just like header files are for C/C++ -- an old solution.

This is what the "Open Scalable Language Toolchains" talk is about
http://vimeo.com/16069687

The idea is that the compile has the job of compiling the program and providing information about the program to allow other tools to make use of the information without their own lex/parser/analysis work. Meaning the compile should not have an advantage.

Lastly Walter has completely different reasons for not wanting to have "auto find" in the compiler. It will become yet another magic black box that will still confuse people when it fails.

> 2) The compiler can do more optimisation, inlining, reduction and refactoring. The compiler also knows which code interacts with other code and can use that information for cache-specific optimisations. Vladimir suggested it would open the door to new language features (like virtual templated methods). Generally I think it would be good for templates, mixins and the like. In the TDPL book Andrei makes hints about future AST-introspection functionality. Surely access to the source would benefit from this.

No, you do not get optimization benefits from how the files are stored on the disk. What Vladimir was talking about was the restriction that compilation unit was the module. DMD already provides many of these benefits if you just list all the files you want compiled on the command line.

> It would simplify error messages now caused by the linker. Names within a program wouldn't need to be mangled. More information about the caller / callee would also be available at the point of error.

Nope, because the module you are looking for could be in a library somewhere, and if you forget to point the linker to it, you'll still get linker errors.

> It would also be of great help to third-party developers. Static code analysers (for performance, correctness, bugs, documentation etc), packet managers... They could all benefit from the simpler structure. They wouldn't have to guess what code is used or built (by matching names themselves or trying to interpret makefiles).

As I said, have all these tools assume such a structure. If people aren't already using the layout, they will if they want to use these tools. I believe that is how using the import path already works in dmd.

> It would be easier for novices. The simpler it is to build a program the better. It could be good for the community of D programmers. Download some code and it would fit right in. Naming is a little bit of a Wild West now. Standardised naming makes it easier to sort, structure and reuse code.

rdmd is distributed with the compiler... do you have examples of poorly chosen module names, which have caused issue?

> > Right, using such tools is great. But what if you are like me and don't have a dev environment set up for Phobos, but I want to fix some module? Do I have to setup such an environment or through the file in a folder std/ just do some work on it?
> 
> You have compilers, linkers and editors but no version control system? They are generally very easy to install and use. When you have used one for a while you wonder how you ever got along without it before. In git for example, creating a feature branch is one command (or two clicks with a gui). There you can tinker and experiment all you want without causing any trouble with other branches. I usually create a new branch for every new feature. I do some coding on one, switch to another branch and fix something else. They are completely separate. When they are done you merge them into your mainline.

No no no, having git installed on the system is completely different from have a dev environment for Phobos. You'd have to download all the Phobos files and Druntime into their proper location and any other dependencies/issues you run into when you try and build it. Then you would need a dmd installation which used your custom test build of Phobos.