On Sunday, 27 January 2013 at 14:14:18 UTC, Dicebot wrote:
> Text is still most efficient form of providing information. Please call me back when something better will be invented. Then we can speak about minimal editing environment for it.

Okay, here's what I invented in 5 minutes that would be better than plain text:

* Arguments to a function call would go, instead of inside parentheses, inside a box with a solid, black border and some nice and unique background color.

* Template arguments would go in a box with a hatched border line and a different background color.

* Blocks are, instead of surrounded by braces, indicated by this thing that looks like a tall, black, thin, right-opening square bracket that spans the whole block and sits directly to the left of the left-most characters of the statements inside the block.

* Instead of having '*' indicate both "multiply" and "dereference", invent and use a new symbol that means "dereference". The same goes for all symbols, like '&', '!', '~', '@', that don't have a universally defined meaning that corresponds to its meaning in language X.

In order to input those "things that are not symbols found on your keyboard", you'd either need to learn keyboard shortcuts by heart, or use a custom keyboard, which is what tv and movie editors have done for 20 years with their Avid keyboards. Most other creative jobs require custom tools for performing the craft, why not programming?

On Sunday, 27 January 2013 at 15:09:10 UTC, TommiT wrote:
> On Sunday, 27 January 2013 at 14:14:18 UTC, Dicebot wrote:
>> Text is still most efficient form of providing information. Please call me back when something better will be invented. Then we can speak about minimal editing environment for it.
>
> Okay, here's what I invented in 5 minutes that would be better than plain text:
>
> * Arguments to a function call would go, instead of inside parentheses, inside a box with a solid, black border and some nice and unique background color.
>
> * Template arguments would go in a box with a hatched border line and a different background color.
>
> * Blocks are, instead of surrounded by braces, indicated by this thing that looks like a tall, black, thin, right-opening square bracket that spans the whole block and sits directly to the left of the left-most characters of the statements inside the block.
>
> * Instead of having '*' indicate both "multiply" and "dereference", invent and use a new symbol that means "dereference". The same goes for all symbols, like '&', '!', '~', '@', that don't have a universally defined meaning that corresponds to its meaning in language X.
>
> In order to input those "things that are not symbols found on your keyboard", you'd either need to learn keyboard shortcuts by heart, or use a custom keyboard, which is what tv and movie editors have done for 20 years with their Avid keyboards. Most other creative jobs require custom tools for performing the craft, why not programming?

And how it is any better? Also D sources are unicode, so last two are possible just now and you need no special keyboard for it. Still the same good old text.

On Sunday, 27 January 2013 at 15:22:34 UTC, Dicebot wrote:
> And how it is any better? Also D sources are unicode, so last two are possible just now and you need no special keyboard for it. Still the same good old text.

I don't know if what I invented is any better, but my attempt was to make something that's easier to read and less ambiguous than plain text. For example parenthesis would be used only to define the order in which expressions are evaluated, and _not_ to indicate a section of arguments.

But are you really arguing that: "there can be nothing better than plain text for programmers to declare their intent". I wonder why we even have graphic operating systems, if graphic elements don't make thing easier to use and understand.

To me, saying that "D is bad language, because in order to most effectively write and understand the code requires some dedicated software" is like saying "Avid is a bad editing software, because using it most effectively requires some custom keyboard". You can write and understand D code, where parentheses of nullary function calls have been omitted, in notepad - it just may not be most optimal environment. Just like you can use Avid with a regular keyboard, it just may not be most optimal to do so (unless you remember all the keys by heart already).

On Sun, Jan 27, 2013 at 04:09:09PM +0100, TommiT wrote: [...]
> Most other creative jobs require custom tools for performing the craft, why not programming?

Because it's not *necessary*. Having a universal representation has many advantages, *independence* from custom tools, scriptability, testability, etc..

