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

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

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