Nick Sabalausky:

> I'm not sure that's valid outside a function, though.

It doesn't work outside functions. More info:
http://d.puremagic.com/issues/show_bug.cgi?id=4085

Bye,
bearophile

On 29-04-2012 08:40, Paulo Pinto wrote:
> Am 28.04.2012 22:59, schrieb q66:
>> On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
>>> On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
>>>> On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:
>>>>
>>>> There are minimalistic languages that don't add too much complexity,
>>>> instead it results in code being kept simple.
>>>
>>> I appreciate minimalistic languages. I love the simplicity of Scheme
>>> and the design of Lua. Lua and Python are extensible language, but
>>> truth be told, they cannot handle large scale programming. In fact, I
>>> don't know of any minimalistic language that can scale from hundreds
>>> of thousands to millions of lines of code. When you reach these sizes,
>>> their simple design becomes a drawback. You start missing lots of
>>> features. When you reach large scale programming, you want really
>>> powerful tools.
>>>
>>> That's basically what the Java designers discovered after experience.
>>> The original language was simple and easy, but that simplicity
>>> translated into way too much boilerplate code. So they kept adding
>>> features from version to version, generics, then annotations, a means
>>> to create new keywords. And now they would like to add delegates.
>>> These are all needed in large programs.
>>>
>>>> D needs to do something it does really well and concentrate on that.
>>>> Otherwise the language will remain being rather vague and doing "a
>>>> bit of everything, but nothing truly well".
>>>>
>>>
>>> It does a lot of things well already. Our point of comparison should
>>> not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e
>>> languages that are designed to develop large systems.
>>>
>>> But most of all it needs to stabilize and polish, not change all the
>>> time. I think its feature set is very good already.
>>> We are far from having explored all its possibilities.
>>>
>>>> Instead of adding more and more features into a rigid language, it
>>>> needs to be made more flexible and extensible, both syntactically and
>>>> semantically.
>>
>> This kind of attitude "we need big fat bullshit like Java and heavy use
>> of OO and idioms and EH and all that other crap" is broken and false.
>> And you have no way to prove that Python for example wouldn't scale for
>> large projects; its main fault is that the default implementation is
>> rather slow, but it's not pretty much missing anything required for a
>> large project.
>>
>
> Python is my favorite scripting language, but I would never propose a
> dynamic language for programming on the large.
>
> My employer does consulting for big projects. The type of entreprise
> projects that require multi-site development scattered across the globe,
> sometimes with 300+ developers.
>
> There is no way a dynamic language would work in such scenarios, without
> having a constant broken build on the CI system.
>
> --
> Paulo

Wait, dynamic-language programmers use CI?

*ducks and runs*

-- 
- Alex

Am 29.04.2012 20:08, schrieb Manu:
> On 29 April 2012 18:50, Don <nospam@nospam.com
> [...]
>     * package. I have no idea how a failed Java experiment got
>     incorporated into D.
>
>
> package confuses me, it's poorly documented. What are the protections
> between packages, sub-packages. Can parent packages see sub-package
> contents? vice-versa?

I've always assume that package is similar to what is available in another module based languages.

Where you have a library (package) that is composed of several separated
modules.

In certain scenarios, you want to have symbols that are private to the
library, but need to be marked public so that each module, that is part
of the library, is able to see them. So you mark those symbols as package level access.

This is usually done in "programming in the large" projects.

Some examples where I think this concept might be visible,

- .NET Modules (internal is used for visibility accross .dll)
- default package access for Java common namespaces scattered across several jar files
- Ada limited and child packages
- Delphi packages

--
Paulo

On 28-04-2012 23:18, SomeDude wrote:
> On Saturday, 28 April 2012 at 21:05:12 UTC, q66 wrote:
>> On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
>>> On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
>>> [...]
>>>> - AAs integrated in the language; you barely ever use AA literals and
>>>> having them purely in Phobos would help get rid of the runtime fat, as
>>>> well as better implementations
>>>
>>> On the contrary, AA's are a major reason I started programming in D. In
>>> this day and age, it's simply inexcusable to *not* have some kind of
>>> hash type available by default.
>>>
>>
>> Besides AA literals, library can handle this JUST FINE.
>>
>
> Yeah, but core language AA are so useful it would be a MAJOR mistake to
> remove them. In Python too, you could put the AA in the libraries. Yet
> everybody uses the AA that are in the language.
>
> Where I DO agree with you is, Phobos should be a two level library, i.e
> a minimalistic library, with about the same feature set as the standard
> C library + multithreading, and a superset with the full range of
> features (ranges, algorithms, etc). I've already advocated it somewhere
> else.