Independence from specialized tools, contrary to popular opinion, is a very good thing. Having a universal representation like text lets *anyone* write tools for it easily, and more importantly, tools that can work with more than just that specific representation. This is incentive for people to actually invest the effort to make said tools, because the target market is much wider (==lower risk, greater ROI). It also lets more tools than the creators of the thing being represented thought of to be used for manipulating it -- i.e., saves them the effort of reinventing an entire ecosystem, you just leverage what's already out there. Having specialized representations means that far fewer tools can be used for manipulating it, and these tools must be specifically made for the job. Why artificially limit yourself in this way, when generic formats and generic tools are far more useful?

Always reminds me of the difficulty of automating the test of GUI apps. You need specialized software to record interactions and replay them, whereas with a text-based interface, you can *generate* test cases that no human has ever done before, thereby making it possible to have more complete coverage than would be possible with any record/replay-based system. GUI apps are also non-scriptable, which greatly limits their usability in automated environments. Recorded GUI scripts are also usually in a non-interoperable format, which makes sharing / editing by others, etc., more difficult than necessary.

Obligatory quote:

	A program should be written to model the concepts of the task it
	performs rather than the physical world or a process because
	this maximizes the potential for it to be applied to tasks that
	are conceptually similar and, more important, to tasks that have
	not yet been conceived. -- Michael B. Allen

I see many more disadvantages to things like colors, fonts, reliance on specific tools, than advantages. Things that artificially limit themselves for no good reason other than convenience are rarely worth the trouble.

(Caveat: I'm another slobbering vim fanatic. I don't even use syntax highlighting. So you may take a big grain of salt with everything I say. :-P)


T

-- 
The richest man is not he who has the most, but he who needs the least.

On Sun, Jan 27, 2013 at 04:42:39PM +0100, TommiT wrote: [...]
> But are you really arguing that: "there can be nothing better than plain text for programmers to declare their intent". I wonder why we even have graphic operating systems, if graphic elements don't make thing easier to use and understand.
[...]

I wonder the same thing too. I'm a CLI fanatic. ;-)

And in fact, I honestly find GUI's a pain to use, due to their non-scriptability and needless reliance on the rodent. Yes, it makes things more appealing to the eye, but easier to use is arguable (there are too many GUI apps out there that are clearly written by people who have no idea what UI design means), and ease of understanding is also questionable (ever used a GUI app with icons that require clairvoyance to figure out what it means?).

Some tasks are more suited for GUI interfaces, like image editing, 3D modelling, etc.. But I find GUIs to be an unnecessary waste of resources on most other tasks.

But yes, I know I'm in the minority, and I'm quite OK with that.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.

On Sunday, 27 January 2013 at 15:42:40 UTC, TommiT wrote:
> On Sunday, 27 January 2013 at 15:22:34 UTC, Dicebot wrote:
>> And how it is any better? Also D sources are unicode, so last two are possible just now and you need no special keyboard for it. Still the same good old text.
>
> I don't know if what I invented is any better, but my attempt was to make something that's easier to read and less ambiguous than plain text. For example parenthesis would be used only to define the order in which expressions are evaluated, and _not_ to indicate a section of arguments.
>
> But are you really arguing that: "there can be nothing better than plain text for programmers to declare their intent". I wonder why we even have graphic operating systems, if graphic elements don't make thing easier to use and understand.
>
> To me, saying that "D is bad language, because in order to most effectively write and understand the code requires some dedicated software" is like saying "Avid is a bad editing software, because using it most effectively requires some custom keyboard". You can write and understand D code, where parentheses of nullary function calls have been omitted, in notepad - it just may not be most optimal environment. Just like you can use Avid with a regular keyboard, it just may not be most optimal to do so (unless you remember all the keys by heart already).

More noise -> not easier to read. It may has a merit when designing grammar unambiguous for reader with limited symbol count is impossible but otherwise simple unambiguous representation beats complex one. Also your proposal is not very different from plain text, it is about on the level of syntax highlighting.

We do have graphic operating systems and power users still do use consoles/shells for advanced operating system-related work. Because graphic elements are easier to understand, but harder (less efficient) to use. I am perfectly fine with relaxed mouse clicking when I am browsing or watching films or whatever, but when I do work - please, give me a pair of my trusted text shells.

