"Marco Leise" <Marco.Leise@gmx.de> wrote in message news:20120429075404.121a5a46@marco-leise...
>
> I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly.
>

Yea, it's a tradeoff either way. Once we have a mature "D CPAN", there will be less reason to pack things into Phobos. But until that actually happens, a "batteries included"-style std lib is necessary. And of course, like you say, there are likely things that just aren't appropriate for the std lib either way.

"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:sxzgfzztxfvsstwrqdiu@forum.dlang.org...
> On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
>> On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
>>> On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
>>
>> So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?
>
> Sorry, with that, I agree. Nick Sabalausky proposed to remove version
> entirely.
> But I agree there could be something like:
> version(LINUX|OSX){
> ...
> } else {
> ...
> }

FWIW, one of the big wins I see in migrating "version" to "static if" is switching from the clumbsy "defined/undefined" model to a model of "true/false, undefined is an error". The current "undefined is not an error" stuff is just so...ActionScript 2.

>> My list:
>> * I'd start with getting rid of foreach completely. (not just foreach_reverse).

> C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it).
>
> Obviously somehow you want to go into the opposite direction. Beats me.

 If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it?

 Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on.

Am 28.04.2012 20:47, schrieb Walter Bright:
> 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?

- two different ways of creating function pointers is confusing (function and delegate)

 I understand the reasoning, but makes one think all the time when
to use what.

- sometimes D code looks like template and mixins gone mad
 While I do appreciate the power, it can be quite confusing to try
 to understand what the code does. Specially with the lack of support
 in mixin's debugging

- __traits should be given a proper name
  It looks out of place in regard with the rest of the language, by making use of the underscores

- AA should be a library type
  I am on the C++ and Scala camp where the language should be extendable via the library

- misuse of enum to declare constants
  I prefer that the use of const would be possible

- conditional compilation is hard to follow without syntax highlighting
  Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada

- unit tests
  I would rather have them as a library.

While it is fun to discuss what we like and not like, I vote that priority should be given to make the language stable and have better tooling.

We need to have safer languages with native code generation for systems programming in the mainstream OS, that take us away from the buffer overflow exploits and dagling pointers legacy that C and C++ brought upon us.

Someone that does not know D and sees the amount of bugs still existing,
or this type of discussions, will run away to Go or some future version of C#/Spec#/Bartok, or back to whatever he/she was using before.

I don't agree D is complex, any language that aims to be used in large
application domains, needs a certain set of abstractions. If it does not
support them, it is condemmend to keep getting new features until it turns in what the language designers were fighting against.

--
Paulo

"Timon Gehr" <timon.gehr@gmx.ch> wrote in message news:jnhpvv$ih4$1@digitalmars.com...
> On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
>>
>> But how about:
>> alias thing = runSomeCtfe();
>>
>
> That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D:
>
> enum Foo{
>     member1,
>     member2,
>     member3,
> }
>
> => (allow non-integral enumerations)
>
> enum Foo{
>     member1 = "1",
>     member2 = "2",
>     member3 = "3",
> }
>

Those are good. They are essentially enumerations.

> => (anonymous enums)
>
> enum{
>     member1 = "1",
>     member2 = "2",
>     member3 = "3",
> }
>

I don't think "anonymous enum" makes any sense at all. It's *not* an enumeration by any stretch of the term, it's just a series of manifest constants. The fact that they're grouped doesn't even have any semantic consequence, as far as I'm aware.

> => (a single member is okay)
>
> enum{
>     member1 = "1",
> }
>
> => (syntactic sugar)
>
> enum member1 = "1";
>

Just simpler examples of the above, which isn't any form of enumeration at all.

>> And bring the usual alias to new_name = <something>;
>> form (even C++ finally got this right with C++11 aliases).
>>
>
> This is probably something that should be done.
>

Emphatic +1

I always have to stop and think carefully about the order when I write an alias.

>
> Implementing a compiler is probably harder for D, because of the interplay of forward references, CTFE and compile time introspection.
>

Those make D more difficult to implement than many languages, but OTOH, AIUI, C++ has some real nightmarish details with templates and even just simply parsing. Probably some other bizarre cruft, too. IIRC, I think Walter's occasionally mentioned something about the...overload rules?

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

On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote:
> On 29.04.2012 4:31, Jonathan M Davis wrote:
> > For better or worse, the solution for smart pointers in D would be to use opDispatch,
> 
> *cough* alias this *cough*

