www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Evolutionary Programming!

reply Jason Jeffory <JasonJeffory doodle.com> writes:
No, I mean the real kinda of evolution, not algorithmic mimicking!

It seems that many programmers get dissatisfied with the state of 
something and try and branch off and create something that suits 
them. The evolution of programming is the evolution of life in 
some way.

Is it possible that one could develop or modify an existing 
programming language that can adapt in such a way to provide 
maximum unity between programmers?

A language itself, that can adapt grammatically(since people like 
different grammars), be both powerful and simple, and provide all 
that is needed(more or less)?

One could say that binary programming or even punch cards were 
the evolutionary seed of modern languages. That all programming 
languages are essentially part of the evolutionary food chain.

I know many will immediately write off this statement, but I have 
to ask: Is it possible for a single language to capture it all? 
One with a polymorphic grammar(you choose, it's irrelevant) to 
provide those needs(some people just like cobol syntax and other 
people love there brackets). System level, application level? Why 
not both?

People will claim that such a language is infeasible because it 
is too complex! That's an easy argument to make. All languages 
are complex and all the people working on the nearly infinitely 
number of programming languages today could be working as one on 
the perfect language(in effect, that is what they are doing... 
they just don't realize it yet).

What are the properties of the perfect language? To be able to 
create it we have to know them.

Here are a few "laws" that I think it would have to have:

1. Grammar independence - People speak different languages and 
perceive logic through different symbols. It is the nature of 
life and knowledge.

2. Platform independence - Time changes all. A language that is 
specific to one platform will die off when the platform dies. 
When the platform evolve the language must evolve to keep up.


[Note, these laws do not state that an actual implementation 
cannot violate them. Think of them as the "interface" with a real 
living compiler as the "class"]

Any more thoughts?

Think of all the wasted man hours spent on people working 
unfocused on the issue. Surely there are invariant's in a 
programming language(any language, for that matter) that could be 
used to create a language that will unify people. Imagine the 100 
million programmers in the world all working on one language! It 
could happen with the right seed!

But a top down approach to programming(and computers) is 
required. We started from the bottom up because we were 
ignorant(just as writing software started)... will it take 50 
years, 150 years, 10000 years for programming to evolve to a 
state of peace? Where everyone knows the same language, can 
communicate exactly what they want to anyone else, and can solve 
their problems and humanities problems without squabbling over 
brackets, libraries, etc?

Such a programming language would truly be evolutionary(or at 
least revolutionary), right?
Jan 05
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 It seems that many programmers get dissatisfied with the state 
 of something and try and branch off and create something that 
 suits them. The evolution of programming is the evolution of 
 life in some way.

 Is it possible that one could develop or modify an existing 
 programming language that can adapt in such a way to provide 
 maximum unity between programmers?
In a way that is the ideal for language design. Design a minimal core that can be extended. A few languages are a bit like that: Lisp, Beta, Self, Smalltalk? But I think the most powerful concept now is _software synthesis_. The basic idea being that you specify the constraints and let the computer write the actual code, or some variation over that.
 A language itself, that can adapt grammatically(since people 
 like different grammars), be both powerful and simple, and 
 provide all that is needed(more or less)?
Ok, on the grammar level you have some languages that try. Like Pure, which is based on term rewriting. But the _key_ problem with this in the general case and also with very powerful and flexible type systems is that situations may arise where you either have bugs related to (perceived) ambiguities or that computations become very expensive and takes forever to complete (if at all). Of course, one can solve that with time-out errors and smart heuristics, but there is a design complexity cost here.
 I know many will immediately write off this statement, but I 
 have to ask: Is it possible for a single language to capture it 
 all?
If you mean "capture it in all ways that a human will perceive as significantly", then yes, probably. It might be impossible to master, like C++, but such a language could probably be constructed.
 System level,  application level? Why not both?
Ok, but I would rather have a deductive language that can easily express efficient imperative code... I don't know what it would look like, but I think that would be my ideal.
 People will claim that such a language is infeasible because it 
 is too complex!
I don't think it is infeasible, but I think that the amount of effort it takes to design it should be spent on creating AI that can do boilerplate coding. And let humans do high level application design instead. My point is this: We all spend a disproportional amount of time writing braindead code. With bugs. Because the human brain isn't very good at pinpoint level accuracy. We are really not very good at explicit imperative programming. We are much better at modelling approximately with clay, gradually refining the model until it is good enough. That's the major flaw of computer languages. None of them reflect human creative processes.
 Any more thoughts?

 Think of all the wasted man hours spent on people working 
 unfocused on the issue.
Yes, this is horrible. We should rather write more generic language agnostic code, and drop down to specific code where efficiency matter. Take a look at Github and see how many source code files have functions that implement almost the same function. That's insanely inefficient. Just take a look at D repositories and we see the same, lots of implementations of essentially the same functionality. What we need is not libraries but maps of "abstract function implementations". The closest we get to this is StackOverflow. I think that is just the beginning. We could have a language agnostic representation and automatic translation to Java, C#, JavaScript, C, C++, D...
 But a top down approach to programming(and computers) is 
 required.
You need both. Top down and bottom up, then software synthesis (let the computer fill in the details).
 Such a programming language would truly be evolutionary(or at 
 least revolutionary), right?
Software synthesis is an active research topic. Maybe we'll see it in 30 years? Real world languages lag 20-30 years behind the computer science frontier...
Jan 05
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
I guess "program synthesis" might be a less confusing term:

http://research.microsoft.com/en-us/um/people/sumitg/pubs/synthesis.html

Very interesting topic!
Jan 05
prev sibling next sibling parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 5 January 2016 at 20:11:10 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 It seems that many programmers get dissatisfied with the state 
 of something and try and branch off and create something that 
 suits them. The evolution of programming is the evolution of 
 life in some way.

 Is it possible that one could develop or modify an existing 
 programming language that can adapt in such a way to provide 
 maximum unity between programmers?
In a way that is the ideal for language design. Design a minimal core that can be extended. A few languages are a bit like that: Lisp, Beta, Self, Smalltalk? But I think the most powerful concept now is _software synthesis_. The basic idea being that you specify the constraints and let the computer write the actual code, or some variation over that.
 A language itself, that can adapt grammatically(since people 
 like different grammars), be both powerful and simple, and 
 provide all that is needed(more or less)?
Ok, on the grammar level you have some languages that try. Like Pure, which is based on term rewriting. But the _key_ problem with this in the general case and also with very powerful and flexible type systems is that situations may arise where you either have bugs related to (perceived) ambiguities or that computations become very expensive and takes forever to complete (if at all). Of course, one can solve that with time-out errors and smart heuristics, but there is a design complexity cost here.
 I know many will immediately write off this statement, but I 
 have to ask: Is it possible for a single language to capture 
 it all?
If you mean "capture it in all ways that a human will perceive as significantly", then yes, probably. It might be impossible to master, like C++, but such a language could probably be constructed.
 System level,  application level? Why not both?
Ok, but I would rather have a deductive language that can easily express efficient imperative code... I don't know what it would look like, but I think that would be my ideal.
 People will claim that such a language is infeasible because 
 it is too complex!
I don't think it is infeasible, but I think that the amount of effort it takes to design it should be spent on creating AI that can do boilerplate coding. And let humans do high level application design instead. My point is this: We all spend a disproportional amount of time writing braindead code. With bugs. Because the human brain isn't very good at pinpoint level accuracy. We are really not very good at explicit imperative programming. We are much better at modelling approximately with clay, gradually refining the model until it is good enough. That's the major flaw of computer languages. None of them reflect human creative processes.
 Any more thoughts?

 Think of all the wasted man hours spent on people working 
 unfocused on the issue.
Yes, this is horrible. We should rather write more generic language agnostic code, and drop down to specific code where efficiency matter. Take a look at Github and see how many source code files have functions that implement almost the same function. That's insanely inefficient. Just take a look at D repositories and we see the same, lots of implementations of essentially the same functionality. What we need is not libraries but maps of "abstract function implementations". The closest we get to this is StackOverflow. I think that is just the beginning. We could have a language agnostic representation and automatic translation to Java, C#, JavaScript, C, C++, D...
Yeah, I'm not sure I understand the StackOverflow thing but it would be cool if people didn't waste so much time having to do the same boilerplate code. I'm not sure if AI is far enough along. Proper AI learning algorithms could potentially help(they might suck at first but this is what training/practice is for. Eventually they will be better at it than us)
 But a top down approach to programming(and computers) is 
 required.
You need both. Top down and bottom up, then software synthesis (let the computer fill in the details).
Yes, I meant that basically programming compilers and designing languages seems to be approached current from the bottom up(much like it was in the past). We are starting to see top down approaches with DSL's, intermediate languages, etc...
 Such a programming language would truly be evolutionary(or at 
 least revolutionary), right?
Software synthesis is an active research topic. Maybe we'll see it in 30 years? Real world languages lag 20-30 years behind the computer science frontier...
I basically agree with what you said. I think it is a difficult problem and I guess it will take time for humanity to figure it all out... we are on track. It just feels like there it is very inefficient... but like most things, it tends to be exponential. I suppose the average programmer can't comprehend the complexities require for the initial adaptation and it takes time for them to "get with the program". Think of when C added ++... most programmers were not good at oop... now it seems everyone has a pretty solid understanding of it. Thanks
Jan 05
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 05:43:37 UTC, Jason Jeffory wrote:
 Yeah, I'm not sure I understand the StackOverflow thing but it 
 would be cool if people didn't waste so much time having to do 
 the same boilerplate code.
What I meant is that often what we seek is recipes for solving specific problems. Python is pretty high level and expressive. Quite often we find cut'n'paste solutions in Python to specific problems. What if we had a better way of locating recipes? What if we had high level recipes and an AI program that could turn it into something more specific and executable? Basically we not only need a better programming language, but a language for helping the AI to locate the best recipes and a global infrastructure that can provide all this knowledge compilers.
 I'm not sure if AI is far enough along. Proper AI learning 
 algorithms could potentially help(they might suck at first but 
 this is what training/practice is for. Eventually they will be 
 better at it than us
I think we need more computational power. Which will happen, but takes time. In our computers the physical chip is the size of a confetti. One idea that is being explored is to build chips as "cubes" with pipes through them for efficient cooling. And we need lots of storage too. Chess players memorize good moves given specific configurations, compilers should too. Our compilers don't learn... that's rather primitive. There are solutions that generate machine language by stringing together random sequences of instructions and selecting the ones that can become part of a working program. But it takes lots of computing. With more computing power and storage it might become practical, but we'll see more efficient AI based approaches. Still, stochastic optimizers like STOKE is hinting of what might come. https://cs.stanford.edu/people/eschkufz/ https://github.com/StanfordPL/stoke-release
 all out... we are on track. It just feels like there it is very 
 inefficient... but like most things, it tends to be exponential.
Yes, or maybe we need _lots_ of storage. It seems to help chess computers. Storage also don't need as much energy as computation, so it is easier to scale up? Just think about how much storage one cubic meter of memorysticks represents... and we are only at the beginning of solid state storage. Our brain is also quite slow, I think parts of it is working at 100hz? But we have lots of relevant information in storage to access ("experience").
 I suppose the average programmer can't comprehend the 
 complexities require for the initial adaptation and it takes 
 time for them to "get with the program". Think of when C added 
 ++... most programmers were not good at oop... now it seems 
 everyone has a pretty solid understanding of it.
Yes, tradition can be limiting. Most have a fair understanding of OOP, but many also don't understand that OO is more about modelling than programming and can be implemented in any language... So I think you are right, programmers probably think in rather concrete terms of their code, but the kind of futuristic programming language need more abstract thinking than commercial languages require. I remember a visit with a game company in the 90s. They said that many of their original coders left when they transitioned from coding in assembler to C/C++, the programmers had trouble changing how they thought about programming to a higher level. For us that is difficult to understand, right?
Jan 06
prev sibling parent reply crimaniak <crimaniak gmail.com> writes:
On Tuesday, 5 January 2016 at 20:11:10 UTC, Ola Fosheim Grøstad 
wrote:

 But I think the most powerful concept now is _software 
 synthesis_. The basic idea being that you specify the 
 constraints and let the computer write the actual code, or some 
 variation over that.
It's called Prolog. Subject of this entire thread: http://www.e-commerce-review.com/wp-content/uploads/2010/09/image51.png
Jan 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 09:03:04 UTC, crimaniak wrote:
 On Tuesday, 5 January 2016 at 20:11:10 UTC, Ola Fosheim Grøstad 
 wrote:

 But I think the most powerful concept now is _software 
 synthesis_. The basic idea being that you specify the 
 constraints and let the computer write the actual code, or 
 some variation over that.
It's called Prolog.
Prolog uses unification that is rather explicit, but Horn clauses (which is the gut of Prolog) is used. Datalog (a restricted variation of Prolog) is used for code analysis for instance and is also the guts of IBM's SQL query engine. It can be executed bottom up, in parallel. What people use for specification is SMTLIB2 or some variation of it. There have been great advances for solving difficult problems using Satisfiability Modulo Theories (SMT) in the past decades. So, no, it is not called Prolog, but Prolog is part of the history.
Jan 06
prev sibling next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 Is it possible that one could develop or modify an existing 
 programming language that can adapt in such a way to provide 
 maximum unity between programmers?

 What are the properties of the perfect language? To be able to 
 create it we have to know them.

 Here are a few "laws" that I think it would have to have:

 1. Grammar independence...
 2. Platform independence...
Languages differences are far from just grammatic or platforms. You seem to completely ignore semantics, and it's very different. But most important, people are different and their needs in different projects are different, so they need different things from the language. Alex wants to control memory allocation to the last bit and do it manually. Bob doesn't care about memory and wants a GC to clean things up, don't make him think about all those free(), delete, reference counts or whatever. Charlie thinks in terms of for loops and bytes. Dan thinks in terms of applicative functors and natural transormations in 2-categories for the left Kan extensions of his free monads. (yes, it's still programming) Ellie wants dynamic typing. Frank wants strong static types everywhere. Gordon wants all his data to be immutable and all functions referentially transparent. Howard likes mutating data in-place. Allow him, and Gordon will lose his ability to reason about the code. Good luck making all these guys write in one language and understand each other. Talking about evolution. Did you ever see evolution leading to consolidation into one specie? It works just the opposite: different habitats are filled with millions of different species. Survival of the fittest for each place == right tool for each job.
Jan 05
parent Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 5 January 2016 at 23:14:27 UTC, thedeemon wrote:
 On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 Is it possible that one could develop or modify an existing 
 programming language that can adapt in such a way to provide 
 maximum unity between programmers?

 What are the properties of the perfect language? To be able to 
 create it we have to know them.

 Here are a few "laws" that I think it would have to have:

 1. Grammar independence...
 2. Platform independence...
Languages differences are far from just grammatic or platforms. You seem to completely ignore semantics, and it's very different. But most important, people are different and their needs in different projects are different, so they need different things from the language. Alex wants to control memory allocation to the last bit and do it manually. Bob doesn't care about memory and wants a GC to clean things up, don't make him think about all those free(), delete, reference counts or whatever. Charlie thinks in terms of for loops and bytes. Dan thinks in terms of applicative functors and natural transormations in 2-categories for the left Kan extensions of his free monads. (yes, it's still programming) Ellie wants dynamic typing. Frank wants strong static types everywhere. Gordon wants all his data to be immutable and all functions referentially transparent. Howard likes mutating data in-place. Allow him, and Gordon will lose his ability to reason about the code. Good luck making all these guys write in one language and understand each other. Talking about evolution. Did you ever see evolution leading to consolidation into one specie? It works just the opposite: different habitats are filled with millions of different species. Survival of the fittest for each place == right tool for each job.
Um, there is only one form of life, and that is life itself. You are confusing variations as distinct entities. One could have a solid(mathematical and logically provable(maybe a turing machine on steroids)) that is provable to provide all programmatic needs(in the computational sense). The grammar is irrelevent. If Alex wants pascal style he uses it... if Joe wants C++, he uses that. It doesn't change the language, only the form. That was my point about the languages in my original post. Semantics is the WHOLE POINT! It's not being ignored!! But until people coordinate there efforts on the real problem a ton of effort is wasted. Just because Alex and Bob disagree on specifies means nothing for the language itself. The language is suppose to be a living breathing thing. Take it like this: What if every human being spoke the exact same language? No dialects, no semantical ambiguities, no illogical arguments? Would the world be a much more efficient place? Better? I don't know. Maybe all the variations is important(it is in an evolutionary sense), but many problems stem from people not being able to communicate effectively. A lot of time is wasted arguing about stuff or about misunderstandings... even if people don't recognize it. Wars have been started over such things. It's important enough to bring everyone together under a common umbrella for humanities sake. Less wasted time, less pollution, less anger, less unhappiness. Computers are being an integral part of humanity... But as long as we all speak different languages we will never be as one. Computers are part of the story. They are evolving from us, through us... And our mentality and approach to them will determine how fast and how well this happens. But currently there is so much bickering and wasted time over asinine(meaningless) things. e.g., Using {} or BEGIN END is fucking absolutely irrelevant, yet how many humans have wasted their time and others fighting over such ignorant things? It's like saying one color is better than another, or left is better than right, ford or chevy, etc. It's meaningless.... except that in which ignorant people make meaningful and spread it like a cancer that effects everyone in untold ways. How many programmers have wasted their life fixing bugs? Is it worth it? I don't believe so(It may be necessary, but that's a different question). Imagine this: 1. A programming language that is syntax independent(essentially an IL like basis... we already are starting towards that end)... but imagine it being developed much further than it is now. 2. A programming language that everyone can extend to solve problems. Not in a haphazard way, mind you, in a control and focused way. If the language cannot do X, then it is extended to do X. This way Alex can get what he wants. It can't be illogical because the language is designed to be logical. 3. The only programming language in existence(because it solves everyone's problems). ---Imagine what kind of power humans will have. Every minute programming is a minute, not 1 second of programming and 59 debugging. The untold increase in efficiency would be astounding. (One could argue in the same way about humanity how it treats people, and all that. It is really an issue of unity and the question is, Do you think that there is a theoretical unifying programming language)
Jan 05
prev sibling next sibling parent reply Christopher Bergqvist <chris digitalpoetry.se> writes:
On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 Any more thoughts?
I empathize with you Jason. It's kind of like biological evolution that has progressed through organisms spawning new generations and dying, and some humans' search for immortality. Being free from aging and disease would lead to a different kind of evolution happening within the same generation, through technology. This new language would not have to die out and be replaced as progress is made, and it would have a capability of evolving without growing enormous scars like C++. Key to a clean evolution is robust upgrade-ability of source code IMO. If the language designers add the dimension of safe as an after-thought, an upgrade script could be run on old source-code that would tag all valid functions as safe, (or better; tag unsafe functions as unsafe). I'm leaning toward live-editing AST's instead of raw text for robust, quick upgrades and quick compilation times. The tree could be stored in XML/JSON/binary, but be edited in a different view. AST editing would also fix the issue that beauty is in the eye of the beholder (programmer), as the same program tree could be visualized/skinned in different ways. The same programmer could also be writing programs with different defaults (such as safe/ unsafe) depending on context (short term shell scripts vs aviation-software). The reason similar AST projects have failed in the past AFAIK is that it's very very hard to build pleasant to use editors and viewers/diff-tools. Programmers are married to their editors (https://www.youtube.com/watch?v=qzC5H5xrr-E oh Andrei :) ). Bikeshedding in language forums would also go down a lot if programmers could re-skin keywords, brackets, indentation etc. :) Regarding the struggle for immortality, I think the death/life cycle still provides a way of evolution that is preferable in many ways. Having different languages provides immunization from madness that might take down the "one true language". I would love to see AST-based/structured languages succeed alongside text-based languages like D some day, and see the degree of duplicated programmer hours go down. Cheers, Chris
Jan 05
parent Jason Jeffory <JasonJeffory doodle.com> writes:
On Wednesday, 6 January 2016 at 01:45:50 UTC, Christopher 
Bergqvist wrote:
 On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 Any more thoughts?
I empathize with you Jason. It's kind of like biological evolution that has progressed through organisms spawning new generations and dying, and some humans' search for immortality. Being free from aging and disease would lead to a different kind of evolution happening within the same generation, through technology.
Yes, but we can see the trend that humans only, at least on this planet in all reasonable arguments, are moving towards "immortality"(your word, not mine ;). But we are moving towards it in a relatively inefficient way. Why 0.0001% contribute to the progress, 99.999% move in the opposite or orthogonal direction. Same with languages. Everyone things they can create a better language. They form small groups like mold does on a petri dish putting all there energy coming up with "something better". They come up with a variation. Someone else with their variation. There are so many variations that there is no unity... like a massive symphony of variation on variation that has no glue to make beautiful music. It feels insane to me, personally. As you probably know, the small groups of mold/bacteria are less likely to survive then when they clump together(this might simply be to the procreation rate or whatever). Instead of haphazard variations that are each incomplete, if everyone worked together on a single variation, we might "survive". (just as the mold has a better chance) We don't need new languages, we need to "merge" the best of all we have and then make that the "official language", and modify it and adapt it as one unified variation(sorta like Beethoven's 5th which is almost entirely built from a single motive... it's what gives it it's strength... Beethoven was a genius for seeing how powerful such an idea is, and arguably, it is the most well known and well liked piece of music).
 This new language would not have to die out and be replaced as 
 progress is made, and it would have a capability of evolving 
 without growing enormous scars like C++.
This would be the goal. I think it would have to be designed and proven to do so before we were to actually start down the path of implementing it, else it results in just another variation on a variation(it might be better, but only puts the real problem off).
 Key to a clean evolution is robust upgrade-ability of source 
 code IMO. If the language designers add the dimension of  safe 
 as an after-thought, an upgrade script could be run on old 
 source-code that would tag all valid functions as  safe, (or 
 better; tag unsafe functions as  unsafe).
I don't think this would be a problem if the language itself was designed properly. These types of semantics would be part of the language from the beginning. We *now* know that certain things are required for proper growth. We may not yet be smart enough to design the unified programming language but we have come a long way... and if every programmer on the planet worked day and night for 5 years, we would have an almost perfect approximation(99.999% vs stuff like 25-75% that we have now)
 I'm leaning toward live-editing AST's instead of raw text for 
 robust, quick upgrades and quick compilation times. The tree 
 could be stored in XML/JSON/binary, but be edited in a 
 different view. AST editing would also fix the issue that 
 beauty is in the eye of the beholder (programmer), as the same 
 program tree could be visualized/skinned in different ways. The 
 same programmer could also be writing programs with different 
 defaults (such as  safe/ unsafe) depending on context (short 
 term shell scripts vs aviation-software). The reason similar 
 AST projects have failed in the past AFAIK is that it's very 
 very hard to build pleasant to use editors and 
 viewers/diff-tools. Programmers are married to their editors 
 (https://www.youtube.com/watch?v=qzC5H5xrr-E oh Andrei :) ).
This is sort of what I'm getting at. The skinning analogy is a good one. The skin can change but the language remains the same. I suppose it takes a lot of work and mucho theoretical progress in not just computers but also psychology an logic/math.
 Bikeshedding in language forums would also go down a lot if 
 programmers could re-skin keywords, brackets, indentation etc. 
 :)
There would be none, in the long run, because if the language itself is perfect, everyone would be taught it correctly from day one. Children would understand it logically just like how child virtuoso's are able to immediately pick up the natural underlying language of music through proper training.
 Regarding the struggle for immortality, I think the death/life 
 cycle still provides a way of evolution that is preferable in 
 many ways. Having different languages provides immunization 
 from madness that might take down the "one true language". I 
 would love to see AST-based/structured languages succeed 
 alongside text-based languages like D some day, and see the 
 degree of duplicated programmer hours go down.
It's possible. Mutations are a natural defense for evolution and a way for it to optimize itself. I can't help but feel that humanity, right now, is on the doorstep of understanding evolution... and hence we don't have to continue to play by it's rules. We may or may not always be governed by the physical law but the evolutionary laws seem to be modifiable(because evolution "wants" to succeed, hence, if you do the things that help it along, it is "correct"). e.g., Procreation is obviously a way for evolution to develop. Without it, there is no "life" in the traditional sense. But humans are figuring out how to modify such things(test tube babies, extending life expectancies, etc...) and because humans are part of evolution, it seems natural that these things are not "wrong". Hence, in the future, man will probably have much much larger life expectancies. This might be evolution goal(immortality?). But who knows... what we do know is that people working *together* willingfully to solve problems always works better than when people work against each other. This is basic mathematics and even born out in the laws of physics(two men can lift something together that they can't lift apart). Maybe my ideas are pipe dreams, but so were many things in life(cars, airplanes, space travel, etc). When people actually start working together, dreams become reality!!!
Jan 05
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 Any more thoughts?
In our times programming languages exist and are adopted for market reasons. Because the basic needs have been fulfilled, better alternatives like D can get relatively ignored by the market for a long time. We never had such excellent languages, such an amount of new ones, yet the old players tend to get more entrenched like somehow history stopped. Brookes noted long ago that new language design would yield diminishing returns: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf That and the fact that hardware/OS vendors have incentive to push entrenched languages to developers, I don't see something too shocking happening in the language space.
Jan 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 10:09:57 UTC, Guillaume Piolat 
wrote:
 Brookes noted long ago that new language design would yield 
 diminishing returns: 
 http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

 That and the fact that hardware/OS vendors have incentive to 
 push entrenched languages to developers, I don't see something 
 too shocking happening in the language space.
"no silver bullet" is an anecdotal meme from the 80s. The only "insight" it provides is that we cannot engineer out the need for good designers. That's rather obvious, isn't it? The problem is that we don't express the designs. We express minutiae. This isn't how the Egyptian pyramids were built. You had architects that gave the overall vision, and lots of workers doing the minutiae. There is no reason for not letting the computer do the minutiae. Just like robots are doing minutiae in factories. You need the skilled designer, yes. Do you need all the factory workers? Not really.
Jan 06
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 6 January 2016 at 10:49:45 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 6 January 2016 at 10:09:57 UTC, Guillaume Piolat 
 wrote:
 Brookes noted long ago that new language design would yield 
 diminishing returns: 
 http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

 That and the fact that hardware/OS vendors have incentive to 
 push entrenched languages to developers, I don't see something 
 too shocking happening in the language space.
"no silver bullet" is an anecdotal meme from the 80s. The only "insight" it provides is that we cannot engineer out the need for good designers. That's rather obvious, isn't it?
I guess obvious in hindsight. The point stands about programming languages: their debut brought us order of magnitude improvements, and new PL won't. But i'll take the 50% improvement any day of the week of course. :)
Jan 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 12:13:37 UTC, Guillaume Piolat 
wrote:
 I guess obvious in hindsight.
I think that book is overrated, it was a debate book for the 80s where startups sold snake-oil... Yes, lecturers at universities toss it to their students for debate, because it was a classic, but if you want to dig into actual research on progress then Thomas Kuhn's thoughts about paradigm shifts are more relevant. Basically what happens is that we have certain shifts that enable change. Like electricity, radios, CRTs, transistors, LCDs... Or right now: cloud computing, SMT solvers, probabilistic programming languages or other ideas that can trigger shifts. We've had several advances that affects software development: 1. Algol (60s) 2. OO (late 60s) 3. Structured programming (60s/70s) 4. Structured analysis, entity modelling (60s/70s) 5. RDBMS (80s) 6. OO methodologies (70-90s) 7. Networked programming (80s) 8. Web (90s) 9. Grid/Cloud computing (2000s) 10. Formal provers (2010s)
 The point stands about programming languages: their debut 
 brought us order of magnitude improvements, and new PL won't. 
 But i'll take the 50% improvement any day of the week of 
 course. :)
I am more like 10-20x more productive in Python than in C++... ;-) Not that I consider Python to be a significant advancement. We'll probably see a paradigm shift as a result of both a change in computing hardware combined with alternative approaches to software (like SMT solvers, probabilistic computing, actors). Our hardware today consists of a lot of packaging, and the computing/storage happens on something the size of a small stamp. That's pitiful compared to the size of our brain. Increased complexity requires change. We need robust solutions that tolerate human error (so actors, probabilistic computing, and proof systems). This is kinda happening already with web-services. Systems are realized in a different way today than in the 80s, for sure.
Jan 06
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 6 January 2016 at 12:47:15 UTC, Ola Fosheim Grøstad 
wrote:
 Systems are realized in a different way today than in the 80s, 
 for sure.
