February 17, 2012
On Friday, 17 February 2012 at 17:49:53 UTC, H. S. Teoh wrote:
> On Fri, Feb 17, 2012 at 08:56:58AM +0100, F i L wrote:
> [...]
>> Thought to be honest I doubt we'll all still be designing applications
>> in text (only) editors, even fancy ones, in the next 10-15 years.
>
> I know I still will be. I have never liked IDE's, and probably never
> will.
>
>
>> Software design is very modular, and even arbitrary logic tools could
>> be better at presenting this data. Simple things like code-completion
>> has gone a long way flatten the learning curve, and that can only get
>> better when visual and audio logic can be manipulated in like-fashion.
> [...]
>
> True, but the initial learning curve *is* only just the initial learning
> curve. Programming is essentially difficult, and whether the initial
> learning curve was easy or not, sooner or later you will still have to
> come to grips with the same difficult programming problems that will
> require a lot of effort and ingenuity to solve.
>
> Unless you're talking about trivial things like writing GUI interfaces
> and stuff like that, which require no more than the usual manipulation
> of arrays and lists and simple stuff like that.
>
> Once you get past these trivial things, and get to non-trivial problems
> like finding a good approximation for the travelling salesman problem,
> or computing higher-dimensional convex hulls, say, you'll have to think
> in the abstract anyway, so the representation really doesn't matter that
> much.  Might as well stick with text-only representation so that you can
> focus on the actual problem instead of being distracted by pretty
> graphics.
>
>
> T

Yes, that's why i said "text (only)" because some concepts are simply so abstract in nature, that "writing down" the precise logic is the most efficient way to convey them. But typing is only more direct when you: 1) know the name of what you're looking for, and 2) The problem isn't visual, or you don't think visually. If you ask a person to move an object from point A to point B, they will visualize the movement and use their hands to carry it out without ever really analyzing which muscles or numerical angles they need for approach. Moving visual data, or even abstract objects like memory, around might be best "illustrated" to the computer by recording a more hands-on example and having the compiler optimize that behavior in the best possible way. With fine-tuning step-by-step control a natural, but more expert approach.

In advertising, the more positive senses (sight, sound, touch, etc) you can associate with a product or brand, the more you'll get a positive knee-jerk response to that item, because emotional memory is reinforced through association like any other memory. In good UI design, visual/audial distinction serves to associate controls with their function, while striving to advertise as much positive emotion as possible. A good example of this is GMail's new interface where important controls are conveyed in red and options are blue. So while "fancy graphics" for the sake of advertising alone would do nothing to boost efficiency, "fancy functional graphics" could help make developing software more direct, more conveyable, and more enjoyable overall.
February 17, 2012
Am 17.02.2012, 19:00 Uhr, schrieb H. S. Teoh <hsteoh@quickfur.ath.cx>:

> I thought the US/English keyboard layout is already very well suited to
> D.

Yes, but I am still using the German (DE) layout, which has all the keys (so there was never a _need_ to switch) but almost every symbol I type requires the shift key. EN might be an alternative, but '+' with shift and '-' without? i don't know...
February 18, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.492.1329503475.20196.digitalmars-d@puremagic.com...
>
> That's not 100% true, though. Programming has always had close ties with math, even though, as you said, they aren't the same thing. In fact, computing came out of math, if you want to be historically accurate. I mean, the symbols chosen do have *some* ties with other domains, even if the mapping is not 1-to-1. If it were truly completely arbitrary, why don't we use $ for assignment, ` for equality, and % for addition? After all, we're writing a programming language, not math, so we can just assign arbitrary symbols to mean whatever we want, right?
>
> And as for C syntax, I have to admit that I'm most comfortable with C (or C-like) syntax, too. Even though it has its own flaws, I have become accustomed to its quirks, and I spontaneously type C syntax when I think of code. But that doesn't mean we shouldn't step back and re-examine the system to see if there are better ways of doing things. I find Pascal syntax, for example, truly painful. But if I were to disregard my background in C (and its derivatives), perhaps there is something to be learned from Pascal syntax.
>

I do agree with all of this, FWIW.


