On Wed, 29 Oct 2014 14:32:23 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> I used to be a fan of the ancient Norton Editor
me too! ;-) that's why i started using mcedit on GNU/Linux. there is also "ledit" project, which seems to be very similar to NE, but i discovered it too late.

> pico, until my supervisor at my first job convinced me to try vi. It took a lot of convincing, but after I finally "grokked" the "philosophy" behind vi (which is very different from a non-model editor, I have to say), I found myself much more productive in it, and operate on a "higher level of abstraction", if you can call it that, than the typical character-oriented approach of NE, pico, and the like. In vi/vim, I operate more with lines and words, and ironically enough the awkward character navigation interface forces me to think more semantically (e.g., "go to the place in the file where the word 'cartesianProduct' occurs", which equals to searching for the said word).
i understand vi philosophy (heh, i was using some Forth systems with
editors that has similar spirit), but i simply don't have enough temper
to make myself familiar with vim. i clearly see that editing with vim
will be more productive than with mcedit, but... when i want to write
something, i don't want to think about editor commands, so i'm dropping
vim and going back to mcedit to "make the things done". i know that i
simple have to do some training (as with D, for example, which wasn't
familiar at all when i started with it), but... my lazyness stops
me. ;-)

> Yeah, I rarely ever use interactive debuggers these days. More often than not, I find clever, directed use of printf-debugging actually more effective. Especially if you have debug logs placed at strategic places that allow you to narrow down the locus of the problem after the crash.
and integrated command console, it simply rocks! ;-) i was writing command console modules in each language i was using. it was a pain in pascal/delphi, hairy mess of macros in C, tricky abomination in C++ and hacky to write but very easy to use module in D. actually, simple embeddable command console was the first poject i done with D, just to see if it will help me writing such things without much boilerplate code. and after that project i was never thinking about returning back to c/c++ again. ;-)

metaprogramming rocks. i know that, 'cause i was using Forth and Scheme alot, and even Smalltalk a little. ;-)

On Thu, Oct 30, 2014 at 12:06:23AM +0200, ketmar via Digitalmars-d wrote: [...]
> i understand vi philosophy (heh, i was using some Forth systems with editors that has similar spirit), but i simply don't have enough temper to make myself familiar with vim. i clearly see that editing with vim will be more productive than with mcedit, but... when i want to write something, i don't want to think about editor commands, so i'm dropping vim and going back to mcedit to "make the things done". i know that i simple have to do some training (as with D, for example, which wasn't familiar at all when i started with it), but... my lazyness stops me. ;-)

Yeah, it took me a while before I "grokked" the vim philosophy. And by that I'm not talking about just understanding what it is -- I mean when it finally "clicked" in my brain and I developed a "feel" for it. Like I said, it took my former supervisor a lot of convincing and encouragement before that happened. Much of it was also due to the fact that we had a bunch of bare bones Solaris servers that had vi installed by default, but not pico or any of the "nice" editors (that I considered to be "nice" back then). After a while, I got tired of endlessly ftp'ing and scp'ing pico to every machine I needed to do work on -- often it was a matter of updating some config files and it was taking more time to transfer pico to the machine that it was to use vi to make the changes in the first place. So I was forced to use vi until it became second nature to me.

Nowadays, it's all mostly muscle memory for me -- I don't even think about how to use it anymore, my fingers just "know" what to do to make a certain edit. (One symptom of this is that I've acquired the "Esc twitch", that is, every now and then my little finger would spontaneously reach for the Esc key, 'cos it's so ubiquitous when you're using vi. :-P) Now, ironically, I actually find the "simple" editors much harder to use, in that I have to actively recall how to make edits at the character level again, instead of just letting vim commands "flow" from my fingers spontaneously. :-P


[...]
> and integrated command console, it simply rocks! ;-) i was writing command console modules in each language i was using. it was a pain in pascal/delphi, hairy mess of macros in C, tricky abomination in C++ and hacky to write but very easy to use module in D. actually, simple embeddable command console was the first poject i done with D, just to see if it will help me writing such things without much boilerplate code. and after that project i was never thinking about returning back to c/c++ again. ;-)
> 
> metaprogramming rocks. i know that, 'cause i was using Forth and Scheme alot, and even Smalltalk a little. ;-)