Let's get a standard package manager that we either advocate on dlang.org or include in the releases before we start talking about reducing the amount of modules in Phobos.

-- 
- Alex

On 28-04-2012 23:41, Timon Gehr wrote:
> On 04/28/2012 11:05 PM, q66 wrote:
>> On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
>>> On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
>>> [...]
>>>> - AAs integrated in the language; you barely ever use AA literals and
>>>> having them purely in Phobos would help get rid of the runtime fat, as
>>>> well as better implementations
>>>
>>> On the contrary, AA's are a major reason I started programming in D. In
>>> this day and age, it's simply inexcusable to *not* have some kind of
>>> hash type available by default.
>>>
>>
>> Besides AA literals, library can handle this JUST FINE.
>>
>
> That is why they should be a narrow wrapper around a library defined type.
>
>>>
>>>> - Phobos is too fat - it needs to shrink to just a few core modules,
>>>> others being distributed via some system like CPAN for Perl
>>>
>>> Um... that's what a *library* is supposed to be: a large collection of
>>> useful stuff from which you can pick the few that you need right now.
>>>
>>
>> Too large collection becomes too hard to manage. Separating it and
>> distributing in style "you pay for what you use" is IMO the right
>> approach.
>>
>
> This sounds reasonable.
>
>>>
>>>> - Properties - they're kinda broken at this point and the value is
>>>> questionable
>>>
>>> What kind of properties are you referring to?
>>>
>>
>> The @property crap. It's broken. If anything, it needs something like in
>> C#.
>>
>
> As I understand it, the 'agreed upon' design is that
>
> @property int foo() { return x; }
> @property void foo(int v) { x = v; }
>
> Would be completely equivalent to C#:
>
> int foo { set{ x = value; }; get{ return x; } }

Nope.

First of all, you'd have to declare the setter like this in D:

@property int foo(int v) { return x = v; }

so that you can write:

int v = obj.foo = 1; // valid C#

Next up is the issue of op-assign operations. In D, you can't do:

obj.foo += 1;
obj.foo++;

while in C#, you can (it results in a get -> add 1 -> set and get -> inc -> set, etc).

>
> I think it is even perfectly fine to just allow function calls without
> parentheses, but I wouldn't mind seeing that feature gone.
>
>>>
>>>> - @trusted @system
>>>
>>> These are necessary.
>>>
>>
>> They're far from necessary.
>>
>
> Why? Memory safety is generally considered to be important.
>
>>>
>>>> - Exception handling - a lot of runtime, questionable value
>>>
>>> I completely disagree. No exception handling means lots and lots and
>>> lots of boilerplate code for checking error codes, return values, which
>>> are too tedious to write, which translates to many people leaving them
>>> out and ending up with unreliable code that fail silently or crash
>>> outright when a function call they assumed would work stopped working.
>>>
>>> If you've worked in large multi-person projects, you'll see very quickly
>>> why you *need* exception handling. No modern language can do without
>>> exception handling. Maybe you have a beef with how it's currently done
>>> in D, but regardless, you *need* exception handling of some kind.
>>>
>>
>> The exception handling system via try/catch is as bad and tedious as
>> error codes, except the added runtime.
>
> It can improve performance though, because the exceptional branches
> don't occur in the code that is normally executed.
>
>> It all roots from the idea "catch everything that throws".
>> This is broken, as you DON'T always need to
>> handle all sorts of errors (letting it segfault or something sometimes
>> simply proves to be better than trying to save the situation;
>
> Except that it won't necessarily segfault.
>
> That is not how _reliable_ systems work. Robustness is an important
> property of critical systems. If your software might kill people if it
> behaves in the wrong way, you really really don't want to ignore error
> conditions.
>
>> or you can simply assert it).
>
> Certainly, if it is a consistency criterion internal to the program,
> then assertions should be used.
>
>> Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
>> [snip.]
>
> The part of this article relevant for D is this:
>
> "Still, in many cases, the benefits of exceptions are more important
> than their problems. For example, if your language manages memory
> automatically, the problem of releasing acquired resources becomes a
> small one (you only have to care about files, etc., which are a tiny
> part of the "resources" used by a program - most of the "resources" are
> memory). If your language throws exceptions when you violate its rules
> (for example, upon out-of-bounds array access), these exceptions will
> help you find lots of bugs, especially if you can get the call stack
> from an exception. If the purpose of an application is automated
> testing, and/or it's used as a quick-and-dirty internal tool as opposed
> to a product for an end user, this kind of exceptions is all you need to
> handle errors of almost all kinds. In some languages, you can even
> resume the execution from the point where the exception was raised after
> fixing the problem at the point where it was caught."
>
> Anyway, I generally avoid exceptions if they are not an obvious fit.
>