February 18, 2012
"Marco Leise" <Marco.Leise@gmx.de> wrote in message news:op.v9uav5gm9y6py2@marco-leise.homedns.org...
> EN might be an alternative, but '+' with shift and '-' without? i don't know...

That does seem weird now that you mention it. I guess I just managed to get used to it. *shrug*


February 18, 2012
I would like to add a few more points.
I exclusively use (g)vim text editing, why? Because it means I can jump on
a console, SSH into a server, and it will probably have vim, or atleast vi.
I also switch between languages frequently, I use PHP and JavaScript at
work; and D, bash and python in my spare time. Im used to frequent syntax
switching, even if they might all be C-style.
Ultimately, the smaller the official syntax is, the better, just look at
lisp.

James Miller -- On The Go


February 18, 2012
"James Miller" <james@aatch.net> wrote in message news:mailman.523.1329551034.20196.digitalmars-d@puremagic.com...
>I would like to add a few more points.
> I exclusively use (g)vim text editing, why? Because it means I can jump on a console, SSH into a server, and it will probably have vim, or atleast vi.

I've heard a lot of people say that about vi(m), but in my (admittedly somewhat limited) experience, I've never come across a (Li|U)n[ui]x system that didn't have nano or pico (neither of which are great, but they're good enough for editing Unix configuration files, and I'm actually capable of using them, unlike emacs or vim).

But I prefer to do it like this: SSH into a server, but then also connect via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I can use *any* editor I want: kate, gedit, whatever.

If I'm using a server that doesn't already have ssh set up (for instance, if I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can, I'll install mcedit which is the closest I've seen to what I would consider a nice text-mode editor.


February 18, 2012
On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
> "James Miller"<james@aatch.net>  wrote in message
> news:mailman.523.1329551034.20196.digitalmars-d@puremagic.com...
>> I would like to add a few more points.
>> I exclusively use (g)vim text editing, why? Because it means I can jump on
>> a console, SSH into a server, and it will probably have vim, or atleast
>> vi.
>
> I've heard a lot of people say that about vi(m), but in my (admittedly
> somewhat limited) experience, I've never come across a (Li|U)n[ui]x system
> that didn't have nano or pico (neither of which are great, but they're good
> enough for editing Unix configuration files, and I'm actually capable of
> using them, unlike emacs or vim).

Vi's not that hard to use if you don't expect to be a power user.

>
> But I prefer to do it like this: SSH into a server, but then also connect
> via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I
> can use *any* editor I want: kate, gedit, whatever.

How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases (I need to edit one line of one config file on this server I touch less than once a quarter.

>
> If I'm using a server that doesn't already have ssh set up (for instance, if
> I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can,
> I'll install mcedit which is the closest I've seen to what I would consider
> a nice text-mode editor.
>
>

February 18, 2012
On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote: [...]
> I've heard a lot of people say that about vi(m), but in my (admittedly
> somewhat limited) experience, I've never come across a (Li|U)n[ui]x
> system that didn't have nano or pico (neither of which are great, but
> they're good enough for editing Unix configuration files, and I'm
> actually capable of using them, unlike emacs or vim).

I used to swear by pico. Until my manager at my first job convinced me to try vi. Ever since then, I've acquired this occasional twitching to randomly hit the Escape key every few seconds. ;-)


