www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs Go on reddit

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0
Feb 02 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


Wow, dumbass Google fanboys are just pouring out of the woodworks.
Feb 02 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


If a person looks at the history of computer languages, she sees thousands of
languages. Many of them were lot of work to be created, and most of them have
failed, over and over again. This has happened even to languages better than
many other languages present at their time, and when you see this you get sad.

And then there are language extensions / modifications. Researchers and
students have created hundreds of extensions to the C and Java languages, but
most of those extensions are forgotten, lot of wasted work.

Few of the failed languages, like Algol, have given part of their ideas to
successive languages that have succeed.

Some languages aren't meant to become widespread, they are just research toys.
Despite they usually die quickly, later some of their ideas find their place in
more widespread languages like Java, Haskell, OCaML, Scala, etc, so sometimes
that work is not wasted.

Designing a new language is a bet, the success probability is quite low. Even
if the language is good and it's backed by a strong firm, the probability of
failure is very real.

Software is an important part of our planetary civilization, and even small
improvements in creating it are able to influence society. So despite all,
designing a good new language is a lot of fun and it's very hard, and even if
it's a low probability bet, it's worth doing it.

Language designers usually create more than one language in their life, and
sometimes they design many languages. So even if the success probability is
low, trying again and again sometimes gives them a positive result :-) A good
language designer is more important than the design of a single language.

Bye,
bearophile
Feb 02 2011
parent reply spir <denis.spir gmail.com> writes:
On 02/02/2011 10:37 PM, bearophile wrote:

 If a person looks at the history of computer languages, she sees thousands of
languages. Many of them were lot of work to be created, and most of them have
failed, over and over again. This has happened even to languages better than
many other languages present at their time, and when you see this you get sad.


Like in any other domain in our civilisation, the (hum) "success" (in social 
sense: fame, power, money) of a programming language has exactly nothing to do 
with its quality.
Actually, I rather think the opposite: that deep reasons allowing the creation 
of a Good Thing play against its social success (could hardly explain this 
clearly); and conversely. I would for instance blindly bet 1000€ (or $, or
£) 
that in, say, 18 months, Go will have reached a higher level of success D will 
ever reach. Nothing to do with quality.
I also bet Go not only will never be a good language, compared to other modern 
ones in the same field, but will quickly become a big mess, and worse and 
worse; while loads of people will sing for its fame (and more and more of them, 
more and more loudly).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1206.1296697460.4748.digitalmars-d puremagic.com...

 On 02/02/2011 10:37 PM, bearophile wrote:

 If a person looks at the history of computer languages, she sees 
 thousands of languages. Many of them were lot of work to be created, and 
 most of them have failed, over and over again. This has happened even to 
 languages better than many other languages present at their time, and 
 when you see this you get sad.


 Like in any other domain in our civilisation, the (hum) "success" (in 
 social sense: fame, power, money) of a programming language has exactly 
 nothing to do > with its quality.
 Actually, I rather think the opposite: that deep reasons allowing the 
 creation of a Good Thing play against its social success (could hardly 
 explain this clearly); and conversely. I would for instance blindly bet 
 1000? (or $, or £) that in, say, 18 months, Go will have reached a higher 
 level of success D will ever reach. Nothing to do with quality.
 I also bet Go not only will never be a good language, compared to other 
 modern ones in the same field, but will quickly become a big mess, and 
 worse and worse; while loads of people will sing for its fame (and more 
 and more of them, more and more loudly).


Wouldn't surprise me in the least. That's exactly what happened with Java.
Feb 03 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


I have one comment about one thing said by bnolsen:


Simplicity + Orthogonality == win.<


What I want most is the language features to be implemented in a clean way,
with a clear semantics, with very few bad interactions with other language
features and very few pitfalls, and with a good clean syntax. If this is done
well enough, then I am able to learn and use hundreds of features too (and lots
of keywords).

So the main problem I have with C++ is not its number of features (D seems to
have a comparable number of them), but how brittle they are, how many corner
cases they have, how many traps they have when you combine them with other
language features. This is not just a lack of orthogonality.

Bye,
bearophile
Feb 02 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/03/2011 12:31 AM, bearophile wrote:

 Walter:


 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 I have one comment about one thing said by bnolsen:


 Simplicity + Orthogonality == win.<




I would like people who state such phrases to all spend 3 months (only) 
programming exclusively in Oberon. From some point of view, it may probably be 
considered the best language ever. Twice as expressive as Modula with half of 
its features. It brings one the full power of imperative, structured, 
object-oriented paradigms in a language /completely/ described in 13 (!) pages 
of plain text.
It is a wonderful incarnation of the core any modern language should possess, 
and how to do it properly. Language designers of the mainstream paradigm could 
just start with Oberon as a clean, pure, safe, pedestal and just build on it.
For a full set of reasons, probably, Oberon has not had any success. Among them 
(?) the obsession of those guys at ETH ZĂ¼rich at /not/ considering
practicality 
as beeing of any worth, I guess ;-) This transforms programming in Oberon --a 
potentially enthusiasmic experience at first sight-- into a battle of every 
instant against irritating corners, annoying lacks, and against oneself to not 
explode one's screen out of frustration.


 What I want most is the language features to be implemented in a clean way,
with a clear semantics, with very few bad interactions with other language
features and very few pitfalls, and with a good clean syntax. If this is done
well enough, then I am able to learn and use hundreds of features too (and lots
of keywords).


Oberon is all what you ask for in the first sentence. On the other hand, just 
/listing/ features D provides and Oberon does not would require pages. 
Actually, its feature set is radically minuscule (and even more when compared 
to its expressive power, I guess); this does not ensure cleanness, consistency 
and orthogonality, indeed; but it may be impossible to achieve those qualities 
as soon as features grow in number and, primarily, in diversity. I guess, in 
fact, it is extremely difficult even for super simple toy languages. Successes 
(from this point of view) like Oberon are rarissim as far as I know. (*)

Denis

(*) Even Pascal & Modula did not reach this point; precisely, Oberon abandoned 
some of their features like enums and subrange types.
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 02 2011
parent "Paulo Pinto" <pjmlp progtools.org> writes:
I had the oportunity to watch a presentation from Nikolaus Wirth, back in
2003, when I was at CERN.

One of the reasons that prevented Oberon to get better audience was the 
tunnel
vision of its ETHZ creators.

I remember that they were talking about it as it is the best language in the 
world, and
everyone else is a sad fool not to understand it, but will eventually 
discover the real language.

Having said this, I find the language quite nice and it is a good live 
example how to create a simple
systems programming language with GC, which allows the creation of a real 
operating system.

Funny enough, the way Go binds methods to interfaces is similar to Component 
Pascal, an Oberon's
sucessor.

--
Paulo