-- 
- Alex

On 28-04-2012 21:36, Andrej Mitrovic wrote:
> On 4/28/12, Walter Bright<newshound2@digitalmars.com>  wrote:
>> What's your list?
>
> I don't mind extra features, just as long as they're properly
> documented and implemented. For example, I have absolutely no uses for
> anonymous classes right now, but I know DWT2 uses them and probably
> other people do use them.

I use them too. They're useful if you have an abstract method that just needs to return an arbitrary object implementing some interface or whatever.

>
> Personally I find the hardest threads to to follow are the ones
> discussing in/out/inout/autoref. For one thing there are compiler
> bugs, but then there are misconceptions between what developers vs
> documentation vs core devs say about them. And then you mix in classes
> and templates into the story and it all becomes a large forest of
> information that is very hard to digest.
>
> Another feature I'm curious about is .dup/.idup. It's basically
> hardcoded for a couple of types, but why not instead use UFCS and
> implement .dup/.idup in std.array as a free function? Then you might
> even use it for user-types by requiring a type to implement .dup/.idup
> functions.

This seems reasonable to me.

>
> Also there's mixin templates. What exactly is the difference between
> mixin templates and regular templates? We can use the mixin statement
> for both types right now, so there doesn't seem to be a distinction.
> For example, if you take samples from the template mixin page
> (http://dlang.org/template-mixin.html) and you remove "mixin" from the
> template declaration, all of the samples will continue to work. You
> could remove this declaration feature right now and you probably
> wouldn't break any code at all. Seems like low-hanging fruit to me.


-- 
- Alex

On 28-04-2012 22:43, Timon Gehr wrote:
> On 04/28/2012 09:58 PM, foobar wrote:
>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>>> Andrei and I had a fun discussion last night about this question. The
>>> idea was which features in D are redundant and/or do not add
>>> significant value?
>>>
>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>> and creal types.
>>>
>>> What's your list?
>>
>> D has a lot of ad-hock features which make the language
>> needlessly large and complex. I'd strive to replace these with
>> better general purpose mechanisms.
>>
>> My list:
>> * I'd start with getting rid of foreach completely. (not just
>> foreach_reverse).
>
>
> foreach is very useful. Have you actually used D?

Removing it would be craziness.

>
>> This is nothing more than a fancy function with
>> a delegate parameter.
>>
>
> That would be opApply.
>
>> * enum - enum should be completely redesigned to only implement
>> what it's named after: enumerations.
>>
>
> What is the benefit?
>
>> * version - this does not belong in a programming language. Git
>> is a much better solution.
>>
>
> So you'd maintain a git branch for every OS if there is some small part
> that is OS-dependent? I don't think that is a better approach at all.

That is absolutely horrible. It's not how branches are meant to be used.

>
>> * di files - a library should encapsulate all the info required
>> to use it. Java Jars, .Net assemblies and even old school; Pascal
>> units all solved this long ago.
>>
>> * This is a big one: get rid of *all* current compile time
>> special syntax.
>
> What would that be exactly?
>
>> It should be replaced by a standard compilation
>> API and the compiler should be able to use plugins/addons.
>
> Are you serious?
>
>> This would reduce the size of the language to half of its current
>> size, maybe even more.
>
> I am certain that it would not.
>
>
> You missed to present the 'general purpose mechanisms'.