[...]
> If I'm using a server that doesn't already have ssh set up (for instance, if I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can, I'll install mcedit which is the closest I've seen to what I would consider a nice text-mode editor.
[...]

I used to hate vi and its variants because of modality, which I just couldn't understand how anyone could consider as *not* a handicap.

But I have to say, after having actually used it for quite a number of years now, I simply can't bear to go back to pico. Being able to move in text by words or blocks or even matching parentheses/brackets/braces with just a keystroke or two, or apply complex commands (like regexes) to large blocks of text at a time (thus effecting a very large change *reliably*), going back to pico is like going back to a 50-year-old screwdriver with a loose handle after having used a power drill. It makes me feel so crippled.

Part of what makes vi useful is that many of its commands can deal with logical units greater than a single character. So you can, e.g., navigate by words or paragraphs or matching braces (extremely useful for moving around in code) with just one or two keystrokes, replace a word without needing to count how long it is, cut-n-paste n paragraphs (or words, etc.) around without needing to actually traverse them. In pico you'd have to select, then hit down X number of times per paragraph, before you can actually cut. In vi, you just type "d5}" to delete 5 paragraphs, then use '/' (search) to find the reinsertion point, and then 'p' to paste everything in there.  You can also say, "cut to end of file" with just two keystrokes: "dG". My favorite is "replace up to closing parenthesis": "c/)<ESC>replacement_text<ESC>". Very useful for editing code without needing to recount parentheses.

Furthermore, being able to tell the editor to repeat a (set of) commands n times is very useful, instead of having to manually repeat it yourself. Having logical units is useful here, e.g., you can repeatedly replace words of different lengths with a replacement word without needing to worry about mismatching lengths.

In many ways, using vi vs. pico to me is, in retrospect, like using C arrays vs. D arrays. :) Everything you can do with D arrays and slices, you can do in C, just in a much more tedious and error-prone way. Similarly, pico can in principle do everything that vi does too, just that vi gets you there with less pain.

Just my $0.02.


T

-- 
If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
February 18, 2012
Am 18.02.2012 18:10, schrieb Nick Sabalausky:
> "James Miller"<james@aatch.net>  wrote in message
> news:mailman.523.1329551034.20196.digitalmars-d@puremagic.com...
>> I would like to add a few more points.
>> I exclusively use (g)vim text editing, why? Because it means I can jump on
>> a console, SSH into a server, and it will probably have vim, or atleast
>> vi.
>
> I've heard a lot of people say that about vi(m), but in my (admittedly
> somewhat limited) experience, I've never come across a (Li|U)n[ui]x system
> that didn't have nano or pico (neither of which are great, but they're good
> enough for editing Unix configuration files, and I'm actually capable of
> using them, unlike emacs or vim).
>
> But I prefer to do it like this: SSH into a server, but then also connect
> via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server, I
> can use *any* editor I want: kate, gedit, whatever.
>
> If I'm using a server that doesn't already have ssh set up (for instance, if
> I'm actually setting up ssh) *then* I'll either use nano/pico or, if I can,
> I'll install mcedit which is the closest I've seen to what I would consider
> a nice text-mode editor.
>
>


Well, it's been a while, but in a previous life many moons ago (2000-2003), most of customers at the company I worked for, had plain instalations of Solaris and HP-UX with only vi (not vim) and ed available.

Oh, and the shells were the original sh or zsh without any of the GNU/BSD nice extensions.

--
Paulo
February 19, 2012
"bcs" <bcs@example.com> wrote in message news:jhonpv$neg$1@digitalmars.com...
> On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
>>
>> I've heard a lot of people say that about vi(m), but in my (admittedly
>> somewhat limited) experience, I've never come across a (Li|U)n[ui]x
>> system
>> that didn't have nano or pico (neither of which are great, but they're
>> good
>> enough for editing Unix configuration files, and I'm actually capable of
>> using them, unlike emacs or vim).
>
> Vi's not that hard to use if you don't expect to be a power user.
>

I figure I could probably get by with it (if I had to) as long as I grabbed a command reference and kept it nearby. But so far, I haven't felt any need or desire to do so.

>>
>> But I prefer to do it like this: SSH into a server, but then also connect
>> via SSHFS (SSHFS is fucking *awesome*!). That way, no matter the server,
>> I
>> can use *any* editor I want: kate, gedit, whatever.
>
> How long does it take to get in via sshfs? If it take more than about 10 seconds to get started, that is a non-starter for some cases

Same speed as any normal SSH login. Only difference is instead of doing:

$ssh user@domain

You do:

$sshfs user@domain: /desired/local/mount/point

Or if you don't want it rooted on the remote user's home dir:

$sshfs user@domain:/ /desired/local/mount/point  # the whole damn remote
system
or
$sshfs user@domain:/remote/dir /desired/local/mount/point

Then to logout, it's just:

$fusermount -u /desired/local/mount/point

It literally is SSH, so the actual login process is exactly the same as SSH, whether you use a key-pair or a full login/pass.  So however fast that is, that's how fast SSHFS is. I've never noticed any difference.