Yeah, metaprogramming r0x0r5. Especially in D, where it's actually beneficial to the code... as opposed to C++, where its leakiness makes it fragile and hard to understand, so much so that many C++ coders avoid templates and metaprogramming completely. I was skimming over Google's C++ style guide today, for example, and was shocked to discover that they discourage the use of templates and frown on metaprogramming, among other shocking things (like prohibiting exceptions, using 2-space indentation, and other "interesting" things [1]).

[1] I did agree with avoiding iostream and using C's stdio instead, though. I've been doing that for years, but this is the first time I learned of a major C++ shop recommending the same. Everyone else used to just berate me for anachronism. The only problem with stdio is that its age is showing, and type safety is a big issue.  But in D, 'tis another story, since we have typesafe writefln. And, to top it off, it sports some of the coolest print formatting features, especially %(...%) which can format a matrix of arbitrary user-defined types in a typesafe manner.  Total awesomeness.

And once I get some free time, I'm gonna take a shot at implementing compile-time checked format strings, which Andrei has already preapproved. D totally blows C++ out of the water with taking metaprogramming to whole new heights of cool, I tell ya.


T

-- 
Without outlines, life would be pointless.

On Wed, 29 Oct 2014 21:59:25 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> Nowadays, it's all mostly muscle memory for me -- I don't even think about how to use it anymore, my fingers just "know" what to do to make a certain edit.
yeah, that is what i missing for now. i have to force myself to use vim
like i forced myself to use D some time ago. i was trying to drop D
each time i need to do something more complicated than
`writeln("hello world!")`, but resisting that desire. and now i have
the reverse effect: i want to drop C each time i must write something
with it. ;-) where is all my joy? where are my strings, slices,
templates, metaprogramming? and don't even show me that C macros
anymore! ;-)

> Yeah, metaprogramming r0x0r5. Especially in D, where it's actually beneficial to the code... as opposed to C++, where its leakiness makes it fragile and hard to understand, so much so that many C++ coders avoid templates and metaprogramming completely.
when i was using C++ i wasn't used templates alot. bits of STL here and there, simple "generic" classes like lists and that's all.

and now with D i catching myself turning alot of my functions to templates without double thinking. 'cause it's so easy, and "hey, this function can operate on more that one data type, so let's turn it into template!" back in time C++ wasn't able to autodeduce template arguments, so calling templated functions was ugly. and with D it's almost always a simple function call, so why not? simplified template syntax also helps alot.

> [1] I did agree with avoiding iostream and using C's stdio instead, though. I've been doing that for years
me too. never was a fan of c++ streams.

> story, since we have typesafe writefln. And, to top it off, it sports some of the coolest print formatting features, especially %(...%) which can format a matrix of arbitrary user-defined types in a typesafe manner.  Total awesomeness.
yes, i love it too. plus 'writeln' reminds me my old Pascal days. ;-)

> And once I get some free time, I'm gonna take a shot at implementing compile-time checked format strings, which Andrei has already preapproved. D totally blows C++ out of the water with taking metaprogramming to whole new heights of cool, I tell ya.
i recently wrote a very simple static 'writef', which genertes mixin with calls to posix `write()` and i really like it. nothing serious, though, and not very clear code, but it was fun to do a bit of functional programming again. ;-)

On Thursday, 30 October 2014 at 05:01:27 UTC, H. S. Teoh via Digitalmars-d wrote:
> templates and metaprogramming completely. I was skimming over Google's
> C++ style guide today, for example, and was shocked to discover that
> they discourage the use of templates and frown on metaprogramming, among
> other shocking things (like prohibiting exceptions, using 2-space
> indentation, and other "interesting" things [1]).

The Google cppcon presentation was pretty clear on this, e.g.:

1. The code should be easy to understand at the call site for a non-expert. No need to look up the docs. They don't care if code is tedious to write, because reading is more important and frequent.

