Of course now programmers rely on Git and Mercurial, there is likely no chance of people giving up on hierarchies of text files as the way of storing code.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2013-01-16 at 03:54 +0100, Rob T wrote:
[…]
> I was just a while ago thinking that a reason why text based programming has been so predominant may be that the ability to transmit and discuss programming problems are much easier to do when the program is represented in written form.

But this does not predicate that the stored form is a text file, just that it has to have a text rendering.

> The minute you move to what could be a much more efficient and effective method of programing, you suddenly lose the ability to easily transmit the source code to other people. For example, it is very easy to post code samples in this forum for discussion, but if we represented programs in graphical form, we would have to upload images instead which not quite as easy to do.

Why?

Smalltalk embodied all these problems and Smalltalk programmers have no difficulty sharing.

> Another issue at hand, is when collaborating over the wire with Git and other revision control systems, none of them operate effectively when using encoding methods that are not text based. Revision control systems just don't work well with binary files.

This is a big problem even with binary diff techniques. This is likely the molehill that will be turned into a mountain so as to preserve the standard model of text files for source code.

> Having said this, there may still be better ways of representing programs that do not lose the advantages of text based programming, but what those methods look like is not so obvious.

See Smalltalk.

The problem to solve is how to not rely on images the way Smalltalk does. This was a soluble problem 20 years ago but no-one with money was interested. Hopefully in the coming finding round the modern versions of those ideas will get funded.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 1/15/2013 2:58 AM, Russel Winder wrote:
> The issue is that having a single global style standard for a
> programming language makes it easier to read code in that language.

Yup, it's better even if there are parts of it one doesn't like.

On Wednesday, 16 January 2013 at 01:29:24 UTC, Rob T wrote:
> On Wednesday, 16 January 2013 at 01:03:36 UTC, Peter Alexander wrote:
>>
>> There's nothing stopping a more superior method from still using the keyboard.
>>
>> What amazes me is how much language complexity is added just to make text editing more bearable.
>
> I agree, and consider this discussion as being a part of that complexity. We're accomplishing nothing of much importance really by aligning columns and adjusting font size, it's arcane.



I actually find aligning columns to be extremely handy, assuming your editor has column-editing ability.

When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually.

On 1/15/2013 9:32 AM, F i L wrote:
> sorry if this has already been posted, but Phoronix did an article on John
> Carmack's words as well, and the forum discussion has a bit of talk about D in
> it (specifically how it compares to C++).
>
> http://phoronix.com/forums/showthread.php?76719-John-Carmack-s-Comments-On-C-C#post306255
>

Thanks, it's an interesting thread.

> When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually.

When you have a ton of similar lines of code, you'd better start thinking about templates or mixins :P

Also, in regard of "new approach" to programming - is there a single method of interaction out there that is more efficient than plain text? It is kind of descriptive that we have so many different Desktop Environments and power users still prefer terminal everywhere.

On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
>> When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually.
>
> When you have a ton of similar lines of code, you'd better start thinking about templates or mixins :P


Easy to say in theory, but makes absolutely no sense in many cases. =P

Example:
boost::unordered_set<int> foo;
boost::unordered_map<int> bar;


and now I want to change 'boost' to 'std' because C++11 came out.

Templates? Mixins? wtf lol

On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
> On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
>>> When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually.
>>
>> When you have a ton of similar lines of code, you'd better start thinking about templates or mixins :P
>
>
> Easy to say in theory, but makes absolutely no sense in many cases. =P
>
> Example:
> boost::unordered_set<int> foo;
> boost::unordered_map<int> bar;
>
>
> and now I want to change 'boost' to 'std' because C++11 came out.
>
> Templates? Mixins? wtf lol

Another example:

template<class T> struct foo
{
	int x;
	int operator+(int) const { }
	int operator-(int) const { }
	int operator*(int) const { }
};

template<class T> int foo<T>::operator+(int x) const { return this->x + x; }
template<class T> int foo<T>::operator-(int x) const { return this->x - x; }
template<class T> int foo<T>::operator*(int x) const { return this->x * x; }



let's say now I want to add a new template parameter, class U, to all the functions.



If you can teach me how "templates" or "mixins" would solve my problem here I'd love to know.

On Wednesday, 16 January 2013 at 18:42:38 UTC, Mehrdad wrote:
> On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
>> On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
>>>> When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually.
>>>
>>> When you have a ton of similar lines of code, you'd better start thinking about templates or mixins :P
>>
>>
>> Easy to say in theory, but makes absolutely no sense in many cases. =P
>>
>> Example:
>> boost::unordered_set<int> foo;
>> boost::unordered_map<int> bar;
>>
>>
>> and now I want to change 'boost' to 'std' because C++11 came out.
>>
>> Templates? Mixins? wtf lol
>
> Another example:
>
> template<class T> struct foo
> {
> 	int x;
> 	int operator+(int) const { }
> 	int operator-(int) const { }
> 	int operator*(int) const { }
> };
>
> template<class T> int foo<T>::operator+(int x) const { return this->x + x; }
> template<class T> int foo<T>::operator-(int x) const { return this->x - x; }
> template<class T> int foo<T>::operator*(int x) const { return this->x * x; }
>
>
>
> let's say now I want to add a new template parameter, class U, to all the functions.
>
>
>
> If you can teach me how "templates" or "mixins" would solve my problem here I'd love to know.

This is a single template operator in D so it kind of solves the problem. First is tricky, but is exactly the reason sometimes types from external libs are used only via alias/typedef. I'd prefer something like :%s/boost::unord/std::unord/g though :) But well, if you are working with C++, then templates and mixins will hardly solve most problems of course, because C++ templates sucks and mixins do not even exist there.

On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:
>
> This is a single template operator in D so it kind of solves the problem. First is tricky, but is exactly the reason sometimes types from external libs are used only via alias/typedef. I'd prefer something like :%s/boost::unord/std::unord/g though :) But well, if you are working with C++, then templates and mixins will hardly solve most problems of course, because C++ templates sucks and mixins do not even exist there.



Yeah I'm working in C++, not D.


But even if I was using D, there's no way in heck that I would use a _MIXIN_ for that:

mixin("I'm not sure how this is supposed too be readable").unordered_map!(int) a;

makes no sense to me at all, when I could just as well have said 'boost'.



Also, the search/replace thing won't work so well for any real-world example (the second one is a lot closer to what I had in mind... you can't just replace "T" with "T, U" and expect it to work).


So my point is: no, it's not a simple matter of abstracting things away. Lined-up text really DOES make certain tasks easier than they would be otherwise.