"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1205.1296696481.4748.digitalmars-d puremagic.com...

 On 02/03/2011 12:31 AM, bearophile wrote:

 Walter:


 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 I have one comment about one thing said by bnolsen:


 Simplicity + Orthogonality == win.<




 I would like people who state such phrases to all spend 3 months (only) 
 programming exclusively in Oberon. From some point of view, it may 
 probably be considered the best language ever. Twice as expressive as 
 Modula with half of its features. It brings one the full power of 
 imperative, structured, object-oriented paradigms in a language 
 /completely/ described in 13 (!) pages of plain text.
 It is a wonderful incarnation of the core any modern language should 
 possess, and how to do it properly. Language designers of the mainstream 
 paradigm could just start with Oberon as a clean, pure, safe, pedestal and 
 just build on it.
 For a full set of reasons, probably, Oberon has not had any success. Among 
 them (?) the obsession of those guys at ETH Zürich at /not/ considering 
 practicality as beeing of any worth, I guess ;-) This transforms 
 programming in Oberon --a potentially enthusiasmic experience at first 
 sight-- into a battle of every instant against irritating corners, 
 annoying lacks, and against oneself to not explode one's screen out of 
 frustration.


 What I want most is the language features to be implemented in a clean 
 way, with a clear semantics, with very few bad interactions with other 
 language features and very few pitfalls, and with a good clean syntax. If 
 this is done well enough, then I am able to learn and use hundreds of 
 features too (and lots of keywords).


 Oberon is all what you ask for in the first sentence. On the other hand, 
 just /listing/ features D provides and Oberon does not would require 
 pages. Actually, its feature set is radically minuscule (and even more 
 when compared to its expressive power, I guess); this does not ensure 
 cleanness, consistency and orthogonality, indeed; but it may be impossible 
 to achieve those qualities as soon as features grow in number and, 
 primarily, in diversity. I guess, in fact, it is extremely difficult even 
 for super simple toy languages. Successes (from this point of view) like 
 Oberon are rarissim as far as I know. (*)

 Denis

 (*) Even Pascal & Modula did not reach this point; precisely, Oberon 
 abandoned some of their features like enums and subrange types.
 -- 
 _________________
 vita es estrany
 spir.wikidot.com
Feb 03 2011
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
bearophile wrote:

 Walter:
=20

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_=




major_win32_treats_now/c1f62a0

=20
 I have one comment about one thing said by bnolsen:
=20

 Simplicity + Orthogonality =3D=3D win.<


=20


	Then why has not Lisp won over all competition years ago?

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Feb 03 2011
next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/3 "J=C3=A9r=C3=B4me M. Berger" <jeberger free.fr>:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0Then why has not Lisp won over all competition=


 years ago?

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jerome


You mean why(not(has(won(lisp,all(competition)),years_ago))) ?

Jokes aside, I think people in language-debates often forget that
high-level languages are really just layers of syntactical sugar over
machine-code. ASM is syntactical sugar over machince-code, C is
syntactical sugar over ASM, and D is mostly syntactic sugar over C.
They are merely ways to streamline certain programming-models, into a
language that encourages those idioms and constructs. Just about
anything that can be written in D, can be written with equivalent
semantics in C, but the D-version is likely to be faster to write, and
faster to comprehend.

The purpose of higher-level languages is to encourage "good"
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.
Feb 03 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Ulrik Mikaelsson:


 Jokes aside, I think people in language-debates often forget that
 high-level languages are really just layers of syntactical sugar over
 machine-code.


There are type systems too, and sometimes they become very refined (see ATS
language, etc).

Bye,
bearophile
Feb 03 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Ulrik Mikaelsson wrote:

 The purpose of higher-level languages is to encourage "good"
 programming style and readability. Period. The syntax is crucial here,
 it determines which constructs will become readable, and which won't,
 which in turn determines the mind-set of the programmer. Which is why
 I consider syntactic sugar to be seriously under-appreciated and
 undervalued in many language decisions.



That's one way to put it. I view a programming language as a way to map the way 
humans think into the way the machine works. Orthogonal languages have a 
mathematical simplicity to them, but (as one quickly discovers when trying to 
implement a good user interface) people are just not orthogonal and do not
think 
in an orthogonal matter. Good user interfaces tend to be enormously complex 
under the hood, all to create a "simple, intuitive" interface?

For example, why have do-while loops, while loops, for loops and foreach loops? 
Only one is really needed in an orthogonal language. The multiple forms persist 
in language after language because they fit the idiosyncracies of how our
brains 
think about coding.

As many of you know, I like to work on my cars. My emergency toolkit has just a 
small handful of simple tools, like a screwdriver. I can use a screwdriver as a 
screw driver, a hammer, a lever, a chisel, a punch, a scraper, a mixer, even a 
bus bar (to short across the starter relay). It's good enough at those things
to 
get me home.

But when I'm home, I reach for a tool designed specifically for the purpose. 
That means I've got a lot of tools. Yup.

I kind of view the "complexity" of D that way. There are a lot of tools in it 
for specific jobs. Yes, I could get the job done with a screwdriver and monkey 
wrench, but it would be ugly. I can do lambdas and closures and virtual 
functions in vanilla C, too, it's just darned messy, unappealing, time
consuming 
and far more likely to skin my knuckles.
Feb 03 2011
parent spir <denis.spir gmail.com> writes:
On 02/03/2011 07:43 PM, Walter Bright wrote:

 That's one way to put it. I view a programming language as a way to map the way
 humans think into the way the machine works. Orthogonal languages have a
 mathematical simplicity to them, but (as one quickly discovers when trying to
 implement a good user interface) people are just not orthogonal and do not
 think in an orthogonal matter. Good user interfaces tend to be enormously
 complex under the hood, all to create a "simple, intuitive" interface?

 For example, why have do-while loops, while loops, for loops and foreach loops?
 Only one is really needed in an orthogonal language. The multiple forms persist
 in language after language because they fit the idiosyncracies of how our
 brains think about coding.


Waow, that's just how I see the job of language design!

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 03 2011
prev sibling parent so <so so.do> writes:
 Jokes aside, I think people in language-debates often forget that
 high-level languages are really just layers of syntactical sugar over
 machine-code. ASM is syntactical sugar over machince-code, C is
 syntactical sugar over ASM, and D is mostly syntactic sugar over C.
 They are merely ways to streamline certain programming-models, into a
 language that encourages those idioms and constructs. Just about
 anything that can be written in D, can be written with equivalent
 semantics in C, but the D-version is likely to be faster to write, and
 faster to comprehend.

 The purpose of higher-level languages is to encourage "good"
 programming style and readability. Period. The syntax is crucial here,
 it determines which constructs will become readable, and which won't,
 which in turn determines the mind-set of the programmer. Which is why
 I consider syntactic sugar to be seriously under-appreciated and
 undervalued in many language decisions.


One argument i often encounter about features, syntax in language  
discussions is "What namespaces can do that namespace_func can't?".
Answer might be pretty obvious to many, but consider the corner cases of  
some namespace implementations. (C++ here)

