D vs Go on reddit
http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0
Re: D vs Go on reddit
"Walter Bright" 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.
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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" wrote in message news:mailman.1205.1296696481.4748.digitalmar...@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 >
Re: D vs Go on reddit
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.< > Then why has not Lisp won over all competition years ago? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D vs Go on reddit
2011/2/3 "Jérôme M. Berger" : > 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 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.
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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.
Re: D vs Go on reddit
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;
};
---
Re: D vs Go on reddit
On 02/03/2011 07:16 PM, Ulrik Mikaelsson wrote:
2011/2/3 "Jérôme M. Berger":
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
Re: D vs Go on reddit
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
Re: D vs Go on reddit
"spir" wrote in message news:mailman.1206.1296697460.4748.digitalmar...@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.
Re: D vs Go on reddit
"Walter Bright" 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.
Re: D vs Go on reddit
On 02/09/2011 02:01 PM, Nick Sabalausky wrote: "Walter Bright" 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
Re: D vs Go on reddit
Nick Sabalausky wrote: "Walter Bright" 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.
Re: D vs Go on reddit
"spir" wrote in message news:mailman.1424.1297260589.4748.digitalmar...@puremagic.com... > On 02/09/2011 02:01 PM, Nick Sabalausky wrote: >> "Walter Bright" 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.
Re: D vs Go on reddit
2011/2/9 spir : > > 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.
Re: D vs Go on reddit
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.
Re: D vs Go on reddit
"Ulrik Mikaelsson" wrote in message news:mailman.1430.1297292203.4748.digitalmar...@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.
Re: D vs Go on reddit
On 02/09/2011 08:47 PM, Walter Bright wrote: Nick Sabalausky wrote: "Walter Bright" 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
Re: D vs Go on reddit
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
Re: D vs Go on reddit
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 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 good 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"). 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...)
On 09/02/2011 13:01, Nick Sabalausky wrote:
"Walter Bright" 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 outside the web/html). Only Lisp has widely been
acknowledge as a failure, dunno about Haskell, maybe the jury is still
out on that.
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 hold. 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
for D... because they are not even statically typed languages (and 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 lots
of other things in the language 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
Re: D vs Go on reddit
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" 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
Re: D vs Go on reddit
2011/2/10 Bruno Medeiros :
> 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.
Re: D vs Go on reddit
"Bruno Medeiros" 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" 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 wa
Re: D vs Go on reddit
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/
Re: D vs Go on reddit
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.
Re: D vs Go on reddit
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.
Re: D vs Go on reddit
"Daniel Gibson" 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.
Re: D vs Go on reddit
On 10/02/2011 21:38, Ulrik Mikaelsson wrote:
2011/2/10 Bruno Medeiros:
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
Re: D vs Go on reddit
On 11/02/2011 03:08, Nick Sabalausky wrote:
"Bruno Medeiros" 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" 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.
Re: D vs Go on reddit
2011/2/16 Bruno Medeiros : > 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."
Re: D vs Go on reddit
Thu, 10 Feb 2011 22:38:03 +0100, Ulrik Mikaelsson wrote:
> 2011/2/10 Bruno Medeiros :
>> 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.
Re: D vs Go on reddit
On 16/02/2011 18:15, Ulrik Mikaelsson wrote: 2011/2/16 Bruno Medeiros: 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
Re: D vs Go on reddit
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.
Re: D vs Go on reddit
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
Re: D vs Go on reddit
dolive: > template+range£¬can or cannot > make the syntax simpler then? > > thanks ! > > will you please I don't understand. Bye, bearophile
Re: D vs Go on reddit
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!
