On Sat, 3 Nov 2012 16:12:44 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> I don't even use syntax highlighting

Now that's hard-core!

On Sat, Nov 03, 2012 at 07:14:18PM -0400, Nick Sabalausky wrote:
> On Sat, 3 Nov 2012 16:12:44 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> > I don't even use syntax highlighting
> 
> Now that's hard-core!

I've *tried* using it before, mind you. I just found the colors more distracting than helpful.

But then, I'm just a crazy command-line-only relic from the 70's. My window manager is something that turns X11 into a glorified text console. I don't do desktops at all. (Sometimes I chmod -w $HOME in order to prevent Firefox from creating a Desktop subdir in my home.) So I don't expect many to share my views on these things. :-P


T

-- 
Let's call it an accidental feature. -- Larry Wall

On Saturday, 3 November 2012 at 22:45:59 UTC, Tommi wrote:
> On Saturday, 3 November 2012 at 22:01:21 UTC, Malte Skarupke
> wrote:
>>
>> D also makes the const keyword more annoying than it should be.
>
> What kind of annoyances regarding const have you encountered in D?

To start off it's simple things like this:

void main()
{
    struct A
    {
        this(int x) { this.x = x; }
        int x;
    }
    const(A) a = A(5);
    A b = a;
}

This doesn't compile. And it will probably never compile. The issue is that struct A has a context pointer and because of transitive const, you are not allowed to copy that pointer. And you can not specify your own copy constructor because all copy constructors happens post-blit, at which point you'd already have a non-const pointer. So that will probably never change.

But that's not a big problem.

It's more been stuff like me implementing an equivalent of std::function from C++. (as I said I like to be more explicit about things than delegates) I uploaded the code for it here: http://dpaste.dzfl.pl/60a46049 As you can see there isn't a single mention of const in there. All I wanted was a const and an immutable version of opCall and better const correctness for opAssign, but I just couldn't get it to compile. It'd be great if you could have a look at it. If you succeed in getting that code to be const correct, please tell me how you did it. (Also worth mentioning: I ran into at least two more issues in just this one file: 1. I couldn't specify the templated opAssign that C++'s std::function has because of a compiler bug (which will be fixed in DMD 2.061) and I had to define opAssign twice because there is no way to specify a function which accepts both an rvalue and an lvalue) That being said the code still is much cleaner than it would be in C++.

Another issue I've had was trying to implement my own hashtable which has more deterministic memory behavior. In that I found it very difficult to get the ranges for byKey and byValue to be const correct. I think I had issues with the "inout" keyword when I was passing pointers marked as inout to the range object. I think I'll revisit that one tomorrow and maybe I'll then post code here.

On Saturday, November 03, 2012 09:08:16 H. S. Teoh wrote:
> Yeah I use vim too, and I don't see any problem. But then again, maybe he's looking for syntax highlighting or that kind of stuff which I don't use.

D does syntax highlighting just fine. It's distributed with vim, and if you want the latest version, you can grab it from here ( https://github.com/JesseKPhillips/d.vim ), though for some reason, more recent versions are missing from the page at vim.org ( http://www.vim.org/scripts/script.php?script_id=379 ). Jesse Phillips maintains vim's D syntax file, and he's still an active member of the community.

I don't know of anything that vim doesn't support with D that it supports with C or C++. It may be that there are further plugins that you can get which work with C/C++ but not D (e.g. I have no idea whether cscope would work or not; I expect that plugins like that would choke on templated stuff though). It doesn't have IDE-level features in general, but vim doesn't have those normally. It's a power user level text editor, not an IDE.

- Jonathan M Davis

On 11/03/2012 11:01 PM, Malte Skarupke wrote:
> ...
> I've learned C++ in the last two years and learned D in the last couple
> months, and I slightly prefer C++ over D. When I started using C++11, I
> took for granted that all the features just work.

I have run into bugs in both g++ and clang, and I do not actually use C++ for anything beyond experimenting.

> Using D, I realize that that is actually unusual.

There are many bugs in the implementation, but stuff often works.

> In D you still encounter compiler bugs or
> inconsistent behavior way too often, and I have workarounds all over my
> code.

Do you not have 'workarounds' all over your C++ code? There are conferences about how to work around C++'s limitations. It is fun, but unproductive.

On Saturday, November 03, 2012 13:46:17 Erèbe wrote:
> Nearly no support in vim (my editor of choice)

What does vim do for D that it doesn't do for C/C++? Some plugins that you can use for C/C++ probably won't work for D, but vim itself should support D just as well as C/C++. vim is a power user level editor, not an IDE, so most of the types of features that really require understanding the language wouldn't be in vim anyway.