That's not necessarily a good idea, depending on how it's used. You want to avoid having the smart pointer implicitly convert to what it holds such that a reference to it leaks. If you're dealing with a pointer to a struct, and alias this aliases to the struct (rather than the pointer), then you're okay. But if you're dealing with a class, you don't have that option. So, alias this ends up leaking a reference to the class, which defeats the purpose of the smart pointer. You have the same problem if alias this aliases to the pointer rather than what's pointed to.

But regardless of whether you use alias this or opDispatch, you have the same problem with regards to ->. In C++, . would be used to call the smart pointer's functions, and -> would be used to call functions on the object pointed to. In D, the two aren't distinguished - both use . - so you can't have any functions on the type pointed to which conflict with the smart pointer's functions, or you won't be able to call them (unless another way to call them is provided somehow). So, it's definitely something that C++ does better with as far as that goes.

- Jonathan M Davis

On Sunday, 29 April 2012 at 00:40:01 UTC, Era Scarecrow wrote:
> On Saturday, 28 April 2012 at 23:50:22 UTC, foobar wrote:
>> On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
>>>> * 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.
>
>> I agree with the general notion here. Whatever the actual implementation details are, the API should be strongly tied to the binary in order to insure consistency and ease of use. I shouldn't need to worry if the header files match the binary library. Regarding the human readable API - that's why we have documentation for.
>
>  Mmm well the main reason I see using .di files, is cases when the input library/file/dll doesn't give you much or any information. like... most dll's today. There's also tools to strip that extra debugging and structure information from your output file, so if you distribute a binary only, you still need to include it's .h file or .di file.
>
>  Cases where this would be far more relevant could be in systems that don't have a lot of room (mini-distros or recovery disks for example). I've seen a recovery disk distro with everything you needed 2 floppies disks. Only reason I don't use floppies anymore is the ones being made are crap and don't keep data where as 14 years ago I could accidentally put mine through the wash and still access it's contents. (Cheap bastards)

floppies, are you for real?!
This is only relevant if you travel a decade or so back in time.
The current generation dvd/Blu-ray discs and USB sticks aren't good enough for you?

On Sunday, 29 April 2012 at 06:11:00 UTC, Era Scarecrow wrote:
>>> My list:
>>> * I'd start with getting rid of foreach completely. (not just foreach_reverse).
>
>> C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it).
>>
>> Obviously somehow you want to go into the opposite direction. Beats me.
>
>  If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it?
>
>  Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on.

One of the ideas that I see regularly thrown around is to remove more and more things from the core language and put them in the libraries, because it's possible, and it would make for a thinner languages.
Well, these are good reasons to do it, but there are many good reasons NOT to do it.

Some general reasons:
1. code is uglier when in the libraries. One must add imports, and template code is uglier and harder to write than plain old code.
2. template code makes bigger size executables
3. error messages are more cryptic
4. we like to think that putting things in the library helps changing things easier, but my opinion is, changing fundamental structures in the standard library may actually break more code than changing them in the core language, because of the heavy interplay between modules, and also because the standard library is probably less well tested (in terms of number of regression tests) than the core language.
5. it makes work much harder for tools and parsers

Specific to D:
6. my impression is, from what I've seen in Bugzilla, that Phobos bugs tend to stay around longer, because there is not enough workforce on it


These a lot of drawbacks in my opinion. Basically, one of the main reasons the D code is clean, is because the core languages features so many useful things, with a nice, clean syntax. Moving them to the standard library will automatically make the code uglier and the language harder to use.

On Sunday, 29 April 2012 at 06:10:40 UTC, Nick Sabalausky wrote:
> "SomeDude" <lovelydear@mailmetrash.com> wrote in message
> news:sxzgfzztxfvsstwrqdiu@forum.dlang.org...
>> On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
>>> On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
>>>> On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
>>>
>>> So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?
>>
>> Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely.
>> But I agree there could be something like:
>> version(LINUX|OSX){
>> ...
>> } else {
>> ...
>> }
>
> FWIW, one of the big wins I see in migrating "version" to "static if" is
> switching from the clumbsy "defined/undefined" model to a model of
> "true/false, undefined is an error". The current "undefined is not an error"
> stuff is just so...ActionScript 2.

I don't mind changing the semantics of "version", but replacing the KEYWORD "version" with "static if" will make for code that is harder to read for the eye, harder to parse for the tools, and overall uglier. So I want to keep the keyword, which is a very good addition in my opinion.