Sure some systems use cutting edge techniques and management. Maybe I'm oblivious to that since I was born in late 80s. In some ways I think we still haven't catched up in significant numbers with some of what Brookes proposed. Like the Surgical Team http://c2.com/cgi/wiki?SurgicalTeam (original article is worth reading). Such an organization definately happens but I'd by accident. Like Microsoft said about their C++ compiler, we must discover flight before we invent space travel.
Jan 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 13:08:46 UTC, Guillaume Piolat 
wrote:
 Sure some systems use cutting edge techniques and management.
I think Jason brought up the idea that programmers by tradition think a particular way and this probably will delay change IMO. Pushing Mythical Man Month and Moore's law can steer what people believe is possible or should happen, like a self-fulfilling prophecy (we believe it is true, and therefore act in ways that makes it true). But... maybe hardware changes will force a shift in tradition, then it will be easier to establish completely new practices. The industry will probably try to uphold Moore's law, by increasing the number of cores. At some point that will force a change (using 100 actors/agents instead of 1 monolithic program). I hope.
 Maybe I'm oblivious to that since I was born in late 80s.
I think we all take SQL for granted, but relational databases was a major shift in data modelling/implementation. And NoSQL is major step back as a database tech (back to hierarchical database structures), but still a leap forward in a cloud setting compared to using a regular file system. So... what is technological advance? Depends on what it replaces, not only the tech.
 In some ways I think we still haven't catched up in significant 
 numbers with some of what Brookes proposed. Like the Surgical 
 Team http://c2.com/cgi/wiki?SurgicalTeam (original article is 
 worth reading). Such an organization definately happens but I'd 
 by accident.
