On 1/14/2013 10:30 PM, Rob T wrote:
> A really important advantage that scripting languages provides that D does not
> currently provide, is direct runtime interpretation of the language. This is
> very important for the use cases of script languages such as Ruby and PHP,
> because often they are used for coding and testing on the fly, ie., used in an
> environment that requires frequent changes with almost instant feedback.

The way this is currently done is to put the code that would otherwise be in a script into a DLL, and then the dev process becomes:

1. run program
2. dynamically load DLL with "script"
3. debug
4. change "script" code
5. recompile "script" into new DLL
6. reload DLL
7. rinse, repeat

It turns out that step 5 is nearly instant, on the order of a few seconds.

The hair in the process, however, is DLLs still need better support in D.

> You can also embed a scripting language directly into other applications, and
> store "code" as data, which can be transmitted from one machine to another over
> the wire. We can store and transmit D code too, but getting it to automatically
> run on the other end is not so easy or convenient.

Just so you know, we have a Javascript engine written in D, meaning you can embed Javascript.

On 1/15/2013 4:09 AM, bearophile wrote:
> One common indentation-related bug is caused by relying on the indentation to
> understand code, while the curly brace language compiler ignores what you were
> seeing and only sees the braces. I have seen many cases of delayed code
> understanding caused by that. Making the syntax more DRY (this means stating the
> logical indentation using only one communication channel) helps avoid those
> mistakes (and reduces the visual noise, further helping code readability).

This is the job of a syntax aware editor (and other source code formatting tools), not the language. In my not-so-humble opinion.

BTW, I'd like to see a source code formatter for D. Anyone want to step up?

On 1/15/2013 8:37 AM, Paulo Pinto wrote:
> Then I started working in multi-site projects with developers from all types of
> backgrounds, and understood the value of a consistent project code formatting.

I agree with the value as you say, but as I posted previously I think consistent formatting is the job of a source code formatter, not the language.

> class:
>     def:
>         for:
>             if:
>
> You could call it "south west" code.
>

Recte: South east code, of course!

> Then I started working in multi-site projects with developers from all types of backgrounds, and understood the value of a consistent project code formatting.
>
> --
> Paulo

In most languages, there are coding conventions, and projects should have consistent formatting. I agree. However, I think indentation as part of the syntax is highly exaggerated. A language can and should protect programmers from making stupid or common mistakes and offer features that make programming more efficient and software more reliable. To enforce a certain aesthetic style, based on personal preferences more often than not, should not be part of the language, but up to the teams that use the language. On top of that, Python code can be messy too (although it might look "nice"). In _my_ experience, readability is often impeded by the use of obscure variable and function names.

v = r.calc(m.get_p() / m.get_r())

What is "v", what is calc() calculating ...?

Such code can be due to laziness or arrogance. But no language feature can prevent bad or lazy programmers from producing such code, even if it's nicely formatted.

Anyway, 1,000 programmers will have 1,001 views on coding style.

On Tuesday, 15 January 2013 at 20:07:49 UTC, Walter Bright wrote:
> On 1/15/2013 8:37 AM, Paulo Pinto wrote:
>> Then I started working in multi-site projects with developers from all types of
>> backgrounds, and understood the value of a consistent project code formatting.
>
> I agree with the value as you say, but as I posted previously I think consistent formatting is the job of a source code formatter, not the language.

Sure, I was speaking in general.

Even better, have some kind of indent tool run as part of the
check-in process.

On Tuesday, 15 January 2013 at 20:02:58 UTC, Walter Bright wrote:
> On 1/14/2013 10:30 PM, Rob T wrote:
>> A really important advantage that scripting languages provides that D does not
>> currently provide, is direct runtime interpretation of the language. This is
>> very important for the use cases of script languages such as Ruby and PHP,
>> because often they are used for coding and testing on the fly, ie., used in an
>> environment that requires frequent changes with almost instant feedback.
>
> The way this is currently done is to put the code that would otherwise be in a script into a DLL, and then the dev process becomes:
>
> 1. run program
> 2. dynamically load DLL with "script"
> 3. debug
> 4. change "script" code
> 5. recompile "script" into new DLL
> 6. reload DLL
> 7. rinse, repeat
>
> It turns out that step 5 is nearly instant, on the order of a few seconds.

Doing that is still more difficult in terms of technical skills. Also even when you have the skills, you need more access to perform code modifications remotely. Often too, you do not want to take down the entire application to make a quick fix to some bad code.

I think fully scripted languages appeal to the less technically inclined who prefer to "just get it done" with the least amount of hassle.

I'll suggest that the gap can be filled between scripted and compiled in a way that may get some serious attention. The rapid development process of a scripted language loses its advantage the minute the code stabilizes because at the point of stability, the interpretation process becomes a burden on resources without any advantages. If the stable scripted code can be compiled and linked in, then it gains the advantages of a compiled language.