-- 
- Alex

On 29-04-2012 01:25, foobar wrote:
> On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
>> On 04/28/2012 09:58 PM, foobar wrote:
>>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>>>> Andrei and I had a fun discussion last night about this question. The
>>>> idea was which features in D are redundant and/or do not add
>>>> significant value?
>>>>
>>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>>> and creal types.
>>>>
>>>> What's your list?
>>>
>>> D has a lot of ad-hock features which make the language
>>> needlessly large and complex. I'd strive to replace these with
>>> better general purpose mechanisms.
>>>
>>> My list:
>>> * I'd start with getting rid of foreach completely. (not just
>>> foreach_reverse).
>>
>>
>> foreach is very useful. Have you actually used D?
>>
>
> I have used D and didn't claim that foreach isn't useful.
> What I said that is that it belongs in the library, NOT the language.

Yeah, we tried that in C++. It sucked.

The reason it works for many functional languages is that they have even more terse syntax than D. It would suck to make foreach a function in D.

>
>>> This is nothing more than a fancy function with
>>> a delegate parameter.
>>>
>>
>> That would be opApply.
>
> Indeed but I'd go even further by integrating it with ranges so that
> ranges would provide an opApply like method e.g.
> auto r = BinaryTree!T.preOrder(); // returns range
> r.each( (T elem) { ...use elem...}); // each method a-la Ruby
>
>>
>>> * enum - enum should be completely redesigned to only implement
>>> what it's named after: enumerations.
>>>
>>
>> What is the benefit?
>
> On the one hand the current enum for manifest constants is a hack due to
> weaknesses of the toolchain and on the other hand it doesn't provide
> properly encapsulated enums such as for instance the Java 5.0 ones or
> the functional kind.
>
>>
>>> * version - this does not belong in a programming language. Git
>>> is a much better solution.
>>>
>>
>> So you'd maintain a git branch for every OS if there is some small
>> part that is OS-dependent? I don't think that is a better approach at
>> all.
>
> It is far better than having a pile of #ifdef styled spaghetti code.
> I'd expect to have all the OS specific code encapsulated separately anyway,
> not spread around the code base. Which is the current recommended way of
> using
> versions anyway. The inevitable conclusion would be to either use a
> version management system like git or have separate implementation
> modules for platform specific code and use the build tool to implement
> the logic of select the modules to include in the build.

Yeah, we tried that in C and C++. It sucked. See: Autotools.

>
>>
>>> * di files - a library should encapsulate all the info required
>>> to use it. Java Jars, .Net assemblies and even old school; Pascal
>>> units all solved this long ago.
>>>
>>> * This is a big one: get rid of *all* current compile time
>>> special syntax.
>>
>> What would that be exactly?
>
> This includes __traits, templates, static ifs, etc..
>
>>
>>> It should be replaced by a standard compilation
>>> API and the compiler should be able to use plugins/addons.
>>
>> Are you serious?
>
> No I'm joking.
>
> The current system is a pile of hacks on top of the broken model of c++
> templates.
>
> I should be able to use a *very* minimalistic system to write completely
> _regular_ D code and run it at different times. This is a simple matter
> of separation of concerns: what we want to execute (what code) is
> separate to the concern of when we want to execute it.
>
>
>>
>>> This would reduce the size of the language to half of its current
>>> size, maybe even more.
>>
>> I am certain that it would not.
>>
>>
>> You missed to present the 'general purpose mechanisms'.


-- 
- Alex

