"Nick Sabalausky" <a@a.a> wrote in message news:jl3n59$qf7$1@digitalmars.com...
> "Jacob Carlborg" <doob@me.com> wrote in message news:jl3kar$ie4$1@digitalmars.com...
>> On 2012-03-30 04:05, Nick Sabalausky wrote:
>>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>>>>
>>>> True, but I upgraded recently to 64 bit Win 7, with a 6 core processor
>>>> and
>>>> SSD drive. Reddit seems a lot zippier :-)
>>>
>>> I don't understand why people think it's ok for basic, basic shit that
>>> would
>>> have ran fine on a Pentium 1 (and less) to now require what quite
>>> literally
>>> is a super-fucking-computer-on-the-desktop just to run acceptably.
>>>
>>> Seriously, what the fuck's the point of buying all this insanely
>>> powerful
>>> hardware if software just turns the damn thing right back into a fucking
>>> single-core P1? That's just insane. People are seriously fucking
>>> bat-shit
>>> crazy.
>>
>> Have you seen this:
>>
>> http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
>>
>> They compare and old Macintosh from the 80's against a fairly new PC.
>>
>
> Yea, I've seen that. It's a very good article, though. Although I've been saying this since before that article, and even before multi-cores. Contrary to the title, I wasn't at all surprised which won ;)
>
> Of course, I don't expect software to be as super-fine-tuned as it was on, say, the Apple 2 or Atari 2600. There *is* definitely some value in loosing a certain amount of performance to abstractions, up to a point. But we've blown way, way, WAAAY beyond that point.
>
> It's sickening how much gratuitous waste there is in a lot of "modern" software, and really for not much benefit, as D proves.
>

Actually, one thing that really gets me is shutdown times: RAM is *volitile*. How much processing can really be needed when the RAM's just gonna get wiped anyway? You ask the user if they want to save, you flush the output queues for anything non-volitile, and you cut the power. Sheesh!

Desktops are the worst offenders, and paricularly WinXP. But then even on my brother's PS3, you can literally count the seconds before it actually turns off. It's just a set-top gaming console, is that really necessary? (They can spare me their "It does everything!" - like I give a crap about any of those gimmicks.) On my old (super-low-power) NES, you could hit the power button, and within one second you were at the title screen. Hit one button and you're immediately playing (and I mean *playing*, not "watching exposition" or "learning how to turn left"). And then power button again, and the system's off. Try doing any of that on a PS3. It's amazing that the faster and more powerful the systems become, the longer and longer it takes them to start/stop tasks. ('Course, the Apple 2 is a notable exception: that thing seemed to take forever to boot. It did shut down pretty damn quick though.)

Some of that stuff isn't even a technical matter at all, but deliberate design: Who the hell decided we need twenty company logos (fully animated, one at a time), then 10+ minutes of exposition and building "atmosphere", followed by half an hour of (typically patronizing) tutorials before actually getting to the real gameplay? Zelda Skyward Sword is the worst offender, it literally takes *hours* to get past all the initial exposition, tutorials and shit into the real core of the game (I honestly started wondering if there even *was* a game - "Did I pick up a Harry Potter movie by mistake?"). The original Zelda, you could get from power off to the meat of the gameplay in literally seconds. Game devs won't let you do that now: They've gotta show off their cinematography so they can get hired by Pixar, where they *really* wanted to be all along. (Meh, Dreamworks was always better anyway ;) )

Sheesh, (and now I'm *really* getting sidetracked here ;) ), even *Hollywood* hates exposition (you can tell by how the actors/directors always rush through those lines as fast as they can). But go figure: with all the Hollywood brown-nosing the game devs do, and imitating them even in ways that make no sense for an interactive medium, that hatred for exposition and rambling on, and on, and on, is the *one* thing in Hollywood that game devs aren't tripping over themselves trying to ape.

On 03/30/2012 01:45 AM, bearophile wrote:
> Timon Gehr:
>
>> I think the article does not mention that it also works for primitive types.
>
> But there is a small problem with primitive properties:
> http://d.puremagic.com/issues/show_bug.cgi?id=7773
>
> Bye,
> bearophile

Yes, I have never understood why built-in types are excluded from expressions other than '.' expressions during parsing. After all, semantic analysis must deal with them because they can occur through aliases. It seems inconsistent and causes strange behaviour that is hard to remember. (The fact that primitive types cannot be passed as alias parameters smells in a similar way.)

On 3/30/2012 12:18 AM, Nick Sabalausky wrote:
> While there are definitely times I need to access private state across
> separate components within a module, I find such cases are fairly uncommon,
> so I question the wisdom of making it the default behavior.

If your module has grown so large that you need such encapsulation, meaning that the "cognitive load" of understanding the module has exceeded one's grasp, then I submit that the module needs to be broken up into multiple modules.

There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package.

We think it's something we need to address.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jl3l0c$jn2$1@digitalmars.com...
> On 3/29/2012 7:05 PM, Nick Sabalausky wrote:
>> I don't understand why people think it's ok for basic, basic shit that
>> would
>> have ran fine on a Pentium 1 (and less) to now require what quite
>> literally
>> is a super-fucking-computer-on-the-desktop just to run acceptably.
>>
>> Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy.
>
> I'm in complete agreement with you.
>
> It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!)
>

Yea, needing to upgrade Nero bugged me too. And even ignoring filesize, each new version of Nero kept getting worse anyway (the original was actually pretty good, but they quickly put a stop to that).

I just use ImgBurn/DVD Decryptor/DVD Shrink for ripping/burning ISOs and InfraRecorder for everything else. They're soooo much better than *any* commercial package I've seen in at least ten years. They do the job, do it well, and all with *no* bullshit/bloat/skins or any other such crap.

