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 Zrich 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 next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

bearophile wrote:
 Walter:
=20
 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_=


=20
 I have one comment about one thing said by bnolsen:
=20
 Simplicity + Orthogonality =3D=3D win.<


Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
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 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
prev sibling 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 next sibling parent 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=

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

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
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 next 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

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 next 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
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 next sibling parent 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
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).

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 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 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...
 


 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 

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

 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...


 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

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

 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...


 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

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

 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 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+rangecan or cannot make the syntax simpler then? thanks ! will you please
Feb 26 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
dolive:

 template+rangecan 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+rangecan 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 next 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
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 next sibling parent 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
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
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