Oh yes, methodology should be different from team to team based on problem area, people involved, organization... The "no silver bullet" holds there, which is useful for students, since process consultants sell "the one true way" (the process they know) as universal. E.g. I think "agile" often just means "no methodology, but we still have a little bit of structure". I think methodology and programming languages aren't really comparable entities. The "no silver bullet" claim holds for methodology, I agree. For programming languages... not a silver bullet, but you can get a long way with high quality "forks", "knives" and "spoons". Currently we have rusty knives, we have to be careful or we cut our tongues. The Haskell crowd are eating with bent tea spoons, lucky guys... ;)
Jan 06
prev sibling parent Idan Arye <GenericNPC gmail.com> writes:
On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
 1. Grammar independence - People speak different languages and 
 perceive logic through different symbols. It is the nature of 
 life and knowledge.
I want to focus on that. If multiple developers need to work on the same project, having different grammars is not a very good idea. Consistency is important - we promote coding standards to cover the parts not enforced by the grammar - so mixing the different grammars in the same project is a huge no-no. Promoting multiple grammars will be a disservice to programmers then, since each project will have it's chosen grammar, and number of projects each developer is comfortable working on will be drastically reduced. Of course, as already suggested in this thread, AST editors could do that translation, and having me use a different grammar than you will become as simple as my text editor highlighting keywords in different colors than yours. Then again - if this will be the case, using different grammars will also be about as meaningful as having different color schemes... However, using different grammars can have a different goal - reducing the boundaries between libraries. If everyone use different grammars of the same language, you won't have to give up on or struggle with a cool library just because it's written in a different language than the one you use. This problem is currently addressed by platforms like Java and .NET. Languages on these platforms are compiled into bytecode, with an expressive enough format that allows any language on the platform to use libraries written in other languages - without the need to translate the library's interface to the client language. The main hurdle with these - which I believe your dream language will have to face as well when it tries to support multiple grammars - is supporting the many language-backed idioms that modern languages use to make our code cleaner and safer. Let's consider, for the Dispose Pattern(https://en.wikipedia.org/wiki/Dispose_pattern). The syntax in Java and in Python looks quite similar: try (BufferedReader reader = new BufferedReader(new FileReader(filename))) { return reader.readLine(); } with open(filename) as reader: print(reader.readline()) So, since Python has a JVM version - Jython - you would expect to be able to do this: with BufferedReader(FileReader("chapter-tracker.sh")) as reader: print(reader.readline()) But no - you get an error: AttributeError: 'java.io.BufferedReader' object has no attribute '__exit__' So, what happened? While the idioms look similar in Java and Python, the semantics behind them are quite different. In Java, `try (Foo foo = new Foo())` will simply call `foo.close()` when the block is exited. In python, `with Foo() as foo:` will call `__enter__()` on `Foo()`'s result, assign it's result to `foo`, and when the block exists it call `__exit__(...)` on `Foo()`'s result from back than(not on `foo`!) To solve this, you'd have to define such idioms as part of the platform, and thus all the languages(/grammars) could follow them. But this comes with it's own price: - The list of idioms you'd want to make official can become quite large - making the interface between the platform and the languages/grammars more complex, and therefore the implementation of such languages more complex. This is something platform/language designers usually try to avoid. - Language/grammar designers will want to add new idioms to their languages/grammars, but the process of adding a new idiom to the platform will be quite long. This will give language/grammar designers to just add their new idiom into their own creation, without caring about consistency in the platform's ecosystem. So, like everything else in our profession - this is a matter of tradeoffs.
Jan 06