or just use http://cdburnerxp.se/

Am 30.03.2012 10:30, schrieb Nick Sabalausky:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:jl3l0c$jn2$1@digitalmars.com...
>>  On 3/29/2012 7:05 PM, Nick Sabalausky wrote:
>>>  I don't understand why people think it's ok for basic, basic shit that
>>>  would
>>>  have ran fine on a Pentium 1 (and less) to now require what quite
>>>  literally
>>>  is a super-fucking-computer-on-the-desktop just to run acceptably.
>>>
>>>  Seriously, what the fuck's the point of buying all this insanely powerful
>>>  hardware if software just turns the damn thing right back into a fucking
>>>  single-core P1? That's just insane. People are seriously fucking bat-shit
>>>  crazy.
>>
>>  I'm in complete agreement with you.
>>
>>  It's like when I bought a new dvd burner, and had to upgrade Nero Burning
>>  to deal with it. The old Nero was 6Mb, the new one was 90Mb (!)
>>
>
> Yea, needing to upgrade Nero bugged me too. And even ignoring filesize, each
> new version of Nero kept getting worse anyway (the original was actually
> pretty good, but they quickly put a stop to that).
>
> I just use ImgBurn/DVD Decryptor/DVD Shrink for ripping/burning ISOs and
> InfraRecorder for everything else. They're soooo much better than *any*
> commercial package I've seen in at least ten years. They do the job, do it
> well, and all with *no* bullshit/bloat/skins or any other such crap.
>
>

On 3/30/12, Walter Bright <newshound2@digitalmars.com> wrote:
> There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language.

Ignoring that there are still a few import bugs, you can split functionality into multiple modules and use one module per package that publicly imports all modules in that package:

module std.datetime;
public import std.date.time, std.date.clock, std.date.watch;

That's what people are already doing with various D libraries. Then, unittests could be moved into a central place. I think that could cut down the linecount quite a bit. If linecount is still a problem after that, then either the modules have to be further split or it might be an indication that Phobos is getting too large.

Why would the language be at fault here?

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jl3qds$10ga$1@digitalmars.com...
> On 3/30/2012 12:18 AM, Nick Sabalausky wrote:
>> While there are definitely times I need to access private state across
>> separate components within a module, I find such cases are fairly
>> uncommon,
>> so I question the wisdom of making it the default behavior.
>
> If your module has grown so large that you need such encapsulation, meaning that the "cognitive load" of understanding the module has exceeded one's grasp, then I submit that the module needs to be broken up into multiple modules.
>

It's not about cognitive load exceeding the brain's capacity (well, I'm sure it can be in some cases), it's about just simply keeping separate things separate without ending up in Java's world of "millions of tiny files for each trivial thing".

You should be able to look at a couple unrelated chunks of code in a module (ie they handle completely separate details of the implementation of the module's single conceptual task) and *know* there's no interplay going on simply by virtue of the code not specifically suggesting otherwise via permissive access specifiers. And if those "separate sub-tasks" are small, stucking them each in separate files is a Java-like burden. So if you don't want to go that route, then when you look at them as things are now, well, there might be interplay and there might not be.

> There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language.

I thought that was a deliberate Phobos style convention. I'm certain I remember you and/or Andrei talking here about a year or two ago about how you didn't want Phobos modules broken up into separate implemetation modules.

In fact, I definitely remember now, back early last year when Andrei first brought up the idea of having  generalized parser in Phobos, I mentioned my Goldie project and there was a small discussion about the possibility of using that as the "std.parser" or whatever. I specifically remember you saying that, were Goldie to go into Phobos, you'd want it all merged into one module. Ultimately, I backed off on the whole idea as I felt Goldie likely wouldn't be an appropriate fit for Phobos, and that was one of the reasons.

> Andrei and I have  talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address.

Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module "foo" and module "foo.bar". The reasons they gave for wanting this are right along the lines of what you're talking about here. Eventually they got the message that it wasn't gonna happen and they gave up asking for it.

Or is there a separate problem you're refering to?

On 03/30/2012 02:15 AM, Nick Sabalausky wrote:
> Eh? Other people have voiced concerns over that since waaay back in even
> pre-D1 times. In particular, many people have argued for allowing modules
> with the same name as a package. Ie: you could have both module "foo" and
> module "foo.bar".

This is afaik similar to ADA child packages.
Quote :
Ada allows one to extend the functionality of a unit (package) with so-called children (child packages). With certain exceptions, all the functionality of the parent is available to a child. This means that all public and private declarations of the parent package are visible to all child packages.

On 3/30/2012 2:15 AM, Nick Sabalausky wrote:
>> Andrei and I have  talked about it, and we think it is because of
>> difficulties in breaking a module up into submodules of a package.
>> We think it's something we need to address.
>
> Eh? Other people have voiced concerns over that since waaay back in even
> pre-D1 times. In particular, many people have argued for allowing modules
> with the same name as a package. Ie: you could have both module "foo" and
> module "foo.bar". The reasons they gave for wanting this are right along the
> lines of what you're talking about here. Eventually they got the message
> that it wasn't gonna happen and they gave up asking for it.
>
> Or is there a separate problem you're refering to?

No, that's it. What brings it to the fore is, as I said, the kitchen-sink module that is becoming prevalent.

On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
>
> Yea, that occurred to me, too. <wishful musing>I've been starting to think
> more and more that the "everything in a module is a friend" was a mistake,
> and that we should have instead just had a "module" access specifier like we
> have "package".</wishful musing>

Given Phobos' organization (or lack thereof) where files are at the order of 10k lines or more this should raise concern.