On Tue, 3 Sep 2013 11:18:03 +1000
Manu <turkeyman@gmail.com> wrote:
> 
> I think I've repeated myself 3 or 4 times here, but one more time for good measure...
> 
> Requiring IDE assistance to make code _readable_ seems completely
> fail to me.
> 1) You're not always reading code in your IDE, often in commit logs,
> diff windows, emails, chat clients.
> 2) With so much hate for IDE support, it seems like a massive
> contradiction to say that an IDE should be required to make code
> readable.
> 
> Reading code is the most fundamental task in programming. Anything that gets in the way of code readability is an epic fail.
> 

First of all, not everybody agrees that separating out function definitions makes code easier to read rather than harder.

Also, maintainability is just as important as readability, and "poor
maintainability" is a very big and very common objection to C++'s
separation of member function definitions from class definitions. You're
essentially writing and maintaining full documentation completely by
hand and a lot of people feel very bogged down by the extreme
non-DRYness of that very quickly, especially when there are already so
many other ways to get the same information without maintaining
it manually: Automatic Doc generators, high-level IDE class browsing,
and code folding (and code folding is *not* an IDE thing, but an
extremely common code editor thing).

On 9/2/2013 6:13 PM, deadalnix wrote:
> Unless the industry is showing signs of understanding, I'm done with theses
> stuffs. When amateurs can do better for free, you are not providing any service,
> you are just scamming your customers.

I don't know about scamming, but I find the business practice of ignoring people who want to throw money at you to be utterly baffling.

For example, I want to watch Forbrydelsen. It's only available as Region 2 DVDs. I have several dvd/bluray players, none will play it. What the hell? It's 6 years old. Who is making money off of me not being able to watch it?

(Amazon sez: "It won't play on standard DVD/Blu-ray players sold in the United States.")

I'm unimpressed.