2. Exceptions hide error_handling, so they have their own status class that force error-handling or explicit "ignore()" to make code review easier. C++ exceptions also come with a performance penalty.

3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.

4. They use clang with C++11 and standard libraries.

5. Formatting debates are not interesting. Use automatic clang formatting, it is better than most programmers anyway.

On Thursday, 30 October 2014 at 05:54:34 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 October 2014 at 05:01:27 UTC, H. S. Teoh via Digitalmars-d wrote:
>> templates and metaprogramming completely. I was skimming over Google's
>> C++ style guide today, for example, and was shocked to discover that
>> they discourage the use of templates and frown on metaprogramming, among
>> other shocking things (like prohibiting exceptions, using 2-space
>> indentation, and other "interesting" things [1]).
>
> The Google cppcon presentation was pretty clear on this, e.g.:
>
> ...
>
> 3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.
>

Coming from a Quick/Turbo Basic/Turbo Pascal background, I never understood the C culture about function parameters.

Just another example of C being unsafe.

--
Paulo

On Thursday, 30 October 2014 at 08:02:49 UTC, Paulo  Pinto wrote:
>> 3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.
>>
>
> Coming from a Quick/Turbo Basic/Turbo Pascal background, I never understood the C culture about function parameters.
>
> Just another example of C being unsafe.

C is unsafe, but it is desirable to make it visible at the call site that you are returning a value through a parameter. I think it is a good idea to create a special "zero-cost" wrapper type so that you write:

copy_from_to( input, returns(output) )

I noticed that c++11 has a ref() function:

http://en.cppreference.com/w/cpp/utility/functional/ref

On Thursday, 30 October 2014 at 09:39:42 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 October 2014 at 08:02:49 UTC, Paulo  Pinto wrote:
>>> 3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.
>>>
>>
>> Coming from a Quick/Turbo Basic/Turbo Pascal background, I never understood the C culture about function parameters.
>>
>> Just another example of C being unsafe.
>
> C is unsafe, but it is desirable to make it visible at the call site that you are returning a value through a parameter.

"
Interviewer: Just a minute. What about references? You must admit, you improved on 'C' pointers.

 Stroustrup: Hmm. I've always wondered about that. Originally, I thought I had. Then, one day I was discussing this with a guy who'd written C++ from the beginning. He said he could never remember whether his variables were referenced or dereferenced, so he always used pointers. He said the little asterisk always reminded him..
"

On Thursday, 30 October 2014 at 09:39:42 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 October 2014 at 08:02:49 UTC, Paulo  Pinto wrote:
>>> 3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.
>>>
>>
>> Coming from a Quick/Turbo Basic/Turbo Pascal background, I never understood the C culture about function parameters.
>>
>> Just another example of C being unsafe.
>
> C is unsafe, but it is desirable to make it visible at the call site that you are returning a value through a parameter. I think it is a good idea to create a special "zero-cost" wrapper type so that you write:
>
> copy_from_to( input, returns(output) )
>
> I noticed that c++11 has a ref() function:
>
> http://en.cppreference.com/w/cpp/utility/functional/ref

In 30 years of coding I never found this to be a problem and it saved a lot of bad pointers being passed on to functions.

Again, I am spoiled by better languages for systems programming, even if the market has bet on C and its derivatives.

--
Paulo

On Thursday, 30 October 2014 at 10:18:27 UTC, eles wrote:
> who'd written C++ from the beginning. He said he could never remember whether his variables were referenced or dereferenced, so he always used pointers. He said the little asterisk always reminded him..

One alternative is to have two assignment operators and two equality operators

ref(Something) a :- new Something(1)
ref(Something) b :- new Something(2)
ref(Something) c;

c :- a; // c now points to a
c := b; // a now contains the value of b

assert(a=b); // same value
assert( ! (a==b)); // not same object

On Thursday, 30 October 2014 at 10:24:19 UTC, Paulo  Pinto wrote:
> In 30 years of coding I never found this to be a problem and it saved a lot of bad pointers being passed on to functions.

Why bad pointers, they are typesafe?

What I dislike the most about C ptrs is this:  "ptr->field" vs "object.field"