On 29-04-2012 01:49, SomeDude wrote:
> On Saturday, 28 April 2012 at 23:25:10 UTC, foobar wrote:
>> On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
>>> On 04/28/2012 09:58 PM, foobar wrote:
>>>> On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
>>>>> Andrei and I had a fun discussion last night about this question. The
>>>>> idea was which features in D are redundant and/or do not add
>>>>> significant value?
>>>>>
>>>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>>>> and creal types.
>>>>>
>>>>> What's your list?
>>>>
>>>> D has a lot of ad-hock features which make the language
>>>> needlessly large and complex. I'd strive to replace these with
>>>> better general purpose mechanisms.
>>>>
>>>> My list:
>>>> * I'd start with getting rid of foreach completely. (not just
>>>> foreach_reverse).
>>>
>>>
>>> foreach is very useful. Have you actually used D?
>>>
>>
>> I have used D and didn't claim that foreach isn't useful.
>> What I said that is that it belongs in the library, NOT the language.
>>
>
> Well, it's your opinion. But I bet it's not the opinion of thousands of
> programmers, it's not the opinion of the Java/C# designers, and I even
> believe they wanted to add foreach in C++ (or is it already the case ?).
> Putting things in the library isn't the solution for everything: it's
> often hard (if possible) to make it work as well as in the core
> language, and error messages are usually more cryptic. Basic features
> like this should stay in the core language in my opinion.

C++11 has range-based for (which is basically foreach).

>
>>>> This is nothing more than a fancy function with
>>>> a delegate parameter.
>>>>
>>>
>>> That would be opApply.
>>
>> Indeed but I'd go even further by integrating it with ranges so that
>> ranges would provide an opApply like method e.g.
>> auto r = BinaryTree!T.preOrder(); // returns range
>> r.each( (T elem) { ...use elem...}); // each method a-la Ruby
>>
>>>
>>>> * enum - enum should be completely redesigned to only implement
>>>> what it's named after: enumerations.
>>>>
>>>
>>> What is the benefit?
>>
>> On the one hand the current enum for manifest constants is a hack due
>> to weaknesses of the toolchain and on the other hand it doesn't
>> provide properly encapsulated enums such as for instance the Java 5.0
>> ones or the functional kind.
>>
>>>
>>>> * version - this does not belong in a programming language. Git
>>>> is a much better solution.
>>>>
>>>
>>> So you'd maintain a git branch for every OS if there is some small
>>> part that is OS-dependent? I don't think that is a better approach at
>>> all.
>>
>> It is far better than having a pile of #ifdef styled spaghetti code.
>> I'd expect to have all the OS specific code encapsulated separately
>> anyway,
>> not spread around the code base. Which is the current recommended way
>> of using
>> versions anyway. The inevitable conclusion would be to either use a
>> version management system like git or have separate implementation
>> modules for platform specific code and use the build tool to implement
>> the logic of select the modules to include in the build.
>>
>
> No it isn't. Ask the kernel hackers why they still use #ifdef instead of
> using hundreds of git branches for every feature and platform they must
> maintain.
>
>>>
>>>> * di files - a library should encapsulate all the info required
>>>> to use it. Java Jars, .Net assemblies and even old school; Pascal
>>>> units all solved this long ago.
>>>>
>>>> * This is a big one: get rid of *all* current compile time
>>>> special syntax.
>>>
>>> What would that be exactly?
>>
>> This includes __traits, templates, static ifs, etc..
>>
>>>
>>>> It should be replaced by a standard compilation
>>>> API and the compiler should be able to use plugins/addons.
>>>
>>> Are you serious?
>>
>> No I'm joking.
>>
>> The current system is a pile of hacks on top of the broken model of
>> c++ templates.
>>
>> I should be able to use a *very* minimalistic system to write
>> completely _regular_ D code and run it at different times. This is a
>> simple matter of separation of concerns: what we want to execute (what
>> code) is separate to the concern of when we want to execute it.
>>
>>
>>>
>>>> This would reduce the size of the language to half of its current
>>>> size, maybe even more.
>>>
>>> I am certain that it would not.
>>>
>>>
>>> You missed to present the 'general purpose mechanisms'.
>
>
> You should use Go. It fits better to your views about programming
> languages than D.
>


-- 
- Alex

On 4/29/12, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> Next up is the issue of op-assign operations. In D, you can't do:
>
> obj.foo += 1;
> obj.foo++;
>
> while in C#, you can (it results in a get -> add 1 -> set and get -> inc
> -> set, etc).

It's great to see another (successful) language implemented this. Do we have a proposal open for this somewhere?