On 2 September 2013 22:14, Ramon <spam@thanks.no> wrote:
> On Monday, 2 September 2013 at 21:04:24 UTC, Walter Bright wrote:
>>
>> On 9/2/2013 1:36 PM, H. S. Teoh wrote:
>>>
>>> It's things like this "keyhole interface", that caused me to be convinced that the GUI emperor has no clothes, and to turn to CLI-only development.
>>
>>
>> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
>>
>> On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses.
>>
>> With VS, or any GUI, if there's not a button to do it, I'm reduced to:
>>
>> move mouse
>> click
>> move mouse
>> click
>> move mouse
>> type
>> move mouse
>> click
>> type
>>
>> to get something done. And if I want to do it again, I have to repeat that process. After the 10th time, it's gaaaaahhh I hate it and go back to the CLI.
>>
>> I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's:
>>
>> right shift click on the picture
>> select open with
>> select photoeditor
>> select edit
>> select rotate
>> select autorotate
>> select apply
>> select save
>> select exit
>>
>> Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool:
>>
>> write a script that does it to one picture, name it cc.bat
>>
>> do:
>>    dir/b *.jpg >doit.bat
>>
>> open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes
>>
>> execute the script
>>
>> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!
>
>
> I'm not that big fan of "full" Guis either and try to stick to slick ones.
>
> But for fairness sake: Better Gui Programms (read: way too few) have Macro
> facilities.
>
> (My major reason to go GUI for programming is the auto* /configure/m4/makefile mess. Having that handled by some build in magic is cool. Which, if I'm not mistaken is less of an issue with D (dub, etc?))
>
> A+ -R


Autotools is only as much of a mess as you make it.  I prefer it because it is versatile and portable.

Versatile - ie: Debian rules.conf files used to build binary pacakges
from source are built ontop of the make system... there are 40,000+
packages for all sorts of applications built by them.
Portable - ie: If I give you a set of sources and a configure/Makefile
to build them, I can happily guarantee you can put it on a machine
powered by SPARC, ARM, MIPS, Xtensa... and the tools will be available
for you to at least configure the sources, and hopefully build (so
long as was written to be portable :)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Mon, Sep 02, 2013 at 02:04:22PM -0700, Walter Bright wrote:
> On 9/2/2013 1:36 PM, H. S. Teoh wrote:
> >It's things like this "keyhole interface", that caused me to be convinced that the GUI emperor has no clothes, and to turn to CLI-only development.
> 
> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
> 
> On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses.

Some GUI apps do have macro facilities. The problem is, *most* GUI apps don't, and those that do brew their own and do it their own idiosyncratic way. Which means it only works *within* the app. You'd be lucky enough to *have* macro facilities in the first place, and now you want to interface with an external app? Tough luck. Some macro facilities do allow interfacing with CLI scripts and stuff, but wanna interface with another GUI app? Not a chance. Any inter-app scripted interface only exists if it's anticipated by the developers (and they have enough financial/political backing to implement it).  And that's precisely the problem. You *can't* anticipate everything that users might need to do. So most inter-app scripting is basically impossible.

As someone once said, a good software design makes easy things easy, and hard things possible. With (most) GUI apps, easy things are indeed easy, but hard things are impossible.

Now I'm not saying CLI apps are necessarily better in terms of UI design -- a lot of CLI utilities are unnecessarily obscure (I mean, "awk", "grep", "sed"? In this day and age? Seriously?). So they flunk in the easy things are easy category. But at least hard things are *possible*. There's always a way to work around the limitations and get things to work, even if it's an ugly hack -- the important thing is that it *can* be made to work somehow. With GUI apps, trying to do something the developers haven't thought of is an exercise in futility (and frustration). Given the choice, I rather spend the effort to learn the "harder" CLI interface, knowing that there will always be a way to make it work, than to get locked in to a GUI interface whose limitations may have *no* workarounds.


[...]
> I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's:
> 
> right shift click on the picture
> select open with
> select photoeditor
> select edit
> select rotate
> select autorotate
> select apply
> select save
> select exit
> 
> Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool:
> 
> write a script that does it to one picture, name it cc.bat
> 
> do:
>    dir/b *.jpg >doit.bat
> 
> open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes
> 
> execute the script
> 
> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!

Yeah, when it comes to image editing, it's imagemagick FTW.

Even for image *generation*, I opt for programmatic generation where possible. For example, I have a website with lots of geometric images, all hand-tuned carefully. But the tuning all goes in a script. The build system runs the script through a program that does the calculations and outputs PovRay scene files, povray transforms them into .png's, then the build script runs imagemagick on them to trim them down, add borders, etc., and then install them into the right target directories.  As a result, none of the images need to be backed up; the subversion repos contains only the text-based script files. If needed, a single command recreates the entire website, images and all, completely automatically.

Furthermore, I've often found the need to tweak the images from time to time. For example, adjust the colors on a particular geometric object to make it brighter, etc.. Or if there's a mistake in the source data, and a whole set of images need to be re-rendered. Had I done all the images by hand, it would be a positively painful process of manually examining each image, load it up in the image editor and painstakingly adjust the one tiny part that needs adjusting, and miss the 20 other images that also need to be adjusted, etc.. But with my fully-scripted system, I just edit a couple of values in the source data files, and *all* the images downstream get regenerated automatically by the build system (which, unlike makefiles, uses content-hashing to determine which targets need to be rebuilt, so it automatically knows exactly which files to refresh). A single command, and everything that needs to be updated is re-rendered and regenerated, and optionally, published.

Best of all, this lets me work on an in-progress version of the website on my local PC and see exactly how it's gonna look, then when it's ready, logon to the webserver, svn update, scons -j12 install, and sit back and take a break, and let the script do its job, knowing that a couple o' hours later the website will automatically be updated. No babysitting necessary.

Had I used GUI tools to do this, I'd be fighting with trying to make ImageEditorPro123 work with VisualWebsite2013, and trying to remember which folders held which version of which image, forgetting which layers to apply in which order to which image, generating images from the wrong version of the source data and having to redo it all, etc.. It'd be a gigantic exercise in micromanagement just to get things to work together properly. The lack of cross-app scriptability really turns this into a full-time job, whereas right now, it's a 5-minute edit and re-run the build script, and I'm up and away.

Sometimes I wonder how we managed to get from intelligent parsing of language (CLI commands with meaningful syntax!) all the way to the advanced caveman future of point-and-grunt.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On Mon, 02 Sep 2013 21:29:53 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/2/2013 6:13 PM, deadalnix wrote:
> > Unless the industry is showing signs of understanding, I'm done with theses stuffs. When amateurs can do better for free, you are not providing any service, you are just scamming your customers.
> 
> I don't know about scamming, but I find the business practice of ignoring people who want to throw money at you to be utterly baffling.
> 
> For example, I want to watch Forbrydelsen. It's only available as Region 2 DVDs. I have several dvd/bluray players, none will play it. What the hell? It's 6 years old. Who is making money off of me not being able to watch it?
> 
> (Amazon sez: "It won't play on standard DVD/Blu-ray players sold in
> the United States.")
> 
> I'm unimpressed.

Totally agree. The suits in the media sectors are fucking idiots and need to be jailed for *everyone's* good.

Not that we should need to, but luckily there are ways to exercise our fair use rights (well, at least with movies anyway):

http://www.dvddecrypter.org.uk/

And if it's a DVD9 video, then also:

http://www.dvdshrink.org/

As a bonus they'll also get rid of all that PUO bullshit.

Now if only there were similarly easy equivalents to kill the
regions, unskippable bullshit and non-backupability (and I *do*
literally mean actual "backup") in videogames...Seriously though, as
horrible as RIAA/MPAA are in terms of consumer rights the videogame (and
mobile apps, too) world is far worse.

On Tue, Sep 03, 2013 at 06:22:37AM +0100, Iain Buclaw wrote:
> On 2 September 2013 22:14, Ramon <spam@thanks.no> wrote:
[...]
> > (My major reason to go GUI for programming is the auto*
> > /configure/m4/makefile mess. Having that handled by some build in
> > magic is cool. Which, if I'm not mistaken is less of an issue with D
> > (dub, etc?))

That's a step backwards! Do yourself a favor and use a *real* build system, like scons or tup. *Anything* but make, which is a hack on top of a patch to a broken hack of patch of a simplistic system stretched beyond its original design capabilities.


[...]
> Autotools is only as much of a mess as you make it.  I prefer it because it is versatile and portable.
> 
> Versatile - ie: Debian rules.conf files used to build binary pacakges
> from source are built ontop of the make system... there are 40,000+
> packages for all sorts of applications built by them.
> Portable - ie: If I give you a set of sources and a configure/Makefile
> to build them, I can happily guarantee you can put it on a machine
> powered by SPARC, ARM, MIPS, Xtensa... and the tools will be available
> for you to at least configure the sources, and hopefully build (so
> long as was written to be portable :)
[...]

It's also a magnificent 16-storey fortress of cards that comes crashing down in the ugliest, unfriendliest sort of way when you do something contrary to its 150 unwritten rules enforced solely via convention. That it *does* work, I have no doubt, but its usability rivals that of D's current IDE situation. :-P

The problem is that unless you're an 8th circle black belt in autotools-fu, most likely whatever autoconf.m4 (or whatever it is that you write these days) you write is utter garbage that will break left, right, center, and behind, when someone so much as sneezes at it. I rather be spending my time writing code than learning 150 unwritten conventions of what is expected in which obscure corner by which inscrutable component of the autotools "suite", thank you very much. You're more than welcome to write my autotools scripts for me to make my program compile on obscure platforms I've never heard the existence of. Me, I'll be over here with tools that don't trigger apocalyptic compile catastrophes when I lack arcane knowledge of obscure tomes of ancient documentation that only the initiated can comprehend. :)


T

-- 
My program has no bugs! Only undocumented features...

On Tuesday, 3 September 2013 at 05:57:01 UTC, Nick Sabalausky wrote:
> Totally agree. The suits in the media sectors are fucking idiots and
> need to be jailed for *everyone's* good.
>
> Not that we should need to, but luckily there are ways to exercise
> our fair use rights (well, at least with movies anyway):
>
> http://www.dvddecrypter.org.uk/
>

This illegal in most countries.

Also, they put so much effort into us not being able to read the disc that it don't make any sense. Why would go in extra effort for your customer not being able to use your product ?

On 2013-09-03 06:29, Walter Bright wrote:

> For example, I want to watch Forbrydelsen. It's only available as Region
> 2 DVDs. I have several dvd/bluray players, none will play it. What the
> hell? It's 6 years old. Who is making money off of me not being able to
> watch it?

Don't you have a region free DVD player? Basically only the first models sold in Sweden were tied to a specific region. The rest can play any model.

-- 
/Jacob Carlborg

On 2013-09-03 07:56, Nick Sabalausky wrote:

> Now if only there were similarly easy equivalents to kill the
> regions, unskippable bullshit and non-backupability (and I *do*
> literally mean actual "backup") in videogames...Seriously though, as
> horrible as RIAA/MPAA are in terms of consumer rights the videogame (and
> mobile apps, too) world is far worse.

Here in Sweden we pay a fee for every empty media we buy (CD, DVD, Blu-Ray, USB, external HDD) to cover making private copies. But they still put all these protections and DRM's on all media.

-- 
/Jacob Carlborg

On 2013-09-02 22:59, Jonathan M Davis wrote:

> I don't think that I've ever heard of lldb. I'll have to check it out. Thanks
> for the info.

It's from the LLVM project. Uses libclang and LLVM JIT to execute expressions and so on.

-- 
/Jacob Carlborg