I don't know what Avid is but if it requires custom keyboard for proper usage - it is either bad or targeted to users with weak computer competence (and googling shows it is some audio editing stuff, this second option is likely).

On Sunday, 27 January 2013 at 15:59:42 UTC, Dicebot wrote:
> I don't know what Avid is but if it requires custom keyboard for proper usage - it is either bad or targeted to users with weak computer competence (and googling shows it is some audio editing stuff, this second option is likely).

I was referring to Avid video editing software, which has been used for pretty much all movies and tv series made since 1990. There you can see the custom keyboard in its natural environment:

http://meganandtimmy.com/wp-content/uploads/2012/04/Avid.jpeg

But this is getting really far from the subject now.

On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
> ... but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad.

I think we have been throwing the term ambiguous around too carelessly. Obviously code must be semantically unambiguous when viewed in a Notepad. I don't think that's an issue with optional parentheses - the issue is just that it's "not as easy to read", which I don't think means the same as ambiguous (I'm sure about all english words though). "Not as easy to read" shouldn't sound nearly as bad as ambiguous - it's just a little inconvenience that can be gotten rid of by using an IDE that does semantic colorization.

On Sunday, 27 January 2013 at 17:19:15 UTC, TommiT wrote:
> On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
>> ... but at scope level semantics for reader should be perfectly clear and unambiguous even if opened in notepad.
>
> I think we have been throwing the term ambiguous around too carelessly. Obviously code must be semantically unambiguous when viewed in a Notepad. I don't think that's an issue with optional parentheses - the issue is just that it's "not as easy to read", which I don't think means the same as ambiguous (I'm sure about all english words though). "Not as easy to read" shouldn't sound nearly as bad as ambiguous - it's just a little inconvenience that can be gotten rid of by using an IDE that does semantic colorization.

"easy to read" == "I can find part of code that interests me easily"
"unambiguous" == "I can understand semantics of code I have just read with as little additional context as possible"

Ambiguity is mentioned often because there is one for compiler and one for programmer. Those two are sometimes similar but rather different in nature.

On 01/27/2013 09:26 AM, Andrei Alexandrescu wrote:
>
> Language adoption is a complex phenomenon with many variables, and it's
> easy to neglect certain aspects when assessing the impact of others.

Indeed it is, as you show below.

> Java started as a well-designed language albeit small and underpowered.
> It enjoyed the benefit of unwavering support from a large corporation
> and an estimated one billion dollars in marketing budget. (I remember in
> 1998 non-programming managers in NYC were talking "we must adopt Java!"
> without even knowing what Java meant. Java may as well be the only
> programming language in history to enjoy management support before
> programmer support.)

First off, where do you get this billion dollar marketing figure from? I've seen it from you before, with no citation, and could find no such citation myself when doing a Web search.

Second, Java was a "right place, right time" language. It was initially pegged for consumer devices, and was part of a bid to get cable company adoption for a TV add-on device, but when that fell flat it occurred to them the Web was a good fit. It was (in theory, but not in practice -- Flash ended up winning the browser), the hype machine exploded, and the rest is history. For example, if you read this article here:

http://vidlar.powweb.com/internett/the-java_net/history.html

...you'll see their growth was fairly organic. Yes, I'm sure they had a marketing budget, but I highly doubt that in 1998 they were spending $1 billion.

> That has caused Java to evolve quite differently from languages with
> grass-roots support (e.g. C++, Ruby, PHP, or Python). Generally the
> latter languages grew with little tooling support aside from the
> traditional Unix toolset, and that is to some extent reflected in the
> languages themselves.

One thing you're missing about Java is that because of it's simplicity of design and static typing, it was so easy to write tools for. No crazy macros or templates, and lots of type information.

> The same goes about C#, which was designed from day 1 assuming resources
> are available for dedicated tooling support. It would have evolved
> differently otherwise, and I assume many people would have a dimmer view
> of either Java or C# if they had to use it with vim and emacs.

That may be true for C#, but in the early days for Java I don't recall an IDE out of the box from Sun. For many it was emacs or whatever, then there was JBuilder (from Borland), and then IBM and IntelliJ, etc.