> Support should not be a top priority for the D-core now that the language is well featured ? Something coherent with what already exist (dmd) ?

The folks who work on the compiler and libraries are unlikely to be the same folks working on tools for D. Stuff that requires compiler support does get done by the compiler folks (e.g. providing debug symbols that gdb can use), but IDE stuff? That's not going to be done by the people working on the core language. It's generally a completely different set of people who end up working on that sort of stuff, and even without adding lots of new features to the language, there's still a lot for the core developers to be working on in terms of bug fixing or fleshing out the standard library. And D isn't adding features left and right. In fact, it's mostly feature frozen. So, that long list of features says nothing about the focus of the D community at this point as far as work goes. That just means that lots of work was done in the past.

The main focuses of the compiler folks at this point are compiler features which will help make D more fully usable (e.g. adding 64-bit support to Windows) and bug fixes. We're not adding much in the way of features to the language at all at this point. So, their focus is likely where it should be, aside perhaps from which bug in particular gets fixed first.

If you want better tools beyond the compiler, then other people need to write them. And other people _do_ write them. We have VisualD, Mono-D, etc. Maybe there aren't enough people working on that sort of thing, but work is definitely being done there.

But if you're looking for something like a fully-fledged IDE for D written completely in D, then you're going to have a very long time to wait, because that's the sort of thing that takes years and lots of people to write. And given that all there is that needs to be done for D, that's arguably a very poor use of time anyway, because solid plugins for IDEs like Ecilpse and Monodevelop will do the job just fine for the most part and require far less effort. Maybe we'll get it someday, but no time soon.

And other people are putting time and effort into other types of tools to improve D from the standpoint of tools (e.g. some work has been done on getting a package management tool for D similar to what some other languages have). So, work _is_ being done. It just takes time, and we arguably don't have enough people much of anywhere in the various areas of D development. So, pretty much everything is slower than we might like it to be. But it _is_ improving, and work is still getting done.

- Jonathan M Davis

On Fri, 2 Nov 2012 18:47:22 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Fri, 02 Nov 2012 14:53:05 -0700
> Walter Bright <newshound2@digitalmars.com> wrote:
> 
> > On 11/2/2012 2:33 PM, Jacob Carlborg wrote:
> > > I said the gap is getting thinner, not that is gone. It got foreach, some form of CTFE, static assert, lambda to mention a few new features.
> > 
> > 
> > No ranges. No purity. No immutability. No modules. No dynamic closures. No mixins. Little CTFE. No slicing. No delegates. No shared. No template symbolic arguments. No template string arguments. No alias this.
> 
> No proper modules. No properties. Slow compilation. No reference semantics for classes. No scope guards. Little default initialization. Goofy ptr and func-ptr declaration syntax. Goofy rules about what is/isn't virtual. Lots of undefined behavior. Forward declarations.
> 
> Things I'm not entirely certain about:
> 
> No IFTI? No polysemous literals? No finally?
> 

And no underscores in numeric literals. It's a minor little thing, but it's so very nice to have: No more carefully counting digits to make sure you got it right. :)

On 2012-11-04 00:12, H. S. Teoh wrote:

>> My point is, there may are a lot of people with that knowledge in
>> the community, and a little impulsion from the root should be
>> helpful, because modern support will make D shine even brighter.
>
> We *have* had repeated requests for this stuff, and I'm sure whoever has
> that knowledge in this community have taken heed, but apparently that
> hasn't been enough. So maybe what we really need is somebody to take the
> initiative to be the first to make it all happen, I guess?

The biggest problem that I see is the lack of time. I'm working on several tools that I think is useful when developing with D. But I have a full time job where I don't use D, so I don't have much time to work on D related projects at all.

-- 
/Jacob Carlborg

On 2012-11-03 17:08, H. S. Teoh wrote:
> I find it strange that every so often people clamor for IDE support,
> syntax highlighting, debugger support, etc., yet nobody seems to be
> willing to contribute actual code. Don't like something about the
> current state of D development tools? Well then do something about it.
> The source code is there for a reason, and it's not just to make people
> feel all warm and fuzzy inside because now we can label ourselves "open
> source".

It's not that simple, for me it's mostly the lack of time to work on D related projects. See one of my other replies:

http://forum.dlang.org/thread/iokgislnlzsvsosmqbbv@forum.dlang.org?page=6#post-k75ijh:241aic:241:40digitalmars.com

-- 
/Jacob Carlborg

On Sat, 03 Nov 2012 12:46:17 -0000, Erèbe <erebe@erebe.eu> wrote:
> .. a Visual studio plugin where you need to buy a liscence in order to have the IDE.

I was under the impression that VisualD worked with "express" versions of Visual Studio, which are free.

R

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