On Wednesday, 16 October 2013 at 11:47:44 UTC, simendsjo wrote:
> How would that relate to non-binary attributes like @system, @trusted, @safe?
> Seems like it would only work on binary built-in attributes.

Still helpful.

Problem with current built-in attribute design is that any attribute is supposed to be special case that catches attention and says something about the function. I D though most of attributes are actually wanted as defaults which creates all the mess. Adding negation for most common ones will make it at least tolerable without any major language changes.

On 2013-10-16 13:47, simendsjo wrote:

> How would that relate to non-binary attributes like @system, @trusted,
> @safe?
> Seems like it would only work on binary built-in attributes.

No, !@safe would be mean the exact same thing as if you hadn't applied @safe. In this case, @system.

-- 
/Jacob Carlborg

Dicebot:

> Adding negation for most common ones will make it at least tolerable without any major language changes.

I suggest to stop applying patches over patches over problems, and instead adopt a more principled approach to solve problems. The ideas of the Koka language could show a principled way to face the problem.

Bye,
bearophile

On Wednesday, 16 October 2013 at 14:59:19 UTC, bearophile wrote:
> I suggest to stop applying patches over patches over problems, and instead adopt a more principled approach to solve problems. The ideas of the Koka language could show a principled way to face the problem.

tl; dr: we can't

Right now D is in similar state as C++ in that regard and not much can be done without revamping the spec. It is not like people lack the ideas to improve the design, quite the contrary.

On Oct 15, 2013, at 5:30 PM, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> On Tue, 15 Oct 2013 15:15:45 -0700
> Walter Bright <newshound2@digitalmars.com> wrote:
> 
>> 
>> http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
> 
> Totally agree. 90+% of the argument for dynamic languages is "getting shit done", and yet they ultimately *create* work: More unittests, more roadblocks optimizing for memory/speed, and (the biggest IMO) much more debugging due to statically-checkable errors being silently converted into hidden bugs.

I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used.  Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again.

On Wed, Oct 16, 2013 at 09:19:56AM +0200, Jacob Carlborg wrote:
> On 2013-10-16 02:45, Adam Wilson wrote:
> 
> >+1
> >
> >This is why I claw my eyes out every time I have to work with JavaScript.  This is why I find statically typed languages to so much more powerful for the work I do
> 
> One big difference between Ruby and JavaScript is that when something fails in Ruby you'll get an exception. But with JavaScript it just silently fails and all your scripts on the site dies.
[...]

Yeah, this is exactly what makes Javascript a royal pain in the neck to work with.  I have the dubious pleasure of having to work on a large non-trivial JS codebase at work, and it has a reputation of simply displaying a blank page when something goes wrong. Worse yet, there is some default error handler somewhere that swallows all JS errors, so no errors get logged to the browser's JS console at all -- you have to debug the entire 50k or so lines of JS with a blank page as your only clue as to what blew up.

(And don't get me started on IE6, which used to be the de facto standard demanded by every customer some years ago, which doesn't even *have* an error console. Fortunately, the world has moved on since.)

Other times, when it doesn't show a blank page, the same ingenious default error handler makes it so that scripts *continue* running after something has gone wrong. So when you screw up and some part of the code crashes, the rest of the page continues running as if nothing happened, except that some buttons mysteriously do nothing, or the widget starts acting funny.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

On 10/16/13 4:47 AM, simendsjo wrote:
> On Wednesday, 16 October 2013 at 11:36:30 UTC, Jacob Carlborg wrote:
>> On 2013-10-16 12:52, simendsjo wrote:
>>
>>> If @mutable and @impure existed, I could just add some annotations at
>>> the top of each module, but it wouldn't help on parameters.
>>
>> We need a general way to turn off attributes. This "!@attribute" has
>> been proposed before.
>
> How would that relate to non-binary attributes like @system, @trusted,
> @safe?

Those would be turned off by choosing another one. The point is they are surjective (cover the entire domain). The binary attributes are not surjective - the absence of one indicates its opposite, but there is no way to name the opposite.

> Seems like it would only work on binary built-in attributes.

Yah.


Andrei

On 2013-10-16 20:38, Andrei Alexandrescu wrote:

>> Seems like it would only work on binary built-in attributes.
>
> Yah.

Why?

enum foo;

@foo:

!@foo void bar ();

Just as if @foo wasn't attached to "bar". Although I don't know that to do with multiple attributes of the same type:

@(foo, foo) void bar ();

Remove all?

-- 
/Jacob Carlborg

On 2013-10-16 17:37, Sean Kelly wrote:

> I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used.  Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again.

That can be quite annoying in Ruby sometimes:

class Bar
  attr_accessor :foo

  def bar
    puts foo # calls the getter
    foo = "asd" # declares a local variable
    self.foo = "foobar" # calls the setter
    @foo = "barfoo" # bypasses the setter and set the instance variable directory
    puts foo # prints the local variable
  end
end

Bar.new.bar

Although I like that instance variables are not required to be declared.

-- 
/Jacob Carlborg

On Wednesday, 16 October 2013 at 19:00:07 UTC, Jacob Carlborg wrote:
> On 2013-10-16 20:38, Andrei Alexandrescu wrote:
>
>>> Seems like it would only work on binary built-in attributes.
>>
>> Yah.
>
> Why?
>
> enum foo;
>
> @foo:
>
> !@foo void bar ();

You're right. That would be nice for generic code for instance to mark that it's done processing an attribute.

> Just as if @foo wasn't attached to "bar". Although I don't know that to do with multiple attributes of the same type:
>
> @(foo, foo) void bar ();
>
> Remove all?

Remove all would probably be more in sync with getAttributes that returns all attributes, but removing only the first would allow greater flexibility. It's easy to remove all if you have a way to remove one, but the other way around isn't as easy :)