You simply can't provide a clean library with the given namespace features.

---
namespace ns1 {
	class A;
	....
}

namespace ns2 {
	
	class C {
		A* pa;
	};
}
---

but in D it is quite elegant.

---
module ns2;
private import ns1;

class C {
	A* pa;
};
---
Feb 03 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/03/2011 07:16 PM, Ulrik Mikaelsson wrote:

 2011/2/3 "JĂ©rĂ´me M. Berger"<jeberger free.fr>:

         Then why has not Lisp won over all competition years ago?

                 Jerome


 You mean why(not(has(won(lisp,all(competition)),years_ago))) ?

 Jokes aside, I think people in language-debates often forget that
 high-level languages are really just layers of syntactical sugar over
 machine-code. ASM is syntactical sugar over machince-code, C is
 syntactical sugar over ASM, and D is mostly syntactic sugar over C.
 They are merely ways to streamline certain programming-models, into a
 language that encourages those idioms and constructs. Just about
 anything that can be written in D, can be written with equivalent
 semantics in C, but the D-version is likely to be faster to write, and
 faster to comprehend.


The first part of this paragraph says, imo, something different from the second 
part.
I think there are two kinds of features over a core language: ones are as you 
say plain sugar; others (let's call them conceptual) introduce new semantic 
notions. To distingish those 2 kinds, one needs to observe how translation of 
code involving a given feature into the core language is to be done:
* sugar features only require plain rewriting
* conceptual features require a transformation of the code

The purpose of PL design, imo, is to figure out what kinds of notions people 
use to "model" and define them in the language. Then, expressing a model 
holding such notions using this language is direct. If a given notion does not 
exist in the language used, then one needs to transform the model before beeing 
able to express it; then, the code does not look like what it means (or 
should). This is what I call "semantic distortion" (and others conceptual 
mismatch).

The above distinction of 2 kinds of features is taken from a document called 
(IIRC) "Expressive power of Programming languages", which itself builds on a 
similar distinction made in the field of logic formal languages.


 The purpose of higher-level languages is to encourage "good"
 programming style and readability. Period. The syntax is crucial here,
 it determines which constructs will become readable, and which won't,
 which in turn determines the mind-set of the programmer. Which is why
 I consider syntactic sugar to be seriously under-appreciated and
 undervalued in many language decisions.


Syntax & semantics play together in "linguistic" notions built into a language. 
Sugar features are purely syntactic, library features purely 
semantic/conceptual, linguistic features are both.

Trivial example: the notion of iteration expressed by 'foreach'. Why is it so 
successful, while it's usually trivial to do without it? I guess the reason is 
foreach expresses, as is, a notion that exists in the (mental) "language of 
modelling". Without foreach, one needs to transform this notion into different 
semantics, using a general purpose looping construct (while), also involving 
elements that do not belong to the model (node pointer, ordinal index,...).
Since this is an extremely common idiom, we are used to decode it as 
"iteration" at first sight. But the code does /not/ inherently express 
iteration by itself:

     foreach (node ; list) {
         auto element = node.element;
         doSomethingWith(element);
     }

     Node* node = list;
     while (node) {
         auto element = node.element;
         doSomethingWith(element);
         node = node.next;
     }


Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 03 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


You'd think that things like JS, Haskell, LISP and Java circa v1.2 would 
have taught people that extreme simplicity/orthogonality is a stupid way to 
design a language that's intended to be used in the real world. But people 
keep flocking to that silver bullet anyway.
Feb 09 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 02/09/2011 02:01 PM, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would
 have taught people that extreme simplicity/orthogonality is a stupid way to
 design a language that's intended to be used in the real world. But people
 keep flocking to that silver bullet anyway.


Yop! this said, I recently read (no pointer, sorry) about a possibly 
interesting third way: making the core language as close to orthogonal as 
possible w/o making the rest difficult, then build compromises as sugar layers 
around (syntactic & semantic).
This may be, actually, more or less close to how some actual languages are 
actually constructed; but I find that making this principle intentonal and 
intentional totally changes the whole approach. Also think this well fits the 
design of PL with a main/core paradigm/style (not so for D, probably).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 09 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1424.1297260589.4748.digitalmars-d puremagic.com...

 On 02/09/2011 02:01 PM, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would
 have taught people that extreme simplicity/orthogonality is a stupid way 
 to
 design a language that's intended to be used in the real world. But 
 people
 keep flocking to that silver bullet anyway.


 Yop! this said, I recently read (no pointer, sorry) about a possibly 
 interesting third way: making the core language as close to orthogonal as 
 possible w/o making the rest difficult, then build compromises as sugar 
 layers around (syntactic & semantic).
 This may be, actually, more or less close to how some actual languages are 
 actually constructed; but I find that making this principle intentonal and 
 intentional totally changes the whole approach. Also think this well fits 
 the design of PL with a main/core paradigm/style (not so for D, probably).


Yea, that seems to be the direction that post-v1.2 Java ended up taking. 
Still too little, too late, IMO, at least in the case of Java, but it may 
not necessarily be a bad idea.

Although I do like the inverse approach that D ended up taking: Don't bother 
with simplicity/orthogonality at first, just get important features in. 
*Then* refactor the internals to shuffle the complexity into the std lib and 
simplify the core language. (And, of course, use lowerings whenever 
appropriate.)

Funny though, right after I posted "You'd think that things like JS...", the 
obvious devil's-advocate counter-argument occurred to me: "You'd think that 
things like C++ and Algol would have taught people that complex languages 
are a stupid way to go." Oh well.
Feb 09 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 Funny though, right after I posted "You'd think that things like JS...", the 
 obvious devil's-advocate counter-argument occurred to me: "You'd think that 
 things like C++ and Algol would have taught people that complex languages 
 are a stupid way to go." Oh well.


What matters is if I can express a program in a simple, straightforward manner. 
Not if the implementation language is simple or not.

C++ fails at the former.
Feb 09 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/09/2011 11:43 PM, Nick Sabalausky wrote:

 Although I do like the inverse approach that D ended up taking: Don't bother
 with simplicity/orthogonality at first, just get important features in.
 *Then*  refactor the internals to shuffle the complexity into the std lib and
 simplify the core language. (And, of course, use lowerings whenever
 appropriate.)


I love that. I often program that way, at least up to a certain size/complexity.
I wouldn't even dare designing anything as big and complex as a PL using that 
approach. It's a question of amount of information and level of abstraction one 
is able to master, I guess. (I know from experience that my capacity of 
abstraction is not very powerful, esp compared to top-programmers).
Also, I would tend to conclude from (what I know of) D's past & present 
development history that it a good approach: leads to an eternal beta state (or 
even alpha)?


 Funny though, right after I posted "You'd think that things like JS...", the
 obvious devil's-advocate counter-argument occurred to me: "You'd think that
 things like C++ and Algol would have taught people that complex languages
 are a stupid way to go." Oh well.


Yes, orthogonality, simplicity,  lead to clarity. Which means people (with some 
rational skill) can far more easily grasp the system. But practical usability 
often requires breaking the nice, seducing, theoretical schemes. I guess. Or 
requires adding level of complexity to restore consistency after introducing 
practical features, notions, dictinctions. Veeery difficult.
But a language designed from the start on with only praticality in mind, with 
consistency not considered a design criterion, maybe does not even have a 
chance to become a beautiful, lovable and fun tool. C++. Except for toy cases,

denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 10 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 
 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would 
 have taught people that extreme simplicity/orthogonality is a stupid way to 
 design a language that's intended to be used in the real world. But people 
 keep flocking to that silver bullet anyway.


Yeah, I've been thinking of doing my next presentation on the topic of false 
simplicity.
Feb 09 2011
parent spir <denis.spir gmail.com> writes:
On 02/09/2011 08:47 PM, Walter Bright wrote:

 Nick Sabalausky wrote:

 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:iicfaa$23j7$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0


 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would have
 taught people that extreme simplicity/orthogonality is a stupid way to design
 a language that's intended to be used in the real world. But people keep
 flocking to that silver bullet anyway.


 Yeah, I've been thinking of doing my next presentation on the topic of false
 simplicity.


Great! I long for reading such a doc.
Had in mind an article titled "simplicity ==> difficulty". The point is that, 
when a PL predefines to few notions, and even more /distinctions/, then it 
becomes articially hard to express any non-trivial model. The "modeller" needs 
to reinvent the missing notions and distinctions, often in an unclear, adhoc, 
even unconscious, manner. (*)

denis

Notions: associative table, collection traversal, multi-way choice,...
Among distinctions I would love to see in PLs are:
* define vs modify (2 != assignments)
	a := 1	// error: a is undefined
	a = 1	// ok
	a = 2	// error: a is already defined
	a := 2	// ok
* thing vs value (things is an element with identity/ref)
* function (question) vs action (command)

-- 
_________________
vita es estrany
spir.wikidot.com
Feb 10 2011
prev sibling next sibling parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/9 spir <denis.spir gmail.com>:

 Yop! this said, I recently read (no pointer, sorry) about a possibly
 interesting third way: making the core language as close to orthogonal as
 possible w/o making the rest difficult, then build compromises as sugar
 layers around (syntactic & semantic).
 This may be, actually, more or less close to how some actual languages are
 actually constructed; but I find that making this principle intentonal and
 intentional totally changes the whole approach. Also think this well fits
 the design of PL with a main/core paradigm/style (not so for D, probably).


Isn't this how much of JavaScript is ACTUALLY used nowadays? jQuery,
YUI, PrototypeJS?

Coding for limited embedded hardware, I'm personally hand-coding
Javascript (without 3:d-party-libs) at work ATM, since I really need
to know all effects (especially on the DOM) of everything I do. (Is
something reading .offsetHeight? - i DEFINITELY need to know about
it.) Outside the realm of embedded/limited hardware though, it seems
few people are actually coding in pure JavaScript without
"convenience"-libraries. Maybe it's the ASM of next decade.
Feb 09 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Ulrik Mikaelsson" <ulrik.mikaelsson gmail.com> wrote in message 
news:mailman.1430.1297292203.4748.digitalmars-d puremagic.com...

 Maybe [JS is] the ASM of next decade.


There's been a lot of buzz about that. It's a thought I find horrifying. 
Hellraiser? Very cool. Child's Play? Downright *funny* at times. JS as the 
ASM of the future? Piss-my-pants, nightmares-all-month, frightening.
Feb 09 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.02.2011 23:56, schrieb Ulrik Mikaelsson:

 Maybe it's [JavaScript] the ASM of next decade.


Bringing the performance of the second last decades systems to hardware of the
next decade.
Hooray \o/
Feb 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ij3iru$k6k$2 digitalmars.com...

 Am 09.02.2011 23:56, schrieb Ulrik Mikaelsson:

 Maybe it's [JavaScript] the ASM of next decade.


 Bringing the performance of the second last decades systems to hardware of 
 the
 next decade.
 Hooray \o/


Not to mention the reliability of 90's desktops.
Feb 11 2011
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
You guys are way on the wrong track here.

I'm very much a fan of simple and orthogonal languages. But this 
statement has a big problem: it's not clear what one actually considers 
to be "simple" and "orthogonal". What people consider to be orthogonal 
can vary not only a little, but actually a lot. Sometimes it can 
actually vary so much as to be on opposite sides. I remember seeing that 
first hand here on D: two people were arguing for opposing things in D 
(I don't remember the particular issue, but one was probably a greater 
language change, the other as for the status quo, or a minor change from 
the status quo), and both explicitly argued that their alternative was 
more orthogonal! I remember thinking that one was stretching the notion 
of orthogonality a bit further than the other, but I didn't find any of 
them to actually be incorrect.

So people, please don't dismiss out of hand the principle that 
orthogonality is a very worthwhile design goal. Rather, this principle 
needs to be understood and applied in a more concrete and objective 
manner. It cannot be described in a simplistic one-liner ("more 
orthogonality is good." kthxbye!).
For starters, it only makes sense to evaluate the orthogonality of a 
language alongside the expressive power of the language. Otherwise the 
family of languages used in Turing machines (P′′, and even brainfuck) 
would be the unmatched best languages in terms of orthogonality. (the 
whole language can be described in a few paragraphs... so simple!)


On 09/02/2011 13:01, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iicfaa$23j7$1 digitalmars.com...

 




http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would
 have taught people that extreme simplicity/orthogonality is a stupid 


way to

 design a language that's intended to be used in the real world. But 


people

 keep flocking to that silver bullet anyway.


Eh?? What exactly has "JS, Haskell, LISP and Java" taught us in terms of 
"designing a language that's intended to be used in the real world"? You 
seem to be implying these language did something massively wrong... 
However Java became very popular and widespread (and the version of the 
language when such happened, 1.3-1.4, was very similar to Java v1.2). 
JavaScript is also quite popular and widespread, for a scripting 
language at least (and not only in web/HTML). Only Lisp has widely been 
acknowledge as a failure. Dunno about Haskell, maybe the jury is still 
out on that one.
But in any case your argument is already starting off in a bad way (in 
at least a 50% fuzzy manner).


Even if we were to imagine that all those 4 languages had been a 
failure, or become obsolete, your argument still wouldn't be much 
useful. Because:

Java - Yes, Java is simpler than it's predecessor (C/C++), but not in 
orthogonality. Java has less capabilities/functionality (like 
manipulating pointers, or creating structs), it is not more orthogonal.

LISP - LISP syntax is very orthogonal, but it pushes it the extreme, 
hurting readability. Also can one also say that LISP *semantics* are 
also very orthogonal? Even with the macro system, I doubt that is 
entirely the case for the generality of the language, although the true 
answer for this would depend on the particular dialect of LISP (my 
experience has been with Common Lisp and Scheme).

Don't know enough about Haskell. (And probably neither do you. Or anyone 
else for that matter, except /that/ handful of people in the whole 
world? :P )

As for JavaScript, well, this one I do agree, it is incredibly 
orthogonal, one of the very few languages I would say that, and quite 
beautiful in that way.
But regardless of all this, Lisp and JavaScript are not comparable to D 
with regards to trying to evaluate how much orthogonality is good or 
bad... because they are not even statically typed languages (also in the 
case of JavaScript there is no metaprogramming). Because of this, it 
will be much, much, more easy for them to orthogonal. Yet, if they fail, 
can we say it was the fault of being orthogonal? It could have been 
plenty of other things in the language design. (or even something 
entirely outside the design)


In my view of the /worthiness of orthogonality/, it only is useful to 
compare the simplicity of languages when the capabilities, 
functionality, and expressive power of such languages are more or less 
comparable...

-- 
Bruno Medeiros - Software Engineer
Feb 10 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:ij1guf$694$1 digitalmars.com...

 You guys are way on the wrong track here.

 I'm very much a fan of simple and orthogonal languages. But this statement 
 has a big problem: it's not clear what one actually considers to be 
 "simple" and "orthogonal". What people consider to be orthogonal can vary 
 not only a little, but actually a lot. Sometimes it can actually vary so 
 much as to be on opposite sides. I remember seeing that first hand here on 
 D: two people were arguing for opposing things in D (I don't remember the 
 particular issue, but one was probably a greater language change, the 
 other as for the status quo, or a minor change from the status quo), and 
 both explicitly argued that their alternative was more orthogonal! I 
 remember thinking that one was stretching the notion of orthogonality a 
 bit further than the other, but I didn't find any of them to actually be 
 incorrect.

 So people, please don't dismiss out of hand the principle that 
 orthogonality is a very worthwhile design goal. Rather, this principle 
 needs to be understood and applied in a more concrete and objective 
 manner. It cannot be described in a simplistic one-liner ("more 
 orthogonality is good." kthxbye!).
 For starters, it only makes sense to evaluate the orthogonality of a 
 language alongside the expressive power of the language. Otherwise the 
 family of languages used in Turing machines (P'', and even brainfuck) 
 would be the unmatched best languages in terms of orthogonality. (the 
 whole language can be described in a few paragraphs... so simple!)


 On 09/02/2011 13:01, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:iicfaa$23j7$1 digitalmars.com...




 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would
 have taught people that extreme simplicity/orthogonality is a stupid


 way to

 design a language that's intended to be used in the real world. But


 people

 keep flocking to that silver bullet anyway.


 Eh?? What exactly has "JS, Haskell, LISP and Java" taught us in terms of 
 "designing a language that's intended to be used in the real world"? You 
 seem to be implying these language did something massively wrong... 
 However Java became very popular and widespread (and the version of the 
 language when such happened, 1.3-1.4, was very similar to Java v1.2). 
 JavaScript is also quite popular and widespread, for a scripting language 
 at least (and not only in web/HTML). Only Lisp has widely been acknowledge 
 as a failure. Dunno about Haskell, maybe the jury is still out on that 
 one.
 But in any case your argument is already starting off in a bad way (in at 
 least a 50% fuzzy manner).


 Even if we were to imagine that all those 4 languages had been a failure, 
 or become obsolete, your argument still wouldn't be much useful. Because:

 Java - Yes, Java is simpler than it's predecessor (C/C++), but not in 
 orthogonality. Java has less capabilities/functionality (like manipulating 
 pointers, or creating structs), it is not more orthogonal.

 LISP - LISP syntax is very orthogonal, but it pushes it the extreme, 
 hurting readability. Also can one also say that LISP *semantics* are also 
 very orthogonal? Even with the macro system, I doubt that is entirely the 
 case for the generality of the language, although the true answer for this 
 would depend on the particular dialect of LISP (my experience has been 
 with Common Lisp and Scheme).

 Don't know enough about Haskell. (And probably neither do you. Or anyone 
 else for that matter, except /that/ handful of people in the whole world? 
 :P )

 As for JavaScript, well, this one I do agree, it is incredibly orthogonal, 
 one of the very few languages I would say that, and quite beautiful in 
 that way.
 But regardless of all this, Lisp and JavaScript are not comparable to D 
 with regards to trying to evaluate how much orthogonality is good or 
 bad... because they are not even statically typed languages (also in the 
 case of JavaScript there is no metaprogramming). Because of this, it will 
 be much, much, more easy for them to orthogonal. Yet, if they fail, can we 
 say it was the fault of being orthogonal? It could have been plenty of 
 other things in the language design. (or even something entirely outside 
 the design)


 In my view of the /worthiness of orthogonality/, it only is useful to 
 compare the simplicity of languages when the capabilities, functionality, 
 and expressive power of such languages are more or less comparable...


You seem to misunderstand. I never said that orthogonality or simplicity was 
bad. I just said that it was stupid to equate "more simple/orthogonal" with 
"better" and "less simple/orthogonal" with "worse". Ie, I was saying exactly 
the same thing about "orthoginality" as what you're saying. I beleive that 
as a consequence, it's dumb to make "simple/orthogonal" one of the primary 
design goals.

IMO, some examples of what happens when "simple/orthogonal" is given too 
much importance are Java2, JS, LISP and Haskell.

LISP: We seem to agree how having too much "simple/orthogonal" messed up 
LISP. LISP *is* emmensely popular in certain circles. But I believe that 
certain consquences of its over-emphasis on simple/orthogonal (ex: "Lost In 
Stupid Parenthesis") is a major part of what prevented it from ever finding 
its way outside its niche circles.

Haskell: Haskell has had *huge* buzz for awhile. Especially about 5 or so 
years ago, IIRC. And like a lot of people, I gave it a try. And like most 
people who did, I found its design to have such a strong emphasis on 
simple/orthogonal that it was too impractical to be worth the functional 
benefits it offered. Fast-forward to now, and there's *still* practically no 
one actually using it for real-world software development. Just some 
theoretical/academic stuff and that's about it.

JS: Widely-used != Good. I admit I'm also impressed by how much 
expressiveness it gets out of such few and simple rules (its handling of 
semicolons notwithstanding). But I find that to be largely academic. 
Granted, most of JS's biggest problems aren't direct consequences of its 
focus on simple/orthogonal, but there are things it could improve by 
shedding some of that focus. And more than that, it is a good example of the 
fact that "simple/orthogonal" doesn't necessarily imply "good".

Java circa-v1.2: I agree that fewer capabilites does not necessarily imply 
more orthogonality, and that LISP/JS are possibly more simple/orthogonal 
than Java's ever been. But I don't see how C++ can be considered anywhere 
near as simple/orthogonal as old-school Java. C++ is a giant cancerous web 
of rules, features and special cases. In old-school Java, you have GCed 
classes with member vars and member funcs...and that's about it.  No sugar 
at all: No 'foreach' because 'for' already handles that. No type inference 
because manually-tracked types can be used instead. It already had classes, 
so delegates had to be made out of them (ie, "functors" - and see that 
infamously idiotic paper Sun wrote defending this decision). It already had 
upcasting/downcasting, so generic code had to be constructed via those. 
Separate code-generating tools could be written (for instance, through the 
editor), so metaprogramming had to be done via that. Objects could have 
member functions, so it didn't bother allowing operator overloading - you 
could just use a named function instead. Etc...

All those features were missing because you could get the same effect with 
what few Java it did provide you - Ie, those extra features would have 
*decreased* orthogonality. It was immensely popular, but fitting everything 
into those few multi-purposed building blocks like that (ie, fairly 
simple/orthogonal components) also made it an immense PITA. Maybe not as 
much of a pain as C++ for certain things, but that's really more due to C++ 
being a giant anachronistic puss-filled wad rather than due to Java being 
more simple/orthogonal.

Regarding Java 1.3/1.4: They may very well have been closer to 1.2 than they 
were to 1.5/1.6 (I wouldn't know), but IIRC 1.3 was when it finally started 
to give people little bits of suger (ex: foreach).



 Feb 10 2011



 next sibling parent reply Jeff Nowakowski <jeff dilacero.org>  writes:


On 02/10/2011 10:08 PM, Nick Sabalausky wrote:

 Regarding Java 1.3/1.4: They may very well have been closer to 1.2 than they
 were to 1.5/1.6 (I wouldn't know), but IIRC 1.3 was when it finally started
 to give people little bits of suger (ex: foreach).


1.5 was when Java got foreach, generics, and enum. I don't think there 
were any syntactical language changes before that. Previous version 
updates were mostly about libraries and frameworks.



 Feb 11 2011



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Jeff Nowakowski wrote:

 1.5 was when Java got foreach, generics, and enum. I don't think there 
 were any syntactical language changes before that. Previous version 
 updates were mostly about libraries and frameworks.


Inner classes were added earlier.



 Feb 11 2011



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 11/02/2011 03:08, Nick Sabalausky wrote:

 "Bruno Medeiros"<brunodomedeiros+spam com.gmail>  wrote in message
 news:ij1guf$694$1 digitalmars.com...

 You guys are way on the wrong track here.

 I'm very much a fan of simple and orthogonal languages. But this statement
 has a big problem: it's not clear what one actually considers to be
 "simple" and "orthogonal". What people consider to be orthogonal can vary
 not only a little, but actually a lot. Sometimes it can actually vary so
 much as to be on opposite sides. I remember seeing that first hand here on
 D: two people were arguing for opposing things in D (I don't remember the
 particular issue, but one was probably a greater language change, the
 other as for the status quo, or a minor change from the status quo), and
 both explicitly argued that their alternative was more orthogonal! I
 remember thinking that one was stretching the notion of orthogonality a
 bit further than the other, but I didn't find any of them to actually be
 incorrect.

 So people, please don't dismiss out of hand the principle that
 orthogonality is a very worthwhile design goal. Rather, this principle
 needs to be understood and applied in a more concrete and objective
 manner. It cannot be described in a simplistic one-liner ("more
 orthogonality is good." kthxbye!).
 For starters, it only makes sense to evaluate the orthogonality of a
 language alongside the expressive power of the language. Otherwise the
 family of languages used in Turing machines (P'', and even brainfuck)
 would be the unmatched best languages in terms of orthogonality. (the
 whole language can be described in a few paragraphs... so simple!)


 On 09/02/2011 13:01, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>   wrote in message
 news:iicfaa$23j7$1 digitalmars.com...




 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

 You'd think that things like JS, Haskell, LISP and Java circa v1.2 would
 have taught people that extreme simplicity/orthogonality is a stupid


 way to

 design a language that's intended to be used in the real world. But


 people

 keep flocking to that silver bullet anyway.


 Eh?? What exactly has "JS, Haskell, LISP and Java" taught us in terms of
 "designing a language that's intended to be used in the real world"? You
 seem to be implying these language did something massively wrong...
 However Java became very popular and widespread (and the version of the
 language when such happened, 1.3-1.4, was very similar to Java v1.2).
 JavaScript is also quite popular and widespread, for a scripting language
 at least (and not only in web/HTML). Only Lisp has widely been acknowledge
 as a failure. Dunno about Haskell, maybe the jury is still out on that
 one.
 But in any case your argument is already starting off in a bad way (in at
 least a 50% fuzzy manner).


 Even if we were to imagine that all those 4 languages had been a failure,
 or become obsolete, your argument still wouldn't be much useful. Because:

 Java - Yes, Java is simpler than it's predecessor (C/C++), but not in
 orthogonality. Java has less capabilities/functionality (like manipulating
 pointers, or creating structs), it is not more orthogonal.

 LISP - LISP syntax is very orthogonal, but it pushes it the extreme,
 hurting readability. Also can one also say that LISP *semantics* are also
 very orthogonal? Even with the macro system, I doubt that is entirely the
 case for the generality of the language, although the true answer for this
 would depend on the particular dialect of LISP (my experience has been
 with Common Lisp and Scheme).

 Don't know enough about Haskell. (And probably neither do you. Or anyone
 else for that matter, except /that/ handful of people in the whole world?
 :P )

 As for JavaScript, well, this one I do agree, it is incredibly orthogonal,
 one of the very few languages I would say that, and quite beautiful in
 that way.
 But regardless of all this, Lisp and JavaScript are not comparable to D
 with regards to trying to evaluate how much orthogonality is good or
 bad... because they are not even statically typed languages (also in the
 case of JavaScript there is no metaprogramming). Because of this, it will
 be much, much, more easy for them to orthogonal. Yet, if they fail, can we
 say it was the fault of being orthogonal? It could have been plenty of
 other things in the language design. (or even something entirely outside
 the design)


 In my view of the /worthiness of orthogonality/, it only is useful to
 compare the simplicity of languages when the capabilities, functionality,
 and expressive power of such languages are more or less comparable...


 You seem to misunderstand. I never said that orthogonality or simplicity was
 bad. I just said that it was stupid to equate "more simple/orthogonal" with
 "better" and "less simple/orthogonal" with "worse". Ie, I was saying exactly
 the same thing about "orthoginality" as what you're saying. I beleive that
 as a consequence, it's dumb to make "simple/orthogonal" one of the primary
 design goals.


We must not be saying (or thinking) the same thing then, because I do 
think it is worthwhile to have orthogonality as one of the primary 
design goals.
I believe we are still not thinking of orthogonality in the same way. 
You seem to be thinking in terms of pure simplicity, how easy a language 
is to describe, learn and understand. I'm thinking of how much 
expressiveness you get per amount of "complexity" (how easy it is to 
describe, learn, and understand).


So considering C++ and Java again: then yes, C++ is much more complex 
than Java (even new-school Java, barring generics perhaps). But I never 
said otherwise. I did say that Java is not more orthogonal than C++, but 
not in the sense that Java is just as orthogonal as C++. Rather I was 
trying to say that the comparison doesn't make much sense in the first 
place, because Java has much less "capabilities". Like, you can compare 
D's meta-programming capabilites with C++, because in D you can do 
pretty much the same things as C++ (if not more) meta-programming-wise, 
yet the way things work in D are much more orthogonal, more simpler to 
describe and understand (and probably because of that, more powerful). 
The same comparison could be done with other features, like operator 
overloading between D and C++. But not between C++ and Java because 
doesn't support most of this functionality (and it doesn't make sense to 
compare with the Java alternatives)

-- 
Bruno Medeiros - Software Engineer



 Feb 16 2011



  parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com>  writes:


2011/2/16 Bruno Medeiros <brunodomedeiros+spam com.gmail>:

 We must not be saying (or thinking) the same thing then, because I do think
 it is worthwhile to have orthogonality as one of the primary design goals.
 I believe we are still not thinking of orthogonality in the same way. You
 seem to be thinking in terms of pure simplicity, how easy a language is to
 describe, learn and understand. I'm thinking of how much expressiveness you
 get per amount of "complexity" (how easy it is to describe, learn, and
 understand).


 So considering C++ and Java again: then yes, C++ is much more complex than
 Java (even new-school Java, barring generics perhaps). But I never said
 otherwise. I did say that Java is not more orthogonal than C++, but not in
 the sense that Java is just as orthogonal as C++. Rather I was trying to say
 that the comparison doesn't make much sense in the first place, because Java
 has much less "capabilities". Like, you can compare D's meta-programming
 capabilites with C++, because in D you can do pretty much the same things as
 C++ (if not more) meta-programming-wise, yet the way things work in D are
 much more orthogonal, more simpler to describe and understand (and probably
 because of that, more powerful). The same comparison could be done with
 other features, like operator overloading between D and C++. But not between
 C++ and Java because doesn't support most of this functionality (and it
 doesn't make sense to compare with the Java alternatives)


I completely agree in all of this, but I think orthogonality is a poor
term for it.

I think what you're describing is closer to the term "elegance", in
the mathematical sense
(http://en.wikipedia.org/wiki/Mathematical_elegance). Mathematical
elegance is basically about
 - Finding the "simplest" expression or solution for a problem, that
still accounts for all possibilities.
 - Finding generally applicable solutions for many similar problems.
(Even when the do not seem very similar. Consider, for instance
physical velocity, and bitrates in computers)
 - Finding a solution few dependencies on other work or assumptions.

It is also very close to the principle of Occams Razor,
(http://en.wikipedia.org/wiki/Occam's_razor), basically saying that
given two solutions to a problem which is equally "correct" (or equal
probability of being correct), the one that is "simpler" is
preferable. (The exact meaning of simpler is open to interpretation
though. ;)

A couple of good related quotes;
 "Simplicity is the ultimate sophistication." - Da Vinci
 "Make everything as simple as possible, but not simpler." - Einstein

And finally one from Ockham himself:
 "It is futile to do with more things that which can be done with fewer."



 Feb 16 2011



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 16/02/2011 18:15, Ulrik Mikaelsson wrote:

 2011/2/16 Bruno Medeiros<brunodomedeiros+spam com.gmail>:

 We must not be saying (or thinking) the same thing then, because I do think
 it is worthwhile to have orthogonality as one of the primary design goals.
 I believe we are still not thinking of orthogonality in the same way. You
 seem to be thinking in terms of pure simplicity, how easy a language is to
 describe, learn and understand. I'm thinking of how much expressiveness you
 get per amount of "complexity" (how easy it is to describe, learn, and
 understand).


 So considering C++ and Java again: then yes, C++ is much more complex than
 Java (even new-school Java, barring generics perhaps). But I never said
 otherwise. I did say that Java is not more orthogonal than C++, but not in
 the sense that Java is just as orthogonal as C++. Rather I was trying to say
 that the comparison doesn't make much sense in the first place, because Java
 has much less "capabilities". Like, you can compare D's meta-programming
 capabilites with C++, because in D you can do pretty much the same things as
 C++ (if not more) meta-programming-wise, yet the way things work in D are
 much more orthogonal, more simpler to describe and understand (and probably
 because of that, more powerful). The same comparison could be done with
 other features, like operator overloading between D and C++. But not between
 C++ and Java because doesn't support most of this functionality (and it
 doesn't make sense to compare with the Java alternatives)


 I completely agree in all of this, but I think orthogonality is a poor
 term for it.

 I think what you're describing is closer to the term "elegance", in
 the mathematical sense
 (http://en.wikipedia.org/wiki/Mathematical_elegance). Mathematical
 elegance is basically about
   - Finding the "simplest" expression or solution for a problem, that
 still accounts for all possibilities.
   - Finding generally applicable solutions for many similar problems.
 (Even when the do not seem very similar. Consider, for instance
 physical velocity, and bitrates in computers)
   - Finding a solution few dependencies on other work or assumptions.

 It is also very close to the principle of Occams Razor,
 (http://en.wikipedia.org/wiki/Occam's_razor), basically saying that
 given two solutions to a problem which is equally "correct" (or equal
 probability of being correct), the one that is "simpler" is
 preferable. (The exact meaning of simpler is open to interpretation
 though. ;)

 A couple of good related quotes;
   "Simplicity is the ultimate sophistication." - Da Vinci
   "Make everything as simple as possible, but not simpler." - Einstein


Indeed. And also, to give some concrete examples of this principle in 
terms of D language design (so as to not be talking in abstract terms only):
* making static arrays value types. The kind of hybrid/weird reference 
type it was before was but a relic from C days, it did not add value to 
the language, on the contrary...
* foreach_reverse... Although the presence of this statement did not 
complicate the language in any significant way (unlike the static array 
issue, which did make it harder to write generic code), it was clearly a 
very specific functionality that could be generalized much better. Which 
is what the idioms/API of ranges brought, and added much more value, in 
a generalized and orthogonal way.


 And finally one from Ockham himself:
   "It is futile to do with more things that which can be done with fewer."


Yes! Very good quote, I love it.  :)

-- 
Bruno Medeiros - Software Engineer



 Feb 25 2011



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Bruno Medeiros wrote:

 * making static arrays value types. The kind of hybrid/weird reference 
 type it was before was but a relic from C days, it did not add value to 
 the language, on the contrary...


Thinking about it, I and others thought that static arrays logically should 
behave like structs, i.e. be value types. C's view of them is just
fundamentally 
messed up.



 Feb 25 2011



  parent reply dolive <dolive89 sina.com>  writes:


Walter Bright Đ´µ½:


 Bruno Medeiros wrote:

 * making static arrays value types. The kind of hybrid/weird reference 
 type it was before was but a relic from C days, it did not add value to 
 the language, on the contrary...


 
 Thinking about it, I and others thought that static arrays logically should 
 behave like structs, i.e. be value types. C's view of them is just
fundamentally 
 messed up.



template+range£¬can or cannot
 make the syntax simpler then?

thanks !

will you please



 Feb 26 2011



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


dolive:


 template+range£¬can or cannot
  make the syntax simpler then?
 
 thanks !
 
 will you please


I don't understand.

Bye,
bearophile



 Feb 26 2011



  parent  dolive <dolive89 sina.com>  writes:


bearophile Đ´µ½:


 dolive:
 

 template+range£¬can or cannot
  make the syntax simpler then?
 
 thanks !
 
 will you please


 
 I don't understand.
 
 Bye,
 bearophile


 template + range syntax too complexity, hope that more simple.

thanks!



 Feb 26 2011



prev sibling  parent reply Ulrik Mikaelsson <ulrik.mikaelsson gmail.com>  writes:


2011/2/10 Bruno Medeiros <brunodomedeiros+spam com.gmail>:

 I'm very much a fan of simple and orthogonal languages. But this statement
 has a big problem: it's not clear what one actually considers to be "simple"
 and "orthogonal". What people consider to be orthogonal can vary not only a
 little, but actually a lot. Sometimes it can actually vary so much as to be
 on opposite sides. I remember seeing that first hand here on D: two people
 were arguing for opposing things in D (I don't remember the particular
 issue, but one was probably a greater language change, the other as for the
 status quo, or a minor change from the status quo), and explicitly argued
 that their alternative was more orthogonal! I remember thinking that one was
 stretching the notion of orthogonality a bit further than the other, but I
 didn't find any of them to actually be incorrect.


For the sake of discussion I'll define orthogonal as "non-redundant".
For instance, orthogonal dimensions in a coordinate-system is when the
dimension is completely unrelated to other dimensions, i.e. there is
no redundancy in the coordinate-system. Likewise orthogonality in a
language in my definition means it does not have redundancy in
features.

Now, the problem with orthogonality is that, it is not good for
exploiting 80/20 optimisations.

Example: for most (imperative) languages, you'll somewhere have the
general way of iteration;

list x;
int i = 0;
while (i < x.length) {
  // do something with x[i];
  i++;
}

Now, if the language is truly orthogonal, you cannot add the "foreach
(x in list)"-feature, since it's a redundant way of doing a subset of
the same things. Yet, it's highly likely practical thinking says that
for most programs in the language, 95% of all iteration will be
list-iteration, where the foreach-version is both shorter to write,
easier to read, and not as prone to a typo.



 Feb 10 2011



 next sibling parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 10/02/2011 21:38, Ulrik Mikaelsson wrote:

 2011/2/10 Bruno Medeiros<brunodomedeiros+spam com.gmail>:

 I'm very much a fan of simple and orthogonal languages. But this statement
 has a big problem: it's not clear what one actually considers to be "simple"
 and "orthogonal". What people consider to be orthogonal can vary not only a
 little, but actually a lot. Sometimes it can actually vary so much as to be
 on opposite sides. I remember seeing that first hand here on D: two people
 were arguing for opposing things in D (I don't remember the particular
 issue, but one was probably a greater language change, the other as for the
 status quo, or a minor change from the status quo), and explicitly argued
 that their alternative was more orthogonal! I remember thinking that one was
 stretching the notion of orthogonality a bit further than the other, but I
 didn't find any of them to actually be incorrect.


 For the sake of discussion I'll define orthogonal as "non-redundant".
 For instance, orthogonal dimensions in a coordinate-system is when the
 dimension is completely unrelated to other dimensions, i.e. there is
 no redundancy in the coordinate-system. Likewise orthogonality in a
 language in my definition means it does not have redundancy in
 features.

 Now, the problem with orthogonality is that, it is not good for
 exploiting 80/20 optimisations.

 Example: for most (imperative) languages, you'll somewhere have the
 general way of iteration;

 list x;
 int i = 0;
 while (i<  x.length) {
    // do something with x[i];
    i++;
 }

 Now, if the language is truly orthogonal, you cannot add the "foreach
 (x in list)"-feature, since it's a redundant way of doing a subset of
 the same things. Yet, it's highly likely practical thinking says that
 for most programs in the language, 95% of all iteration will be
 list-iteration, where the foreach-version is both shorter to write,
 easier to read, and not as prone to a typo.


Ok. However, my notion of orthogonality is fairly different from that one.

-- 
Bruno Medeiros - Software Engineer



 Feb 16 2011



prev sibling  parent  retard <re tard.com.invalid>  writes:


Thu, 10 Feb 2011 22:38:03 +0100, Ulrik Mikaelsson wrote:


 2011/2/10 Bruno Medeiros <brunodomedeiros+spam com.gmail>:

 I'm very much a fan of simple and orthogonal languages. But this
 statement has a big problem: it's not clear what one actually considers
 to be "simple" and "orthogonal". What people consider to be orthogonal
 can vary not only a little, but actually a lot. Sometimes it can
 actually vary so much as to be on opposite sides. I remember seeing
 that first hand here on D: two people were arguing for opposing things
 in D (I don't remember the particular issue, but one was probably a
 greater language change, the other as for the status quo, or a minor
 change from the status quo), and explicitly argued that their
 alternative was more orthogonal! I remember thinking that one was
 stretching the notion of orthogonality a bit further than the other,
 but I didn't find any of them to actually be incorrect.


 
 For the sake of discussion I'll define orthogonal as "non-redundant".
 For instance, orthogonal dimensions in a coordinate-system is when the
 dimension is completely unrelated to other dimensions, i.e. there is no
 redundancy in the coordinate-system. Likewise orthogonality in a
 language in my definition means it does not have redundancy in features.
 
 Now, the problem with orthogonality is that, it is not good for
 exploiting 80/20 optimisations.
 
 Example: for most (imperative) languages, you'll somewhere have the
 general way of iteration;
 
 list x;
 int i = 0;
 while (i < x.length) {
   // do something with x[i];
   i++;
 }
 
 Now, if the language is truly orthogonal, you cannot add the "foreach (x
 in list)"-feature, since it's a redundant way of doing a subset of the
 same things. Yet, it's highly likely practical thinking says that for
 most programs in the language, 95% of all iteration will be
 list-iteration, where the foreach-version is both shorter to write,
 easier to read, and not as prone to a typo.


There is no need to guess what orthogonality means in computer science, 
the definition is here http://en.wikipedia.org/wiki/
Orthogonality#Computer_science

For example if the language has both the if() statement and ? : 
expression, you could rename ? : into if() else and overload the keywords 
to mean both expression and a non-returning statement. Now it only has 
one construct, which is more powerful than than any of the previous two.



 Feb 16 2011