This is an important point, because companies with large server farms are aware that they are paying far more money for processing power than they need to because their servers are running scripted code most of the time. For example, Twitter moved from Ruby to Java to gain performance, so imagine what they could get if they moved to something like D instead.

> The hair in the process, however, is DLLs still need better support in D.

Yes, having full DLL support will help, and I cannot wait for that support.

When we say "DLL" that usually means Microsoft's implementation of dynamic linking, but we need support for Linux too. Also please do not overlook the importance of dynamically loaded libraries (loaded during runtime) for implementing loadable plugins giving you extensibility options like what you see with Firefox and other popular applications. Once D has plugin support, I'll be very happy.

>> You can also embed a scripting language directly into other applications, and
>> store "code" as data, which can be transmitted from one machine to another over
>> the wire. We can store and transmit D code too, but getting it to automatically
>> run on the other end is not so easy or convenient.
>
> Just so you know, we have a Javascript engine written in D, meaning you can embed Javascript.

I knew about it, but I read somewhere that it was not fully compatible with the version of JS that is being used for web related work, is this correct? Still, it can be useful to have a look at it to see how it does its job.

I wonder if the work on the CTFE can be somehow spun off into an embeddable D interpreter?

--rt

On Tuesday, 15 January 2013 at 10:22:20 UTC, Chris wrote:
>> A language such as C++ seems like a bad fit for a scripting language because of it's complexity and the difficultly with parsing through it. Also a scripted language probably should not have low level access that is provided by languages such as D and C/C++.
>>
>> --rt
>
> Why not? In my experience small scripts often turn into bigger programs and sooner or later you need some sort of low level features. Then you have to write modules in C/C++ and use Swig or something to integrate them. That's why I prefer D, because you can get the whole shebang _if necessary_. There are also copyright issues. If you deliver a Python program, anyone could rip it, even if you compile it to byte code. If you distribute native executables, it's harder to rip your program. In general, I find scripting languages less useful for projects that (might) develop into something bigger. Now that I come to think of it, scripting languages are inherently "quick and dirty", that's why they are not really scalable (think of the class system in Python and Lua, not the real deal).

For many applications where a scripted language really shines, there are usually security related issues that require placing strict limitations on what the scripts are allowed to do. You have to understand that the scripts tend to be implemented by the users of the system, rather than just the original developers. Also code may be transmitted from one machine to another and executed, so you have to be careful that malicious code cannot do much harm.

I agree with your comment about larger projects that are scripted. I think you'll tend to use large applications like that in environments where the scripting provides little to no advantages, and it becomes mostly a disadvantage in terms of eating up resources for no good reason. I can see an advantage for the developers, but the users of the application tends to suffer, so if the application could later be compiled to native machine code for distribution, that would close the gap.

--rt

>
> For many applications where a scripted language really shines, there are usually security related issues that require placing strict limitations on what the scripts are allowed to do. You have to understand that the scripts tend to be implemented by the users of the system, rather than just the original developers. Also code may be transmitted from one machine to another and executed, so you have to be careful that malicious code cannot do much harm.

> I agree with your comment about larger projects that are scripted. I think you'll tend to use large applications like that in environments where the scripting provides little to no advantages, and it becomes mostly a disadvantage in terms of eating up resources for no good reason. I can see an advantage for the developers, but the users of the application tends to suffer, so if the application could later be compiled to native machine code for distribution, that would close the gap.
>
> --rt

But scripting languages still can do a lot of harm, even if they are not as low level as C/C++ or D. But transmission is actually an issue. Scripting languages are better for this purpose. My point is that developers should think twice before using scripting languages, because the disadvantages may sooner or later outweigh the initial advantage of "ease of use" and "no compilation time". A lot of cross-platform software is still written in C and C++, not without a reason. What D can offer here is modern (scripting like) convenience plus cross platform native machine code.

On Tue, 15 Jan 2013 20:06:05 -0000, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/15/2013 4:09 AM, bearophile wrote:
>> One common indentation-related bug is caused by relying on the indentation to
>> understand code, while the curly brace language compiler ignores what you were
>> seeing and only sees the braces. I have seen many cases of delayed code
>> understanding caused by that. Making the syntax more DRY (this means stating the
>> logical indentation using only one communication channel) helps avoid those
>> mistakes (and reduces the visual noise, further helping code readability).
>
> This is the job of a syntax aware editor (and other source code formatting tools), not the language. In my not-so-humble opinion.
>
> BTW, I'd like to see a source code formatter for D. Anyone want to step up?

In an ideal world the source code would be stored in file on disk in some "standard" format, and displayed in each programmers editor in their own preferred format.  It could end all arguments about code formatting, for good.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, 16 January 2013 at 10:59:46 UTC, Regan Heath wrote:
> In an ideal world the source code would be stored in file on disk in some "standard" format, and displayed in each programmers editor in their own preferred format.  It could end all arguments about code formatting, for good.
>
> R

It is partially achievable now with IDE's auto-formatting tools and git commit hooks. Not on disk, of course, but repo is more relevant.