   The Perfect Language
  Whatever programming language(s) you program in frequently, I'm betting there are blocks or sections of code that you find yourself writing in some variation over and over and over again.  So I have two questions:1.  What are they?  Be as specific as you need to be. 2.  What syntax would you replace them make your life easier?  Don't think in terms of existing languages here!  How would you write it if you could.  (Understand of course that I'm talking about a level of abstraction that fully specifies the actions needed to take place; for example you might say, "render awesome looking fps please" but that doesn't tell the computer how to do what you want.)Beyond that, feel free to tell me what you'd like to see (or not see) in a programming language.  My goal is to design a new programming language (with help; open source, gpl, you get the picture) that compiles down thru C to executables (I'm thinking I could use gcc as an intermediate step).Just to get you thinking outside C and Java, one possible syntax structure is "subject verb object" instead of the usual "verb subject object" or "verb object subject".  Arguably OOP uses the SVO structure by doing Subject.doSomething(Object); however the point is we can even write it with the dot if we want.  Forget all the syntax and structure you know and think about what you WANT.  The PC already has it's binary; it's happy.  The only other thing we need in a language is to make US, the programmer happy.[edited by - bob_the_third on February 6, 2004 5:36:23 PM]
  Something that works more like a neural net -- where the process of writing is less of a serialized sort of experience, but one where different portions are tweaked some at the same time, others in a response to some kind of optimization, extension, etc.  This abstratction I believe is already possible.  I suppose an example is neccessary:Suppose you start by first determinining which type of memory management model you want to use within a certain module of your program -- ie, system managed, strict program manager, stack machine, whatever (these aren''t defined as of yet for this specification, but you can sort of understand it even now.)In the process of writing a program there would also be an added layer of abstratction, one that specifically expresses the modifying source code from a compilation perspective -- ie something of how templates work, along with the preprocessor, inline assembly if desired, and other things all following under a sort of umbrella api that specifically manipulates code (see XDoclet, XML-Databinding, etc.)Secondly -- to hell with escape characters.Built-in regular expressions.Standard abstract data types of course.Void returns assigned to the void for easier parsing.An existing recurse directory search method -- done this in about 8 languages.Some form of easy gui -- I''m thinking SVG compatible.This stuff is of course mostly off the cuff..L- " ''No one has control -- control is just a fantasy.  And being human is difficult.'' " ;  Lucientquiet:  I'm definitely with you on the GUI tools; it's the one thing that keeps me (and I MEAN the one thing) with VB.  Because I can sit down and whip out a Windows app in 10 minutes.  I want to see if I really understood what you said; are you kind of talking about a language that uses context along with syntax to determine meaning?  If so I definitely think that would be cool and it's something I'd like to see.  If not, I must have missed you and perhaps a little more elaboration would help my sleep-addled brain.  I don't know about you, but I spend way too much of my time trying to deal with indention to keep my code readable.  I don't know if there's a better alternative that wouldn't be a workaround, but...Also for-loops, do-loops, while-loops.  If-else.  All these things are cludgy.  My seed-of-a-thought (SOAT ) right now is templates on steroids.  Basically the language could be a collection of rules which would be templates that could be structured HOWEVER you want and they would then map directly to C/C++ language source files.  The compiler would do pattern matching to determine the pattern you were applying.  Context-sensitivty would be great too.  In addition, the templates could be defined with the code from the language itself.  Basically a language that can be redefined/extended at any point in any way (or at least ALMOST any way; not really just any way).  Also I was thinking about having it use an imports approach except not just with methods, but with language constructs, operators, EVERYTHING.  Everything is modular and can be overloaded/overridden.  The real trick here would be to set up a highly functional core language that people could use without having to define all sorts of macros (which would offset the efficiency gains) themselves.  The macros would be built by those who wanted to contribute to the ongoing development of the language.One thing I really like about Java is that it goes all the way from high-level to low-level; you can take whatever view you want.  I'd like to see this in the "perfect" language.  Commands, operators, etc. can be very high-level and have lower-level definitions that you can override if you want.  For example in a rendering package, you might have:"cull P's backfaces" which could be overriden if you found a better algorithm.  Notice that I used an apostrophe for a possessive; I don't think I've ever seen THAT in a programming language, but it's an idea (I'm not saying I'm sold on it; I'm just not discounting it right off the bat.  The mantra right now is keep an open mind.  ).  Also notice that P is an object with some sort of polygon-mesh definition and cull is one of the methods defined for that object; backfaces is one of its members.  By the way, if this concept takes form I have plans of beginning a language specification project (completely open; no $$ involved here, no patents etc.; I just want a GOOD language).  The goal is basically to produce a compiler that produces executables, but it can compile to an intermediary language.  Good ideas/points.  Let's keep this discussion going.  With all the debate on languages around here, I'd say it's worth our while to work as a community to "build a better mouse-trap."   [edited by - bob_the_third on February 6, 2004 6:33:44 PM];  Python ! ;quote:Original post by bob_the_third  I want to see if I really understood what you said; are you kind of talking about a language that uses context along with syntax to determine meaning?  If so I definitely think that would be cool and it''s something I''d like to see.  If not, I must have missed you and perhaps a little more elaboration would help my sleep-addled brain.   [edited by - bob_the_third on February 6, 2004 6:33:44 PM]Excuse me if I''m mistaken but wpuldn''t that require an EXTREMELY sophisticated AI. I mean If a computer could choose the correct corse of action based on context, that would be WAY more advanced than todays compilers and additionally make programmin(defined as EXPLICIT sets of instructions being read into a computer) as obsolete. thus it would be like the computer in startrek.Sure it would be possible to exist but not with todays technology(unless you like to wait a good 100 years for each build) ;  Yes Python rocks too!!! ;  Fruny:  Do you mean that Python is the perfect language or that what I described IS Python?One potential problem I see with my ideas so far (and that would have to be considered when designing a spec) is without a certain core amount of structure the user will be paralyzed with indecision and won''t be able to get anything done.  So there should be a well-specified rule-set.  I lean toward natural-language style in some cases, but not all.  Perhaps a mix or perhaps even allowing the programmer to switch between styles at in the same program.  They could code in NL, functional, oop, structural, back to NL, etc.  Mix and match.  But there has to be a syntax (or syntaxes.)  In fact, I envision at least four basic syntaxes:1. Natural language style syntax  (subject verb object modifier)2. OOP style syntax  (subject.verb(object,object,modifier,object...)3. Structural/procedural    int myFunc( int a )  {    if ( a>2 )    { return a*2;    }    else    {  return a;    }  }4.  Functional  (more of pure mathematical/algorithmic definitions; for more on this google "Functional Programming").The user can mix and match and the language should detect the syntax being used.  Each of these should be well-defined in terms of structure.  They should still be extensible in terms of methods, functions, types, and operators. ;  You guys are posting faster than I can complete my [long winded] posts! varanid:  What I mean by context sensitive is that what a particular code fragment (such as statement, operator, or method) actually means in terms of execution is based on the code that modifies it.  An example would be one of the code fragments I gave earlier: cull P''s backfacesP is an object.It has backfaces as part of it''s definition.It has defined "cull" to be a method that operates on it to remove unwanted faces from its mesh.  It is possible that "cull" could be used by another object in another way.  For example, a database might "cull" out records (although they could just call it "delete" or "remove").  In this case we could have: cull P''s backfacescull records from Database where Income > $25,000"cull" is used in both, but has different meanings based on context.  Now you said this would be difficult.  *scratches head*  I think you''re probably right.  But I don''t think it''s impossible or even beyond the scope of modern technology.;quote:One potential problem I see with my ideas so far (and that would have to be considered when designing a spec) is without a certain core amount of structure the user will be paralyzed with indecision and won''t be able to get anything done. Well, I do and don''t agree.  Let me see if I can explain why I don''t think it would be a problem.  First of there are languages that already one doesn''t always have expert knowledge of the underlying mechanisms for computing some results.  Especially since many things are platform specific -- so already some underlying abstractin has already been built upon.  So interpretted languages are mainly just abstratctions. (And some portions of non-interpretted languages are the same as well.)This doesn''t side step the issue that the bounds of those languages are determinate.  By programming one has to expect certain things to hold true in every instance -- it has to be reliable in this way.  The thing to not is that how something is done and it being reliable are two seperate things.  This is one of the powers of OOP, of course.So to build on this, the only things that needs to vary are the amount of constraints built in the language.  Tightenning or loosening these constraints should be within the power of the programm, obviously, but so should how they also be able to be tweeked, up or down a notch (so to speak.)  This would be where the language would have to spend most of its time.Some of this thought flows directly into fuzzy logic.  And since fuzzy logic is an AI discipline, then yes the compiler and the language would have to be AI based.Lisp, I think is the most powerful language to date.  Its too bad that some other languages are in the spotlight as much as they are -- incidently one of the writers of the Java language is Guy Steele -- who is also the writer of the Lisp reference book (I forget the exact title.)A fuzzy logic machine would be cool too, I know they have the working specifications for making them, I believe its considered experimental, and I don''t think its been explored thoroughly enough.Alright more later,L-   " ''No one has control -- control is just a fantasy.  And being human is difficult.'' " ;  Uh, terribly sorry, I didn''t proof read that before I posted and it was a rant-typing incident. 